EnterWorktree permission prompt never renders in background remote-control sessions (regression, first bad 2.1.213)

Description

In background remote-control sessions (claude --bg --remote-control --name …, driven from claude.ai/code), the EnterWorktree permission prompt is never rendered in the browser. The session blocks indefinitely on the tool call until the user interrupts.

Only EnterWorktree is affected. Ordinary permission prompts in the same sessions — Bash, Write, Edit — render and can be approved normally.

The transcript then records the user's interrupt as "The user doesn't want to proceed with this tool use" / toolDenialKind: user-rejected, which is misleading: no decision was ever presented, let alone made.

Bisect

First bad version: 2.1.213. Last good version: 2.1.212.

Bisected by pointing the daemon at each version (stop unit → repoint ~/.local/bin/claude → start unit) and running one fresh background RC session per version with the same prompt: create a worktree with an external tool, then EnterWorktree into it at a path outside .claude/worktrees/.

| Version | Result | Evidence |
| ----------- | -------------------------------- | ------------------------------------------------------------------- |
| 2.1.209 | prompt renders | earlier bisection, 2026-07-25 |
| 2.1.212 | prompt renders, worktree entered | transcript relocated to the new worktree's project dir |
| 2.1.213 | hangs, no prompt | EnterWorktree tool_use recorded; no result event ever written |
| 2.1.215 | hangs, no prompt | same signature |
| 2.1.220 | hangs, no prompt | 137s from call to interrupt |

(2.1.214 was not a valid probe — that session produced no assistant turn at all and never reached the tool. It is bracketed by bad versions either way.)

The reliable signal in the transcript is call-to-result latency: a genuine auto-approval completes in ~0.1s, whereas these calls have no result record at all. On 2.1.212 and earlier the same sessions show prompt-and-approve latencies of 7–518s, all succeeding — so the prompt was being rendered and answered.

Not a configuration problem

• The prompt itself is expected: the target path is outside .claude/worktrees/, which requires confirmation by design. The bug is that the confirmation is never displayed over remote control.
• Adding a bare "EnterWorktree" entry to permissions.allow does not work around it — the session still prompts, and still hangs. That appears to be a second regression in the same version window; see #80432, which reports allowlist matching for this tool breaking around 2.1.213–2.1.215. The two stack: the allowlist stops suppressing the prompt, and the prompt it raises does not render.

Workaround

claude attach <session-id> from a terminal surfaces the waiting prompt, and approving it unblocks the browser session. Otherwise, staying on 2.1.212 restores correct behavior.

Environment

• Claude Code 2.1.213 through 2.1.220 (2.1.212 and earlier unaffected)
• Linux, daemon run as a systemd user unit (claude daemon run)
• Sessions created with --bg --remote-control, driven from claude.ai/code
• Target worktrees live outside .claude/worktrees/ (sibling directories of a bare .git)