stdio + Internal Integration token hangs on init in Claude Code MCP client

[sentry-junior]

Problem

When using @sentry/mcp-server via the stdio transport with a Custom (Internal) Integration token, the MCP server initialization hangs indefinitely in a "pending" state inside Claude Code's MCP stdio client. No tools are registered and no explicit auth error is returned — the handshake never completes.

This is distinct from #833, which tracks the remote HTTP endpoint (mcp.sentry.dev) not supporting API token auth. The stdio transport with a bound token is the documented workaround for headless environments, but it fails in this specific client.

Symptom

• MCP server stays in "pending" / initializing state indefinitely
• No tools registered in the client
• No explicit error or timeout surfaced

Reproduction Context

• Client: Claude Code MCP stdio client (desktop/local, not web IDE)
• Server: @sentry/mcp-server@0.32.0 (confirmed across multiple versions)
• Token type: Custom (Internal) Integration token — a single org-level bot token, not a per-developer user auth token
• Transport: stdio

What was ruled out

• Token is valid — GET https://sentry.io/api/0/ returns HTTP 200 with the same token, scopes look correct
• @sentry/mcp-server@0.32.0 spawned directly with the same token initializes cleanly and exposes 22 tools
• Per-developer OAuth flow through the same MCP works fine for individual devs
• The Claude Code stdio client is not at fault for the token itself — CLI tools work with it without issue

Diagnosis

The failure sits somewhere in the initialization handshake between Claude Code's MCP stdio client and the server when using an Internal Integration token. The same server + token combination works when spawned outside of Claude Code's client, so this is likely either:

• A difference in how Claude Code's stdio client drives the MCP init sequence (e.g. environment, process lifecycle, or handshake timing)
• A code path in the server that behaves differently for Internal Integration tokens vs. user auth tokens during initialization

Use Case

Headless bot pattern: a single shared Internal Integration token bound to a bot account, used by an internal Claude agent running inside Claude Code. OAuth per-developer is not viable here — the agent needs a single stable identity.

Workaround in place: using the Sentry CLI directly with the same token instead of the MCP path.

Related

• Support API token auth on remote MCP endpoint (not just OAuth) #833 — request for token auth on the remote HTTP endpoint (different surface, same underlying headless-agent pattern)
• anthropics/claude-code#40835 — Claude Code remote environments issue where tools don't register initially (may be related on the client side)

Action taken on behalf of Wassim Melakhessou.

[linear-code]

MCP-964

[github-actions]

Triage bot here.

I left this open as a likely stdio/Claude Code integration bug, but I don’t see an init-time server path that branches on Internal Integration vs user tokens once the token reaches the process.

What I checked:

• SENTRY_ACCESS_TOKEN / --access-token short-circuits device auth in packages/mcp-server/src/auth/resolve-token.ts.
• Tool registration in packages/mcp-core/src/server.ts is based on skills/mode, not token type.

Could you add the exact Claude Code MCP config with secrets redacted, plus any server stderr/debug output from the pending startup? That should help separate “token/env not reaching the process”, npx/spawn blocking, and an MCP handshake failure after spawn.

[dcramer]

Integration tokens have never been explored and we would not attempt to support them. Personal access tokens are different and device code is the recommended solution.

I can look into the hanging and cleaning up docs if it’s unclear.