[betegon]

Code Mode is the MCP equivalent of sentry api: agents can use published API operations without a dedicated MCP tool.
The client's agent writes JavaScript; our Cloudflare sandbox executes authenticated HTTP calls and returns the result.

For example: “Copy this dashboard for two projects, preserving its widgets and filters.” The existing tool catalog cannot do this; Code Mode can.

search_sentry_api discovers the schema and execute_sentry_code runs the program. This version is HTTP-only; the SDK remains future work.

Prerequisite #1676 is merged. Stack: this PR → #1675 (agent evals). #1807 (shared path matcher with the CLI) is also stacked on this PR. Runtime and permission safety tests remain here.

sequenceDiagram
    participant Agent as Agent / MCP client
    participant Sandbox as Sandbox<br/>(no token, no network)
    participant Broker as Broker in the parent Worker<br/>(holds the token)
    participant API as Sentry API
    Agent->>Sandbox: execute_sentry_code(code)
    Sandbox->>Broker: sentry.request(...) via RPC
    Broker->>API: checks permissions, adds Authorization
    API-->>Broker: HTTP response
    Broker-->>Sandbox: response data
    Sandbox-->>Agent: program result

Loading

How it fits

• One composition. The hosted handler calls registerCodeModeTools(server, env.LOADER, context) on the server it builds for each request. ApiAuthorization is always applied; there is no standalone worker or eval-only path. Tool definitions live in mcp-core/src/code-mode.ts and are generated into toolDefinitions.json with the other tools. The runtime lives in mcp-cloudflare/src/code-mode/.

• Requests go through SentryApiService, like every other tool: the organization's regional host, MCP client attribution and the bearer header come from it, so the broker never handles the token itself.

• The API data ships with the deploy, as in Cloudflare's Code Mode server: nothing fetches it at runtime. For the @sentry/api release in the pnpm catalog (0.428.0: 173 paths, 273 operations), the same release the CLI builds sentry api and sentry schema from:

  • generated/openapi.json.txt is the dereferenced OpenAPI document. It is a Workers Text module that each search sandbox parses.
  • generated/operations.json holds the method and path of each operation, which authorization matches. This is how the CLI ships its generated catalog.

  To move to a new release, bump the catalog and run pnpm --filter @sentry/mcp-cloudflare generate:openapi; a test fails if either file differs from the installed @sentry/api.

Permissions

The Sentry token authenticates API calls; its OAuth scopes and the user's Sentry permissions set the maximum access.
The permission screen controls which of those actions this MCP connection may perform, without changing the token or its scopes.

• API Read permits reads. API Write includes reads and enables create/update/delete. It starts unchecked; explicitly remembered selections are preserved.
• Permissions are additive: API Write can modify issues even with Triage Issues unchecked, and projects/teams with Manage Projects & Teams unchecked. The consent screen explains this before approval.
• The screen shows the scope: /mcp covers organizations authorized by the Sentry token; /mcp/{org} is restricted to that organization. Project-scoped connections do not expose Code Mode.
• Direct Sentry-Bearer connections default to all active skills, including API Write: the client already holds the token. skills / disable-skills can narrow access; token permissions and connection constraints still apply.
• Existing grants gain no new permissions, and stdio (sentry mcp, @sentry/mcp-server) rejects the API skills. Shared upstream OAuth scopes stay unchanged; the broker checks the MCP grant on every call, and Sentry still enforces token, role and resource permissions. Credentials stay outside generated code.

Debugging

• Each tools/call span records:
  • the executed code (gen_ai.tool.call.arguments.code, like every tool's arguments)
  • the outcome (ok, error, timeout, internal_error)
  • API calls and writes
  • the operations as METHOD template status, with denied when this connection's policy refused them
  • the schema release
• Unsampled metrics count every execution (app.code_mode.execution) and every operation by path template (app.code_mode.request).
• Failures outside the program (Worker Loader, sandbox crash, CPU limit) create an issue and return its event ID; program errors and deadlines do not. Upstream 5xx responses keep reporting the operation template.
• Concrete URLs, query strings and bodies are never recorded.
• Locally, pnpm run dev with Authorization: Sentry-Bearer <token> and ?skills=api-read runs the same code path against a real account.

Design, permissions and limits: docs/architecture/code-mode.md.

Validation and before production

Executions close pending RPC, abort in-flight HTTP and block requests whose authorization finishes after execution ends. Programs must await API calls before returning; accepted writes cannot be rolled back.

An independent review of the cleanup found nothing that widens what a request can reach. Its smaller findings are fixed in d10ff0f: Code Mode skills are listed explicitly instead of derived from hostedOnly, the 403-does-not-revoke check is back, and the docs are corrected.

Warden's findings:

• 304: addressed in f4150e1. The sandbox cannot send conditional headers, so the broker no longer forwards them and a 304 cannot occur.
• Non-JSON error bodies: addressed in cc37b12. A failed response whose body is not JSON keeps its HTTP details.
• listChanged: initialize already advertised listChanged: false, because the SDK sets the capability only on the first registerTool. That is an SDK detail, so 929dbcc sets it explicitly after Code Mode registers, as buildServer() does.
• Description length: addressed in 7ac6e60. Both descriptions now fit the repo's 2,048-character budget, with the same rules and the same published examples: search_sentry_api went from 2,310 to 2,045 characters and execute_sentry_code from 3,259 to 2,042. The length test now covers them.

Passed locally on 929dbcc:

• 493 Cloudflare tests. Code Mode runs through the authenticated handler with real Dynamic Workers, the RPC broker and the shipped schema.
• 1,899 core tests (six skipped), the toolkit-core tests, and the CLI sentry mcp tests.
• Workspace typecheck, lint and documentation links.

The remaining CLI failures (upgrade, cli fix, db permissions and others) are the same 24 that fail on main in a root container.

Agent evals in #1675 passed 35/35 with claude-opus-5-5 on this composition before the cleanup and before the descriptions were shortened. After it, the harness tests pass against the cleaned branch (61 tests, real eval worker). The model runs were not repeated.

Pending before production: real hosted OAuth-to-API authorization and Cloudflare CPU/termination/concurrency enforcement. Local workerd tests do not establish these platform guarantees; the internal_error issues and metrics above will show whether hosted CPU limits trigger. No production deployment performed.

https://claude.ai/code/session_017M6odW3kt5i65zATxfz9RX

---

Generated by Claude Code

[vercel]

The latest updates on your projects. Learn more about Vercel for GitHub.

1 Skipped Deployment

Project	Deployment	Actions	Updated
sentry-local	Skipped		Nov 2, 2026 8:58pm UTC

[cursor]

Stale Bugbot comment from a previous run.