Mobile app: new session creation hangs at "allocating sandbox" against local remote-control daemons

Symptom

Starting a new session from the iOS / iPadOS Claude Code mobile app against a registered remote-control daemon hangs indefinitely at "allocating sandbox" after the first user message. Reproducible against two independent daemons on the same host (different working directories). This blocks a material use case on a paid product — mobile-initiated work when away from a desktop.

Workaround (with caveat)

Starting the session on the desktop app (works fine), then opening it on mobile to continue (works fine) is a functional fallback. It only helps when a desktop machine is physically accessible.

Environment

• Host: Linux (Ubuntu 24.04), /usr/bin/claude from @anthropic-ai/claude-code npm global install
• Two daemons via user-mode systemd, both --spawn same-dir, in two separate working directories
• Both daemons active (running), both registered, both visible in mobile host picker
• bwrap installed, kernel.unprivileged_userns_clone = 1
• Workspace trust accepted (hasTrustDialogAccepted: true in ~/.claude.json for both paths)
• Mobile app: latest version on iOS + iPadOS

Repro

1. Open Claude Code mobile app
2. Tap "New session" → pick a registered remote-control host
3. Session window opens, header shows e.g. [host]:[project]:<short-id>
4. Type any message and send
5. App displays "allocating sandbox" indefinitely; no response ever arrives

Diagnostics from the daemon side

• Daemon journal (journalctl --user -u claude-remote-control.service) is silent during the entire stall — daemon never sees the mobile session attempt reach it
• Daemon's pre-spawned child (claude.exe --print --sdk-url https://api.anthropic.com/v1/code/sessions/cse_...) stays idle in Sl state; never receives input
• /tmp/claude-<uid>/<encoded-workspace>/ has session-state subdirs for desktop-initiated sessions, none from any mobile-initiated attempt
• Same daemon, same workspace, started from desktop: session works end-to-end, journal shows activity, session-state dir is created

Hypothesis

The mobile new-session-creation handshake doesn't reach the local daemon — failure is upstream of the daemon, somewhere in the mobile app's session-creation path or the routing service that connects mobile sessions to registered remote-control hosts. Desktop's new-session path on the same daemon works, so the daemon, workspace, trust state, and network are all healthy.