Skip to main content

Admin guide · Platform

Developer tools

Let developers point Claude Code at the gateway with a personal identity token, so their coding-agent sessions are recorded alongside the rest of your traffic. The switch and the org-wide token list live at Admin → Developer tools.

What you are enabling

Visibility, not a new way to spend money.

  • Each developer mints their own token and sets two environment variables. Their own claude.ai login still authorizes every call — the gateway relays the request untouched and records the trace.
  • A developer token is an identity, not a credential. It grants no access to models, keys or endpoints, and it consumes no organization budget: these calls are billed to the developer's personal subscription, so every cost column on the resulting traces is a structural zero.
  • It is self-service by design. Every member can mint and revoke their own tokens; no administrator is in the loop for day-to-day use.

The org-wide switch

A kill switch, not a way to hide the page.

The capability ships disabled and has to be turned on explicitly. Until it is, developers see the feature in their sidebar with a note that the organization has not switched it on.

warning · Switching it off breaks existing tokens

While the toggle is off the gateway rejects every developer token, including ones already minted and working. It is the emergency stop for the whole capability — not a way to tidy the navigation. Turning it back on revives the same tokens; nothing is destroyed.

Auditing and offboarding

The question the list exists to answer: who still has a working token?

The admin Developer tools page: an availability toggle for the organization, then a table of developer identity tokens with name, owner, tool, token prefix and last use. Owner names and emails are redacted.
Admin → Developer Tools — the switch, then every token minted (owners redacted).

The token list covers every token minted in the organization, with its owner, and is sorted active-first rather than purely by date — so the rows that still work are the rows you see. It is paged and searchable by token name, owner email or owner name. Clicking a row opens the sessions that token carried.

FieldTypeDescription
Revokeany tokenStops the token working at the gateway. Traces already recorded are kept and the row stays visible, so the history remains auditable. This is the offboarding action.
Deleteany tokenRemoves the row entirely — nothing in the list shows it ever existed, though the audit log keeps the record. Recorded sessions are NOT removed: they stay, attributed to the developer, no longer linked to a token.
Regenerateowner onlyDeliberately has no admin override. The flow reveals a plaintext token that files sessions under the owner's name, so anyone else holding it could impersonate their developer identity.

note · Revoke, then decide about delete

Revoking is what stops access; deleting only tidies the list. For a departing employee, revoke — the row is the evidence that the token existed and was closed off.

Who can do what

Self-service for everyone, org-wide reach for owners and admins.

FieldTypeDescription
developer_token:create · :read · :revokeowner · admin · memberMint, list and revoke your OWN tokens. Every role holds these — that is what makes the feature self-service.
developer_token:read_allowner · adminSee every token in the organization, with owners, and read any developer's sessions.
developer_token:revoke_anyowner · adminRevoke or delete someone else's token.
developer_tools:updateowner · adminFlip the org-wide switch. A member cannot enable the capability for the organization. See Users & roles.

note · A pasted admin URL degrades safely

The per-developer sessions view keys off both the URL and the permission. Without developer_token:read_all the developer parameter is ignored and the reader sees their own sessions, rather than a broken page or someone else's data.

Retention

A fixed 30-day cap, separate from the org policy.

Coding-agent traces are capped at 30 days, rows and payloads alike. The cap is not org-configurable, and it is deliberately much shorter than the default generation window: these are development diagnostics rather than billing or audit records, and their volume profile is inverted — hundreds of turns per session, each payload carrying the agent's whole context window.

note · Shorter org policies still win

Your data-retention policy sweeps these rows too, so an organization configured below 30 days removes them sooner. The cap only bounds the longer windows.

What developers need from you

Then point them at their own page.

  1. The Developer tools feature entitled for the organization, and the switch on.
  2. Nothing else — they mint their own token and configure their own client. The setup they need is on Developer tools in the developer guide.