Feature request: let a local process spawn a session into a running remote-control server's list
Problem
A local coordinator process (no attached terminal, no app in the loop) manages background work and wants to open a new Claude Code session so that it shows up immediately in the same session list a linked phone or web client already sees through Remote Control -- the same effect as a person tapping "new session" in the app.
Per the docs, a claude remote-control server exists and serves multiple concurrent sessions to a connected app, but the mechanism for adding a new session to that running server's list is driven by the connected app, not by a local, non-interactive request. There is no documented CLI subcommand or local API for "ask this already-running remote-control server to open and register one more session."
What exists today (checked against the docs)
claude remote-control(remote-control.md: https://code.claude.com/docs/en/remote-control.md) starts server mode, serving multiple concurrent sessions -- but new sessions within that server are shown as originating from the connected client (phone/web), not from a local process asking the running server for one more slot.- The vendor's own comparison table in the same page lists six ways to start or reach work (Dispatch, Remote Control, Channels, Slack, Self-hosted environments, Scheduled tasks) -- none of the six is "a local automation adds a session to an already-running Remote Control server's list."
- Adjacent open issues, none of which cover this:
- #94369 -- wants Remote Control sessions to show up locally (
/resume,claude rc list-sessions) -- about reading the list locally, not about a local process adding to it. - #94546 --
--spawn=same-dirsessions never appear in the local--resumepicker -- a bug in the opposite direction (local sessions not surfacing), not a way to push a session into Remote Control's own list.
Proposed solution
A local, non-interactive way to ask an already-running claude remote-control server to open and register a new session, so it appears in the same list the connected app already renders -- e.g. claude remote-control spawn <args> targeting the running server, or a documented control message on its existing local IPC mechanism.
Use case
A background coordinator on the same machine as a phone-linked Remote Control server wants to hand off a new unit of work as a session the phone's owner can see and tap into from their existing session list, without having to drive the phone app itself to create that session.