Remote Control (CCR v2): new session requests never reach the registered environment's poll loop — client stuck on "Allocating sandbox" forever

Claude Code version: 2.1.220 (npm @anthropic-ai/claude-code, latest as of report)
Platform: macOS (Apple Silicon), Node/CLI installed via Homebrew npm global
Feature: claude remote-control (Remote Control), connecting from Claude mobile app and from claude.ai/code in a browser

Summary

Once a claude remote-control session is registered and its pre-created default session is running normally, any client-initiated new session request (from the Claude mobile app's Code tab, or from claude.ai/code in a browser, on any device) gets stuck indefinitely on "Allocating sandbox" in the client UI. This happens both for brand-new sessions and for reopening previously-created sessions.

What works

• claude remote-control --name <name> registers fine: POST /v1/environments/bridge → 200, environment created.
• The pre-created default session (the one automatically created in the working directory on startup, shown as "Attached"/named after --name) spawns and runs correctly — confirmed via --verbose --debug-file:
• [bridge:work] Starting poll loop ...
• GET .../work/poll -> 200 workId=cse_... type=session
• POST .../work/cse_.../ack -> 200
• CCR v2: registered worker sessionId=... epoch=1 attempt=1
• Child process spawns (--sdk-url .../v1/code/sessions/cse_...), runs, and later archives cleanly after idle timeout (end_session / archive / exit_code=0).

What doesn't work

• Tapping "new session" in the Claude mobile app's Code tab, targeting the live registered environment, never produces a new workId in the local poll loop. GET .../work/poll keeps returning 200 (no work, N consecutive empty polls) — the request from the client apparently never reaches this environment's work queue at all.
• Same result reopening an older, previously-working session (created days earlier under an older environment registration for the same directory/--name) — the client shows the session, sends a message into it, and gets no response, with zero corresponding activity in the local bridge's debug log.
• Confirmed independently across: (a) Claude mobile app, (b) claude.ai/code in a phone browser, (c) multiple fresh remote-control restarts producing brand-new environment_ids each time (ruling out any local caching/stale-pointer explanation on the CLI side — see below).

Local-side issue also found (fixed on our end, documenting since it compounded the debugging)

Separately, we found that running claude remote-control as a macOS launchd LaunchAgent (WorkingDirectory pointed at a folder inside ~/Library/Mobile Documents/com~apple~CloudDocs/... — i.e. iCloud Drive) reliably fails with:

shell-init: error retrieving current directory: getcwd: cannot access parent directories: Operation not permitted
job-working-directory: error retrieving current directory: getcwd: cannot access parent directories: Operation not permitted
Error: timeout of 15000ms exceeded

repeating in a loop, apparently because the LaunchAgent's process context doesn't carry the iCloud/File Provider access that an interactively-spawned (Terminal/login-session) process has. Running the identical command outside launchd (foreground, or nohup from a normal login shell) has zero such errors. This is a macOS/TCC quirk, not necessarily an Anthropic bug, but worth noting since it produces very similar symptoms (hangs / no progress) and could mislead other users debugging Remote Control issues into thinking it's a local permissions problem when the actual blocker (this issue) is server-side. We also found a local bridge-pointer.json (under ~/.claude/projects/<hashed-dir>/bridge-pointer.json) that caches sessionId/environmentId per directory; if the referenced environment goes stale/dead server-side, it keeps getting reused/retried. Deleting it forces a fresh environment registration, but did not resolve the core issue above (new client-initiated sessions still never reach the poll loop, even against a brand-new environment_id).

Steps to reproduce

1. claude remote-control --name test --permission-mode acceptEdits in any directory (works fine, confirmed via debug log).
2. From the Claude mobile app (or claude.ai/code in a browser), open the Code tab, select the registered environment, and create a new session (or reopen any existing one).
3. Client shows "Allocating sandbox" and never progresses.
4. Local --debug-file log shows no corresponding workId ever appearing in GET .../work/poll responses.

Expected

A client-initiated new session request should show up as a queued work item (workId=cse_...) in the environment's poll loop within a few seconds, matching the behavior already seen for the auto pre-created default session.

Impact

Remote Control is currently unusable for its core purpose (starting/continuing coding sessions from a phone or browser against a Mac session) — the only session that ever actually runs is the one auto-created locally on startup.