JWT authentication enabled for CLI agent sessions
Developers can now authenticate with Personal Access Tokens to spawn AI agent sessions directly from their local CLI environments.
Previously, starting an AI agent chat required server-side secret keys, which inadvertently locked out local tooling. The cli-v3 Model Context Protocol (MCP) toolkit acts as a local server but only holds a JWT minted from a developer's Personal Access Token. This mismatch completely blocked the agent toolkit from creating sessions.
Developers can now authenticate session creation requests via JWT. By adding support for token-based auth alongside secret keys, the system allows the CLI and IDE extensions to successfully trigger, send messages to, and close agent chats.
This removes a major roadblock for local agent development in the webapp API. It operates in tandem with recent CLI chat harness updates, clearing the path for end-to-end local testing of the AI SDK chat transport.
View Original GitHub Description
Summary
POST /api/v1/sessions was secret-key-only because the customer browser flow runs through chat.createStartSessionAction (server-side, holds the secret key). But the cli-v3 MCP start_agent_chat tool is itself a server-side surface — developer's CLI/IDE acting as their own server — and only holds a JWT minted from the user's PAT. Without JWT support on this route the entire MCP agent toolkit (start_agent_chat, send_agent_message, close_agent_chat) is blocked at session creation.
Add allowJWT: true plus an authorization block requiring the write:sessions (or admin) super-scope.
Why a wildcard sessions resource
Resource scoping by taskIdentifier isn't possible at auth-resolve time — action routes don't pass body to the resource callback, and the task name only lives in the body. So the resource is sessions: "*" and the super-scope does the actual gating. The JWT-issuer (cli-v3 MCP, customer servers wrapping their own auth helpers, etc.) decides which scopes to mint, which is where per-task narrowing lives.
Test plan
- Verified end-to-end against local:
mcp__trigger__start_agent_chat→send_agent_message("pong")→send_agent_message("echo")→close_agent_chatall succeed. Two assistant turns reuse the same runId (continuation in the idle window). - Browser-mediated
chat.createStartSessionActionflow continues to work unchanged (still uses secret-key path under the hood). - Loader (GET) and other session routes — unchanged, no scope drift.
Notes
This unblocks T17 in the ai-chat e2e smoke catalog (which lives in the feature branch's skill catalog, not this repo). Pairs with the cli-v3 MCP fix on the feature branch (feat: AI SDK custom useChat transport & chat.task harness, PR #3173) — that PR's agentChat.ts change makes the call shape correct (taskIdentifier + triggerConfig); this PR opens the door for the JWT to actually pass.