feat(mcp): answer an MCP agent's scope request on Vana Web or in the terminal

[volod-vana]

When an agent connected to your Personal Server (Claude, Claude Code, Cursor) needs data it was not given, it calls request_scope_access. Until now nothing on a CLI-run server let the owner answer that. With this PR:

• The server vana server start runs passes vanaWebMcpScopeRequestApprovalUrl from personal-server-ts 1.30.0, so request_scope_access hands the agent a Vana Web link: https://app.vana.org/mcp/requests/<connection id>?ps_origin=<the server's tunnel URL>. That is the same approval surface as app data requests, and it works from a phone. Moksha uses https://app-dev.vana.org, since the CLI's moksha server already runs on the dev deployment (dev gateway, storage and relay). The page itself is unity-surfaces PR 1517.
• A --local server (no public https origin), or a server whose tunnel is not up yet, gets no link; the agent is told to wait for approval in Vana.
• vana mcp requests lists waiting requests (who, scopes, reason, age, what it already has) with the same Vana Web link per request when the server has a public origin (its /health apiOrigin). Without one it says to answer with vana mcp approve <id> or vana mcp deny <id>.
• vana mcp approve <id> [--scopes a,b] and vana mcp deny <id> answer from the terminal through the owner endpoints, with the PS session token the CLI already holds. All three emit one outcome with --json; exit codes follow the table (2 bad scopes, 5 no server or gateway down, 6 concurrent update, 1 otherwise).
• vana status adds one "Agents" line while a request waits, and accessRequests in --json.
• vana mcp with no arguments still runs the stdio MCP server.
• The MCP OAuth approval page on 127.0.0.1 is unchanged from main. The earlier loopback scope-request page and its .vana-cli-approval.json file are removed.

Server version

Pins personal-server-ts 1.30.0 (PERSONAL_SERVER_VERSION, runtime-pkg package.json and lockfile). The only change since 1.29.2 is personal-server-ts PR 372: the scope-request approve/deny endpoints, grantedScopes in the connection list, GET /v1/mcp/connections/:id, and the approval URL hook. @opendatalabs/personal-server-ts-core is now a direct runtime dependency at the same version because entry.mjs imports the hook from @opendatalabs/personal-server-ts-core/mcp. Install scripts are unchanged (better-sqlite3 12.11.1, secp256k1 5.0.2). A running server picks up 1.30.0 on its next vana server stop && vana server start. Against an older server the commands still list requests and say the server is too old to take the answer.

Tests

• pnpm validate green (741 tests).
• Unit tests: the Vana Web link (same encoding as the server hook, no link for http, loopback or missing origins, app-dev on moksha), listing with and without a public origin, JSON outcomes, exit code per server error (including MCP_CONNECTION_NOT_FOUND), --scopes validation, old server, 401, the status line.
• Installed the pinned runtime from the lockfile and checked that @opendatalabs/personal-server-ts-core/mcp exports the hook and that it builds the same URL the CLI shows.
• Still to do: a live run on a registered public server with the web page from unity-surfaces PR 1517.

https://claude.ai/code/session_01Fcv6uEy4zcXaigzDNxeW3j

[github-actions]

🎉 This PR is included in version 0.39.0 🎉

The release is available on GitHub release

Your semantic-release bot 📦🚀