t3 auth session issue --access: mint an MCP client token with a runtime-mode ceiling, headless

[freezscholte]

Problem

A headless control plane that dispatches coding work to T3 boxes over /mcp can't get a credential that lets those threads run tools without a human present.

t3 auth session issue is documented as "Issue a scoped bearer access token for headless or remote clients", and /mcp accepts its token when issued with --subject mcp-client. But the session it creates has no runtime-mode ceiling, and /mcp treats a missing ceiling as approval-required. On 0.1.7:

• t3_thread_launch with runtimeMode: "auto", "auto-accept-edits" or "full-access" fails with runtime_mode_escalation_denied ("Child runtime mode full-access is broader than parent mode approval-required").
• A thread launched at approval-required that needs a tool stops on a permission request, and t3_pending_request "cannot approve a permission request". The run waits until someone opens the UI.

So the token works for orchestration but can't run real work.

What already exists

The ceiling primitive is there; the CLI just doesn't expose it.

• EnvironmentAuth.issueMcpClientSession({ access }) sets runtimeModeCeiling from an AuthMcpClientAccess level.
• t3 thread start already uses it in-process, with access: "full-access", revoked at exit (apps/server/src/cli/thread.ts).
• t3 auth session issue goes through issueSession, which never sets a ceiling.

The workaround we use today drives the OAuth flow from a script on the box:

1. t3 auth pairing create
2. POST /oauth/mcp/register
3. POST /oauth/mcp/decision with { _tag: "pairing-code", access: "full-access", code } and PKCE
4. POST /oauth/mcp/token

It works: the 30-day token launches auto and full-access threads that run tools with no prompt. But it is four HTTP contracts, PKCE and a redirect to scrape, all to reach a primitive the CLI already holds.

Proposal

Add an access level to the headless issue command:

t3 auth session issue --subject mcp-client --access auto --ttl 30d --label "dispatcher" --token-only

• --access <read-only|approval-required|auto-accept-edits|auto|full-access> maps to issueMcpClientSession({ access }), so scopes come from mcpClientScopes(access) and the ceiling from access. That is exactly what the OAuth approval page produces.
• --access implies --subject mcp-client, or is rejected without it, so a ceiling never lands on a non-MCP session.
• Keep --ttl and --label. Running the CLI already requires local access as the server's user, which is the same trust that t3 thread start relies on.

A separate t3 auth mcp-client issue --access … subcommand would work just as well, if keeping session issue generic is preferred.

Use case

We run one T3 box per developer, on a VM, and a separate control plane dispatches tasks to those boxes: it launches a thread with clientRequestId for idempotency, waits on it, reads it back and interrupts it when needed. Each box mints the dispatcher's credential when it is provisioned, the control plane stores it, and a scheduled job rotates it before the 30 days run out. With --access, provisioning and rotation are a single CLI call on the box, with no OAuth dance and no human approval. We'd default dispatches to auto, so Claude's classifier still screens risky actions, and allow full-access per task.

Related

• Let outside MCP agents stay signed in longer than 30 days #31474 (outside MCP agents staying signed in past 30 days): --access makes scripted renewal a single CLI call.
• Scoped T3 MCP tokens for agent sessions: tool allowlist, thread scope, delegation caps #33012 (narrower scoped MCP tokens): this is the coarse level, a ceiling per token, which that idea refines.
• Skip the loopback bind in t3 auth session issue #32105 (loopback bind in t3 auth session issue): the same command, used headless.