[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=&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.

Start by tracing approval handling for interactive remote-session MCP calls through the CCR proxy, comparing the behavior described here with #61015 and #58757. Reproduce the listed per-tool results, then identify whether permitted_tools or requiresUserInteraction causes the refusal; done means an approved call succeeds or an unsupported call reports an accurate reason.

Do mô hình lập chỉ mục viết ra từ nội dung của issue.