Manage TWG CLI settings for your organization

You can control which OAuth permissions Teamwork Graph CLI (TWG CLI) can request for your organization. These settings don't install or remove twg on anyone's device - they only govern what TWG CLI can do when users authenticate with OAuth.

To learn how authentication works, see How authentication works.

Open Teamwork Graph CLI settings

Go to Atlassian Administration.
Select your organization if you have more than one.
In the sidebar, select Rovo, then select Teamwork Graph CLI.

The page displays the Permissions section for Teamwork Graph CLI.

Choose the default permission mode

By default, Allow all permissions by default is on. In this mode, TWG CLI can request all current OAuth permissions in the settings page, and new TWG CLI permissions added later are allowed automatically.

To review and manage permissions individually, turn Allow all permissions by default off. You can then configure permissions in the Read, Write and manage, and Delete categories.

There isn't a separate organization-level enable or disable toggle in the current OAuth settings. To block TWG CLI OAuth access, turn off Allow all permissions by default, clear the permissions in each category, save your changes, and choose Save and revoke sessions.

Configure permissions

Use permissions to control what TWG CLI can do across your connected apps and tools through personal OAuth 2.1 sign-in. Bitbucket tokens and Atlassian Admin API keys aren't controlled by these OAuth permission settings.

For the full procedure and how enforcement works, see Configure TWG CLI permissions.

Revoke active sessions after changes

When you save permission changes, Atlassian Administration asks whether to revoke active TWG CLI sessions:

Save without revoking saves the new settings, but users may continue using existing sessions until they need to re-authenticate.
Save and revoke sessions saves the new settings and requires users to authenticate again before TWG CLI can use the updated permissions.

Revoking sessions is the fastest way to make permission reductions take effect for active users.

Authentication posture

Each user authenticates with OAuth 2.1 during setup. Authentication happens at the user level, while organization settings control the OAuth permissions TWG CLI is allowed to request.

Bitbucket commands require a separate Bitbucket token, and admin commands use an Atlassian Admin API key. Neither is controlled by these OAuth permission settings. See How authentication works.

How TWG CLI shows up in audit logs

TWG CLI actions are visible in Atlassian audit logs. Go to Atlassian Administration, then Insights, then Audit log. The captured event details include the following fields:

Name of the command (for example, jira workitem get)
Family of the command (for example, jira.workitem)
Type of command (read, write, or delete)
Status code of the command call
Invocation source (user or agent)
Agent runtime when the command was run by a coding agent (for example, rovodev or claude-code)
Permissions used to make the command call
TWG CLI version used in the command call
Command duration in milliseconds
Whether the command was manually interrupted (for example, with Ctrl-C)
Trace ID for debugging

Command logging requires authentication, a selected site, and logging enabled. Delivery is best effort, so some invocations may be missing. Logs appear under the user's organization in Atlassian Administration. Filter by:

Activity dropdown — select Invoked TWG CLI command to view all TWG CLI logs.
Command name (such as jira workitem get).
Actor — always the user's name, not an AI agent.

Each entry contains the full JSON event and associated event details.

IP allowlist behavior

TWG CLI respects all the IP allowlists configured for your organization.