Feature request: claude setup-token --list and --revoke <id> subcommands

Summary

Add two subcommands to claude setup-token:

1. claude setup-token --list — enumerate all currently-valid long-lived OAuth tokens issued for the authenticated account
2. claude setup-token --revoke <token-id> — revoke a specific token by its id (as shown in --list)

Motivation

I'm building an incident-response runbook for a containerized Claude Code deployment (homototus/ecc-sandbox). The runbook handles the case where a sandboxed Claude Code container is compromised and we need to revoke the per-experiment OAuth token fast, ideally within 5 minutes of detection.

Today, claude setup-token --help shows no options — the command is mint-only. There's no way to list or revoke a previously-minted token from the CLI. The only path is the web console at https://console.anthropic.com/settings/keys, which:

• Requires a human to open a browser and click buttons
• Can't be scripted into an incident-response flow
• Assumes the operator has console reach (network, working cookies, no account-level compromise)

Without scriptable revocation, the incident-response flow has to fall back to droplet-side containment (kill local processes, block egress at iptables, quarantine the systemd-creds credential file) and wait for the human operator to complete the Anthropic-side revocation manually. That leaves a gap between "compromise detected" and "token invalidated at Anthropic" where the token is still live.

Proposed behavior

claude setup-token --list

Output a stable format (JSON on --json, human-readable otherwise) listing each token with:

• Token id (short hash, safe to print in logs)
• Creation timestamp
• Label (if set at mint time via a proposed --label <name> option)
• Last-used timestamp (if the backend tracks it)
• Source device/session fingerprint (if available)

claude setup-token --revoke <token-id>

• Revoke the specified token immediately
• Return non-zero with a distinguishable error code if the token doesn't exist, is already revoked, or the caller isn't authorized
• The currently-authenticated session can revoke its own token (forces re-auth on next command) or any token on the account

Use cases

1. Incident response — scripted teardown can include a real revocation step instead of a manual reminder
2. Token rotation — weekly rotation rituals can revoke the old token atomically after minting the new one
3. Audit — --list lets operators periodically check whether any unexpected tokens exist on the account
4. CI/CD cleanup — ephemeral CI runners can revoke their token on teardown instead of leaking long-lived credentials

Acceptance criteria

• claude setup-token --list exists, returns JSON on --json, and shows at least the token id, creation time, and optional label
• claude setup-token --revoke <token-id> exists and revokes the named token
• Running a previously-valid token after revocation returns 401 from the API
• The Consumer Terms §3 "no automated access" clause is satisfied because these subcommands are first-party and explicitly permitted by Anthropic shipping them

Context

I'm happy to contribute a PR if the design is accepted. The incident-response use case is documented in ecc-sandbox PLAN.md §Panic button (private repo — I can paste the relevant section here if helpful).

Thanks for considering.