[BUG] Enterprise allowedMcpServers policy completely blocks Claude Routines due to un-decoded session proxy URLs

Preflight Checklist

• [x] I have searched existing issues and this hasn't been reported yet
• [x] This is a single bug report (please file separate reports for different bugs)
• [x] I am using the latest version of Claude Code

What's Wrong?

Description
When running Claude Code within an enterprise environment governed by remote settings (allowedMcpServers), all cloud/web-initiated Claude Routines fail to load allowed MCP integrations. The client throws an explicit policy block warning despite the target vendors being explicitly present on the organization allowlist.

Root Cause Analysis
The runtime environment proxies all routine tool configurations through an Anthropic gateway endpoint:
https://api.anthropic.com/v2/ccr-sessions/<session-id>/mcp?mcp_url=https%3A%2F%2Fmcp.pagerduty.com%2Fmcp

The enterprise policy validation engine evaluates this literal proxy string against the patterns configured in allowedMcpServers (e.g., https://mcp.slack.com/, https://mcp.pagerduty.com/). Because the validation loop evaluates the raw request URL instead of decoding the query string argument (mcp_url), it fails to match the allowlist patterns and drops the tool execution capabilities entirely.

What Should Happen?

Proposed Fix
The client-side policy verification layer should detect if an incoming target URL matches the api.anthropic.com/v2/ccr-sessions/ routine proxy structure. If it does, the engine should decode the mcp_url query string parameter and evaluate that underlying target vendor URL against the organization's allowedMcpServers list.

This would fix the routine validation loop without forcing enterprise security teams to broadly allowlist https://api.anthropic.com/v2/ccr-sessions/*, which inadvertently loosens per-vendor control for all web sessions.

Error Messages/Logs

**Log Evidence** (/tmp/claude-code.log)

Warning: MCP servers blocked by enterprise policy: Datadog, Slack, Gmail, github, Context7, Google-Drive, PagerDuty, Atlassian
Policy limits: Fetched successfully → policySettings applied

Steps to Reproduce

Build a Claude Routine with Connectors:

• Navigate to the Claude Routine web console (claude.ai/code/routines).
• Create a new routine and add the corresponding allowed integrations (e.g., Slack, PagerDuty) under the Connectors section.
• Successfully complete the OAuth handshake for each connector.

1. Trigger the Routine via API:

Fire the routine using its unique routine-scoped API token so it attempts to spin up the containerized environment with those active integrations:
```bash
curl -X POST "https://api.anthropic.com/v1/claude_code/routines/YOUR_ROUTINE_ID/fire" \
-H "Authorization: Bearer YOUR_ROUTINE_SPECIFIC_TOKEN" \
-H "anthropic-beta: experimental-cc-routine-2026-04-01" \
-H "Content-Type: application/json" \
-d '{"text": "Triggering routine investigation..."}'

Inspect the Execution Session State:
Once the routine initializes, open the sandbox container logs or inspect the active runtime state file (/tmp/mcp-config-cse_*.json). Notice that the runtime maps the tools to Anthropic's session proxy wrappers instead of direct endpoints:
"https://api.anthropic.com/v2/ccr-sessions/example-id/mcp?mcp_url=https%3A%2F%2Fmcp.pagerduty.com%2Fmcp"

Observe the Policy Blocking Failure:
Check the execution run logs (/tmp/claude-code.log).

---

Expected vs. Actual Results

• Expected Result: The client validation engine should decode the mcp_url query parameter ([https://mcp.pagerduty.com/mcp](https://mcp.pagerduty.com/mcp)), verify that it matches the enterprise allowlist rule, and allow the connector to load.
• Actual Result: The client naively reads the raw request URL string (api.anthropic.com), flags a string-match mismatch against the direct vendor patterns, and completely strips all 8 connectors from the session capabilities.

Claude Model

None

Is this a regression?

Yes, this worked in a previous version

Last Working Version

_No response_

Claude Code Version

2.1.175

Platform

Anthropic API

Operating System

macOS

Terminal/Shell

Terminal.app (macOS)

Additional Information

Claude Code ≥2.1.169 now enforces allowedMcpServers against the remote-session proxy URLs, blocking all our approved connectors in web sessions.

The allowlist match defeats its own intent. The org explicitly approved mcp.slack.com, mcp.datadoghq.eu, mcp.pagerduty.com, etc. The web-session proxy wraps those same servers in api.anthropic.com/v2/ccr-sessions/...?mcp_url=<encoded vendor URL>, and the policy check compares the literal proxy URL instead of decoding mcp_url. The result is that an org-approved server is blocked only in web sessions — same connector, same vendor, different transport. That's almost certainly not the intended semantics of allowedMcpServers.
It degrades silently. The only signal is one startup warning in a debug log that users of the web UI never see. Sessions just quietly lose Slack/Datadog/GitHub tooling.