Keep an unattended outside agent signed in at Full access past 30 days

[ash663]

Our outside orchestrator (KiroCrew) drives T3 threads over /mcp with nobody at the keyboard. It signs in once with MCP OAuth at Full access and sends the bearer token as a static header.

What happened.

• The sign-in ends after 30 days (EnvironmentAuth.ts:86), and nothing renews it. The server advertises only authorization_code (McpOAuth.ts:102), registration ignores the refresh_token grant clients ask for (McpOAuth.ts:334-337), and the token endpoint refuses other grants (McpOAuth.ts:487-488). feat(server): outside agents sign in to the T3 MCP server with OAuth #16336 lists this as a known limit, and feat(server): link to another environment #16655 says links inherit it ("no renewal yet").
• t3 auth session issue --subject mcp-client --ttl 365d mints a token /mcp accepts, but the CLI cannot set a runtime-mode ceiling (cli/auth.ts:164-172, EnvironmentAuth.ts:1107-1118). /mcp reads the missing ceiling as approval-required (EnvironmentAuth.ts:1285), so a Full-access t3_thread_launch fails with runtime_mode_escalation_denied.

Ask. Either would work for us:

1. Refresh tokens on /oauth/mcp/token. Return a rotating refresh token from the code exchange, tied to the same session and ceiling, so revoking the session in Settings → Connections ends it too. The access token can then stay short. Clients that already ask for refresh_token, like Claude Code, would renew without re-approval, and so would environment links.
2. A ceiling flag on the CLI, for example t3 auth session issue --subject mcp-client --access full-access --ttl 365d, setting the same signed ceiling the approval page sets (issueMcpClientSession). It runs only on the host, which can already mint an administrative token with the same command, so it grants nothing new. The session still shows in Connections and can be revoked there.

Why it matters. An unattended orchestrator has nobody to re-approve it every 30 days. Today we mint a pairing code on the host and script the approval page's OAuth flow, which works but automates the one step meant for a person.

Related, not a duplicate: #18003 covers the 30-day lifetime of pairing-issued device sessions. Its suggested fix changes the two pairing call sites, not mcp-client sessions.

Code links are to main at 7ac952c.

[fionn77]

Same need here, at a lower ceiling. OpenClaw, a local agent gateway on the same machine as T3, signs in to /mcp over OAuth at Auto to hand coding tasks to Claude Code threads. It works well, but every 30 days a person has to go through the approval page again. The CLI token isn't an alternative, because it can't carry the Auto ceiling.

Any one of these would solve it while keeping the owner's ceiling choice:

• support the refresh_token grant for outside agents, keeping the approved runtime-mode ceiling;
• an owner-set sign-in lifetime per approval (for example 90 days or "until revoked"), at least for loopback/local clients;
• a --runtime-mode-ceiling flag on t3 auth session issue, so a long-lived CLI token can be capped like an OAuth grant.

[jason5545]

A data point from a fork. We have the same need for an always-on agent (a bot using mcp-remote at Auto-accept edits) and built fionn77's second option, but set on the host when the approval code is made instead of on the approval page:

• t3 auth pairing create --session-ttl 180d: MCP sign-ins approved with that code last 180 days instead of 30. The owner still picks the ceiling on the approval page, so the cap works exactly as before. That also sidesteps the CLI-ceiling gap in option 2 above.
• --reusable (with the code's own --ttl) lets one code approve several sign-ins until it expires or is revoked.
• Either flag makes the code MCP-only. Device pairing refuses it, so a reusable code can't pair unlimited clients. Revoking the session in Settings → Connections still ends it immediately.

Commit with a behavior test: jason5545@16a647457a. The options are stored in the pairing link's subject only because a fork can't add migrations without colliding with upstream's numbering; a real version would use columns.

The trade-off is that this is a long-lived access token, not a refresh flow, so a leaked token stays useful for its whole lifetime. Refresh tokens (option 1) are still the cleaner fix. This was the smallest change that kept the owner's ceiling choice.