remote-control in 2.1.257 never attempts a network connection (silent hang after banner; regression from 2.1.247)

Bug: claude remote-control in 2.1.257 never attempts a network connection — silent hang after banner (regression from 2.1.247)

Environment: Linux x64 (Ubuntu, kernel 6.8), native installer (~/.local/bin/claude shim + ~/.local/share/claude/versions/), OAuth (Claude subscription) auth. Worked on 2.1.247 the same morning; broke immediately after the 2.1.257 update.

Symptom: claude remote-control --name <name> prints the normal startup banner ("Take this session with you...") and then hangs forever. The device never appears in the Claude app's Code tab → Devices. No error output, nothing in --debug-file after startup (log ends right after "Acquired PID lock"), and the process ignores SIGTERM.

Evidence — it never dials out: strace -f over a full run captures zero connect() calls and zero DNS activity (1,397 syscall lines; the only network-adjacent bytes are the banner text itself). lsof -p <pid> -i on the hung process is empty; the fd table holds only stdio + /dev/urandom. It also never spawns the ~/.claude/remote/srv/<hash>/server child. So this isn't auth or network failure — the connection path simply never runs.

Also seen in 2.1.257: first service start after the update failed repeatedly with Error: Workspace not trusted. Please run claude in <dir> first to review and accept the workspace trust dialog. — expected for the new trust gate, but note a headless systemd service can't accept a dialog; a non-interactive accept path (flag or config) would help operators.

Repro:

claude --version    # 2.1.257
claude remote-control --name test --verbose --debug-file /tmp/rc.log
# banner prints; hangs forever; /tmp/rc.log ends at "Acquired PID lock"; strace shows no connect()

Workaround: pin the service to the previous versioned binary: ~/.local/share/claude/versions/2.1.247 remote-control ... — device registers and works normally.