[BUG] "MCP tool call requires approval" in an INTERACTIVE remote session — the approval is clicked and ignored, and the refusal is per-tool on one connector

Reproduced 2026-08-18. #61015 was closed with "This issue should be addressed. We are continuing to monitor" — filing because this surface still reproduces it, and it differs from every duplicate on that thread in the way that matters: a human is present, an approval dialog does appear, and clicking it does not help.

Every prior report (#61015, #61027, #61044, #61143) is about scheduled routines, where the accepted explanation is "non-interactive, so no approval UI can appear." That explanation does not cover this case.

Environment

• Claude Code on the web (claude.ai/code), interactive remote session — not a routine, not a scheduled task. A human is watching and responding.
• Connectors OAuth-authorized and healthy: ListConnectors reports every one installState: "connected", connected: true, enabledInChat: true.
• The injected MCP config points every server at the CCR proxy:

https://api.anthropic.com/v2/ccr-sessions/{session}/mcp?mcp_url=<upstream>&mcp_server_id=…&toolbox_mcp_server_id=…

Symptom

Tool calls fail with:

MCP tool call requires approval

The user is prompted, clicks Allow Once, and the call fails again with the same error. Repeated approvals never succeed. That is consistent with the rejection originating at the CCR proxy — the client-side permission gate is satisfied, and the POST to the proxy endpoint is then refused — matching the unabbreviated form quoted in #61044:

Streamable HTTP error: Error POSTing to endpoint: MCP tool call requires approval

The discriminating observation: it is per-tool, not per-server

This is the part no client-side configuration can explain, and it is why three sessions here misdiagnosed it as an allowlist problem.

Same Linear connector, same session, consistent across repeats:

| Tool | Result |
| --- | --- |
| list_teams | works (first use in the session — not a cached approval) |
| list_issues | works |
| get_issue | works |
| save_issue (a write) | works |
| save_comment (a write) | works |
| list_comments | denied, every time |

The first-party Claude Code Remote toolbox server (mcp_url=https://api.anthropic.com/v1/code/mcp/meta) is denied wholesale, including read-only calls with no arguments:

| Tool | Result |
| --- | --- |
| get_session | denied |
| list_sessions | denied |
| create_session | denied |
| add_repo | denied |

Writes succeeding while a read on the same connector is refused rules out a risk-tier explanation. A brand-new tool succeeding on first use rules out "only previously-approved tools work."

Ruled out by direct test

In case it saves someone the same detour — none of these change the outcome, because the call never reaches the layer they configure:

• Project .claude/settings.json permissions.allow.
• User-level ~/.claude/settings.json grants naming the live server key.
• A PreToolUse hook returning {"hookSpecificOutput": {"permissionDecision": "allow"}}. We built one specifically to test this hypothesis; it cannot intercept a server-side refusal.
• Server-name spelling in the allow rules. We found and fixed a real typo in ours (Claude_Code_Remote vs the registered Claude-Code-Remote); it changed nothing here, as expected once the layer is understood.

Impact

create_session is the fan-out primitive for multi-session work. With the whole toolbox server refused, a remote session cannot dispatch child sessions at all — and unlike the routines case there is no "run it interactively instead" fallback, because the interactive path is itself what is broken.

Relationship to existing issues

• #61015 — canonical, closed as addressed. Same error, same proxy, but an interactive surface: either the fix does not cover it, or it has regressed.
• #61027, #61044, #61143 — duplicates of the above, all routines.
• #58757 — requiresUserInteraction blocking tools regardless of permission mode. A per-tool annotation would explain the list_comments vs list_teams split. If that is the mechanism, it is being applied to plain reads and to an entire first-party server.

What would help

1. Confirm whether the refusal comes from the permitted_tools grant or the requiresUserInteraction annotation — the remedies differ.
2. Make an interactive approval actually satisfy the proxy. Today it satisfies only the client, which is what makes the loop unbreakable from the user's side.
3. If a tool genuinely cannot be called on this surface, fail with a message saying so, rather than one that requests an approval that cannot work.