Remote Control gets a --settings option and pins what its sessions start with

What

Remote Control lets you start Claude Code sessions from elsewhere. Running claude remote-control starts a parent process that launches child sessions.

• --settings <file> is a new option for claude remote-control: a JSON settings file for the sessions it spawns, read once at start. It is passed to each child session as --settings=<file>.
• It must come straight after remote-control. It is an error if it follows -- or an option that needs a value. If you put it before remote-control, the error now suggests claude remote-control --settings <file>, next to the existing --permission-mode hint.
• Remote Control refuses to start if the file has parse errors or cannot be pinned, saying sessions would skip part or all of the --settings file.
• With it, sessions started from a project do not get the auto-compact or auto mode that Remote Control otherwise turns on for them.
• Settings pinning: the parent records a fingerprint of the file in CLAUDE_CODE_BRIDGE_SETTINGS_BINDING. If the file changed since Remote Control started, or the record is damaged, the child session does not start.
• Start folder check: the parent puts the checked folder in CLAUDE_CODE_BRIDGE_CHILD_START_DIR. If the child's real folder differs, it exits with code 78, saying the folder "is no longer where it was when it was checked (moved, removed, or replaced with a link)".
• These variables are passed on to child processes. A new CLAUDE_CODE_NOTIFICATIONS_HOST sits next to CLAUDE_CODE_MCP_APPS_HOST in the same lists; what reads it was not seen.
• Registration now carries a device ID and advertises directory browsing. When input closes, the spawn-mode prompt says you can run claude remote-control and choose, or pass --spawn=same-dir or --spawn=worktree.

Why

You can control the settings of every session Remote Control starts. A settings file or folder swapped after Remote Control checked it stops the session instead of being used.