The server that ran somewhere else

Shipping client-side error monitoring gave the project visibility into real browser crashes, but investigating those errors still required context-switching between the terminal and an external web dashboard. When an agent hit a bug report or needed to verify whether a deployed preview had broken for users, a human had to copy stack traces and event IDs manually into the conversation. Connecting the developer CLI directly to Sentry’s hosted Model Context Protocol (MCP) server closes that gap, allowing agents to query, inspect, and triage live production errors without leaving their terminal session.

A server without a package#

Unlike the workbench’s existing MCP integrations for headless browser automation and documentation search, this connection required no locally installed packages. Previous tools ran inside the devcontainer via pinned npm dependencies and custom shell wrappers designed to guard against supply-chain churn. Sentry instead hosts its own remote MCP endpoint over HTTPS. The devcontainer never executes third-party server code or manages runtime worker processes; it simply acts as an HTTP client querying a remote API.

Routing through the sandbox#

Because the devcontainer operates under a default-deny egress firewall (the firewall has a lifecycle too), reaching a remote service is never just a matter of adding a URL. Outbound HTTPS traffic to the remote service had to be explicitly routed through the sandbox firewall. Following the devcontainer’s network architecture, this meant synchronized updates across both the startup firewall script and the background refresher loop that resolves changing IP addresses, followed by a clean devcontainer restart to load the read-only script mounts.

flowchart TD
  accTitle: Claude Code connecting to Sentry hosted MCP server through firewall
  accDescr: Claude Code initiates an HTTPS query using an environment-provided auth token. The request passes through the devcontainer egress firewall to Sentry's hosted MCP service, returning error issues and stack traces directly into the agent session.

  A["Claude Code session"] --> B{"Devcontainer firewall<br/>(egress control)"}
  B -->|Outbound HTTPS| C["Sentry hosted MCP<br/>(remote endpoint)"]
  C -->|Issues, traces, stats| A

  class A accent
  class C muted

Keeping credentials out of the config#

Authentication required its own defensive care. Running helper commands like claude mcp add in other setups often writes raw access tokens directly into checked-in repository configuration files. To keep credentials strictly isolated from version control, the MCP configuration was written manually to use environment variable expansion at runtime:

{
  "mcpServers": {
    "sentry": {
      "type": "http",
      "url": "https://<sentry-mcp-endpoint>/mcp",
      "headers": {
        "Authorization": "Sentry-Bearer ${SENTRY_ACCESS_TOKEN}"
      }
    }
  }
}

Developers provide their own read-only auth token via an uncommitted local environment file, scoped strictly to reading issues and event data. For now, the hosted integration is wired specifically for Claude Code, leaving mirror configurations for other developer CLIs as potential future additions if their workflows require it. With the hosted endpoint reachable and credentials kept out of tracked files, agents can pull production context directly into debugging sessions, turning bug triage from a manual clipboard chore into a natural part of development.