Remote triggers (cloud): permitted_tools on mcp_connections silently stopped matching short MCP tool names — custom connector tools never surface

Summary

Since approximately 2026-07-22, cloud remote-trigger runs (CLAUDE_CODE_ENTRYPOINT=remote_trigger, CLAUDE_CODE_REMOTE_ENVIRONMENT_TYPE=cloud_default) no longer expose any tools from a custom (URL-based) MCP connector when the trigger's mcp_connections[].permitted_tools uses short MCP tool names (e.g. "code", "bp_settings"). The same configs had worked for months, through 2026-07-21. The filter now appears to match only full harness names (mcp__<ServerName>__<tool>).

The failure mode is silent and confusing: the connector connects (its MCP server instructions blob is delivered into the session context and the session shows the server in the "still connecting / connected" reminders), but zero of its tools surface — not directly callable, not in the deferred-tools list, and invisible to ToolSearch. Scheduled routines then fail with the model reporting the server exists but has no tools.

Environment

• claude --version: 2.1.218 (Claude Code); env CLAUDE_CODE_VERSION=2.1.42
• CLAUDE_CODE_ENVIRONMENT_RUNNER_VERSION=release-1186d93b9-ext
• Custom connector: Cloudflare Worker, streamable HTTP, OAuth; server-side logs confirm the harness completes initialize + tools/list successfully on every run
• The Anthropic-managed GitHub connector in the same session surfaces all 53 of its tools normally (deferred, loadable via ToolSearch)

Repro (A/B, one variable)

Two runs of an identical one-shot diagnostic trigger against the same connector, same environment, same allowed_tools (which include the full mcp__<Server>__* names and ToolSearch):

1. permitted_tools: ["code", "bp_settings"] (short names, the historically working format) → server connects, instructions delivered, no mcp__<Server>__* tools ever appear; ToolSearch select:mcp__<Server>__<tool> returns "No matching deferred tools found".
2. permitted_tools: ["mcp__<Server>__code", "mcp__<Server>__bp_settings", ...] (full names) → tools appear as deferred, ToolSearch loads them, calls succeed ~19s after session start.

Also observed: permitted_tools: [] means "nothing permitted" (all tools filtered) rather than "no filter", with no warning at creation time.

Expected

Either (a) short tool names remain valid (back-compat with existing trigger configs), or (b) the API validates/migrates old configs and documents the required format. In all cases, a session-level warning when permitted_tools filters out 100% of a connected server's tools would have turned a multi-day silent outage of scheduled routines into a one-line fix.

Impact

Every scheduled routine using a custom connector broke simultaneously and silently on ~2026-07-22. Diagnosis required server-side log tailing plus in-container introspection runs, because routine run sessions aren't inspectable via API and the connector itself was healthy.