remoteControlAtStartup is ignored under -p: no supported way to make a headless run viewable from mobile/claude.ai

Summary

remoteControlAtStartup is not read on the print-mode (-p) startup path, so there is no supported way to make a headless claude -p run viewable from the Claude mobile app or claude.ai/code. Every documented lever for Remote Control is interactive-only.

This matters for tools that orchestrate Claude Code as a child process: glorp spawns claude -p --output-format stream-json per GitHub issue and streams the events into its own dashboard. A long run can only be watched from the machine that started it.

Version

Claude Code 2.1.248 (win32-x64, winget build, commit 8c9482ad0510).

What was measured

1. --settings '{"remoteControlAtStartup":true}' under -p does nothing.

Running claude -p --permission-mode auto --settings '{"remoteControlAtStartup":true}' --rc "name" ...:

• no bridge session record is written (a real Remote Control session records a replBridgePlaceholders entry keyed by session id and stamped with the owning pid);
• the session's nameSource stays derived with the working-directory-derived name, not the one passed to --rc;
• peer discovery from another session lists the run as a plain local session, never a Remote Control one;
• the same --settings payload does take effect for other keys — adding "model" changes the model reported in the run's init event — so this is not a --settings plumbing failure.

claude --help is consistent with this: --remote-control [name] — "Start an interactive session with Remote Control enabled."

2. claude remote-control cannot adopt an existing -p session.

It is a persistent server that hosts the sessions it creates itself. --session-id takes a server-side code-session ID, not a local session UUID:

[code-session] Get 11111111-...-555555555506 failed 400: invalid session ID: must be a cse_… or session_… tagged ID

It is also unusable from an automated parent process for two further reasons: it refuses to start until the workspace trust dialog has been accepted interactively (Error: Workspace not trusted. Please run 'claude' in <dir> first...), which a -p-only tool never triggers because print mode skips that dialog; and it then asks Enable Remote Control? (y/n) on the TTY.

3. There is no view-only alternative. No autoUploadSessions (or equivalent session-mirroring) setting exists in the settings reference, and a -p run with -d (all debug categories) makes no upload or session-share request of any kind.

Request

Read remoteControlAtStartup on the print-mode startup path so claude -p can start the bridge, and honour --rc <name> there for naming. Failing that, either:

• let claude remote-control --session-id adopt a local session UUID, plus a non-interactive way to accept workspace trust and the Remote Control consent (a settings key or env var); or
• provide a view-only mirror setting for headless runs, documented as view-only.

Even the view-only form would solve the orchestration case: the value is being able to look in on a long headless run from a phone, not necessarily to steer it.