[BUG] Child sessions: claude-code-remote MCP "Allow once" approvals are orphaned — calls fail before the prompt renders, grants never bind (11 calls, every prompt approved, 0 executions)

### Preflight Checklist

- [x] I have searched [existing issues](https://github.com/anthropics/claude-code/issues?q=is%3Aissue+MCP+tool+call+requires+approval). Related but distinct: #61015, #58757, #61027, #61044, #61196 — all cover *unattended* contexts (Routines, Bypass Permissions) where no human is present to approve. This report covers an **interactive** context where a human received the prompts and granted approval, and the grants were still discarded.
- [x] This is a single bug report.
- [x] I am using the latest version of Claude Code (Anthropic-managed web environment).

## What's Wrong?

In a Claude Code on the web **child session** (`CLAUDE_CODE_CHILD_SESSION=1`), every call to
every tool on the built-in `claude-code-remote` MCP server fails immediately with:

MCP tool call requires approval

The approval prompts **do** reach the user's mobile app, and the user **approved three of
them** — the calls still fail, including calls made immediately *after* the approvals were
granted. Meanwhile, in the same session, ~35 calls to `mcp__github__*` tools executed with no
prompt at all, **including the same operation** (`subscribe_pr_activity`) that fails on the
claude-code-remote server.

### Observed behaviour (full tally, one session)

| Tool (claude-code-remote server) | Calls | User approvals granted | Executions |
| --- | --- | --- | --- |
| `add_repo` | 5 | 1 (user: "the approval popped up - and I agreed to it") | 0 |
| `subscribe_pr_activity` | 1 | — | 0 |
| `get_session` | 1 | — | 0 |
| `create_session` | 4 | ≥2 confirmed with screenshot; user approved every prompt shown | 0 |
| **Total** | **11** | **every prompt approved** | **0** |

Every failure returned the identical string, instantly — the calls did not block awaiting
approval.

Control group, same session:

- ~35 calls to `mcp__github__*` tools (issues, PRs, comments, check runs, job logs,
`subscribe_pr_activity`) — all executed, zero prompts.
- `mcp__github__subscribe_pr_activity` succeeded minutes after
`mcp__claude-code-remote__subscribe_pr_activity` failed — same operation, different server,
opposite result.

### Contrast with an app-created session (same account, same day)

A session the same user created directly from the mobile app, scoped at creation to one
repository, successfully called `add_repo` mid-session behind a single approval prompt: the
prompt appeared, the user approved, the tool executed, the second repository was attached, and
write operations against it followed. So the tool, the account, and the approval UI all work —
the failure is specific to the session type.

### Mechanism hypothesis

The observed pieces assemble into a coherent failure shape:

1. In a child session, the claude-code-remote tool call **fails fast** — it returns the
approval error to the agent immediately rather than blocking on the prompt.
2. The prompt is still dispatched to the user's device, **asynchronously**, after the call
has already failed.
3. The grant is **"Allow once"** scoped — it wants to attach to a pending call, but the call
it was minted for no longer exists.
4. The orphaned grant is not banked, so the next call repeats the cycle from step 1.

Steps 2–4 would each be fine if step 1 blocked, which is presumably what app-created sessions
do (where the identical flow works). Updating the mobile app changed nothing, consistent with
the fail-fast happening server-side before the client is involved.

If the gating mechanism from #58757 is shared, a plausible shape: claude-code-remote tools
carry `requiresUserInteraction`, and the child-session surface routes the prompt to the user
but has no channel to return the grant to the gate.

## What Should Happen?

Either of:

- Approval prompts for claude-code-remote tools in child sessions block the call and bind on
approval, as they do in app-created sessions; or
- If child sessions are by design unable to use these tools, the call should fail with an
explicit "not available in this session type" error, and the approval prompt should not be
shown to the user at all — prompting for an approval that will be discarded is the worst of
both.

From the user's side the current behaviour is maximally confusing: they are asked, they say
yes, and nothing changes — the same request re-prompts indefinitely.

## Error Messages/Logs

```shell
MCP tool call requires approval
```

Returned instantly, identically, for all 11 calls across four different tools.

## Steps to Reproduce

1. From a Claude Code on the web session, have the agent spawn a **child session**
(the container env of the child has `CLAUDE_CODE_CHILD_SESSION=1`).
2. In the child session, call any `claude-code-remote` tool — e.g. `create_session`,
`add_repo`, `get_session`, `subscribe_pr_activity`.
3. Observe: the call fails **instantly** with `MCP tool call requires approval` — it does not
block.
4. Moments later, an approval prompt renders on the user's mobile app: title
**"Create Session requests permission"**, showing the requested session's title, with
buttons **"Allow once"** and **"Deny"**. Tap **Allow once**.
5. Retry the identical call → fails instantly, same string.
6. A second prompt appears. Approve again.
7. Call a third time, now *after* two granted approvals → fails instantly, same string. A
fourth call after the confirmed approvals fails the same way, so an unconsumed
"Allow once" is not banked for the next identical call either.

So approvals do not bind synchronously (the call has already failed by the time the prompt
renders), do not create a standing grant for subsequent identical calls, and do not apply
retroactively.

Control step, in the same session: call `mcp__github__subscribe_pr_activity`. It executes with
no prompt — the same operation that fails on the claude-code-remote server.

## Claude Model

Not sure / Multiple models — `claude-opus-5`, switched to `claude-fable-5` late in the
session. Failures occurred under both.

## Is this a regression?

I don't know

## Claude Code Version

Latest (Anthropic-managed cloud environment on claude.ai/code; version not user-pinned)

## Platform

Anthropic API

## Operating System

Other Linux (Anthropic-managed cloud container)

## Terminal/Shell

Other — Claude Code on the web (claude.ai/code)

## Additional Information

**Environment detail**

- Claude Code on the web (claude.ai/code), Anthropic-managed cloud environment
- Session is a **child session**: `CLAUDE_CODE_CHILD_SESSION=1` set in the container env
- Session repo scope at creation: one repository (name redacted)
- Date observed: 2026-08-26
- GitHub auth: proxy-injected (`GH_TOKEN=proxy-injected` in container env)

**Impact**

A child session cannot: widen its repo scope (`add_repo`), spawn or steer sessions
(`create_session`, `get_session`, `interrupt_session`), schedule self check-ins (`send_later`,
`create_trigger`), or subscribe to PR activity via this server. Workflows that instruct agents
to use these tools (e.g. PR-watching guidance that says to schedule an hourly `send_later`
check-in) silently degrade. None of this is documented as a child-session limitation in
the [Claude Code on the web docs](https://code.claude.com/docs/en/claude-code-on-the-web).

**Suggested labels** (author lacks triage rights on this repo): `bug`, `area:mcp`,
`area:permissions`, `platform:web`

**Related**

- #61015 — root issue for the Routines variant; closed May 2026 with "should be addressed"
- #58757 — Bypass Permissions mode blocks MCP tools with `requiresUserInteraction` flag
- #61027, #61044, #61196 — duplicates/variants, all reporting the same error string in
non-interactive contexts

The new datum this report adds: those describe unattended contexts where *no human is present*
to approve. Here a human **was** present, **received** the prompts, and **granted** approval —
and the grant was discarded. The approval loop is severed, not merely unattended.

A screenshot of the "Create Session requests permission / Allow once / Deny" prompt from the
mobile app is attached in the first comment below.

No repository file or test is named. Start by reproducing the child-session flow with CLAUDE_CODE_CHILD_SESSION=1, comparing claude-code-remote and GitHub MCP calls and the app-created session; done means an approved child-session call executes, or child sessions fail explicitly without displaying an approval prompt.

Escrito por el modelo de indexación a partir del texto del issue.