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

1. The prompt is still dispatched to the user's device, asynchronously, after the call

has already failed.

1. The grant is "Allow once" scoped — it wants to attach to a pending call, but the call

it was minted for no longer exists.

1. 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

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).

1. In the child session, call any claude-code-remote tool — e.g. create_session,

add_repo, get_session, subscribe_pr_activity.

1. Observe: the call fails instantly with MCP tool call requires approval — it does not

block.

1. 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.

1. Retry the identical call → fails instantly, same string.
2. A second prompt appears. Approve again.
3. 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.

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.