[BUG] Daemon-managed `remoteControl` servers in `daemon.json` are tracked by the supervisor but never spawn — silent no-op

Preflight Checklist

• [x] I have searched existing issues and this hasn't been reported yet
• [x] This is a single bug report
• [x] I am using the latest version of Claude Code

What's Wrong?

~/.claude/daemon.json accepts a remoteControl array of {dir, name, spawnMode} entries, and there is a "New Remote Control server" UI flow described as "Make a directory available on claude.ai/code and the Claude mobile app."

The daemon supervisor parses this config and tracks a worker per entry — its hot-reload diffs are exactly correct — but the workers never actually start. No process is spawned, nothing is written to daemon.log for that worker kind, and the directories never appear at claude.ai/code or in the mobile session list.

Because the reload reports success, there is no signal that anything failed. It looks like it worked.

What Should Happen?

Either the workers start and the registered directories become available on claude.ai/code and mobile, or — if the feature is intentionally gated in this build — the supervisor reports that plainly, so claude daemon status and daemon.log show the entries as not-running with a reason instead of silently reporting a successful reload.

Error Messages/Logs

There are no error messages. That's the bug.

Adding nine entries, then reducing to one:

[2026-07-26T19:21:19.690Z] [supervisor] reload: stopped=0 started=9 restarted=0
[2026-07-26T19:51:21.081Z] [supervisor] reload: stopped=8 started=0 restarted=1

The diffs are correct in both directions, so the config is parsed and the workers are modelled. No further line for that worker kind appears in a 272KB daemon.log — no startup, no error, no exit.

claude daemon status acknowledges the config file but lists no Remote Control workers:

pid:     1281804
version: 2.1.220
origin:  transient — started on-demand by `claude agents` (pid 1760)
config:  /home/mjsalinger/.claude/daemon.json
bg sessions:
  bg workers:   1 running (control.sock), 1 in roster.json

This is not a general spawn failure. The same supervisor concurrently runs seven child processes for the bg worker kind. It spawns fine; it just doesn't for remoteControl.

Possibly related, from claude daemon --help:

Service install is disabled in this version — the daemon runs on demand and exits when the last client disconnects.

Steps to Reproduce

1. Have a daemon running (e.g. open claude agents, which starts one on demand). Confirm with claude daemon status.
2. Write ~/.claude/daemon.json:

``json
{
"remoteControl": [
{ "dir": "/absolute/path/to/a/git/repo", "name": "myrepo", "spawnMode": "worktree" }
]
}
``

1. tail ~/.claude/daemon.log — observe reload: stopped=0 started=1 restarted=0.
2. ps -ef | grep "claude remote-control" — no new process.
3. grep -i remotecontrol ~/.claude/daemon.log — no worker lines at all.
4. Open claude.ai/code or the mobile Code tab — the directory is not listed.

For contrast, a manually started claude remote-control in the same directory appears in the session list immediately.

Claude Code Version

2.1.220

Is this a regression?

Not sure — I have not seen this work in any version.

Platform

CLI

Operating System

Linux (WSL2, kernel 5.15)

Additional Context

The supporting surface all appears to be present: the config schema, the supervisor bookkeeping, the per-entry spawnMode of same-dir / worktree, and claude daemon lifecycle subcommands (run, status, logs, stop) with --json-path defaulting to ~/.claude/daemon.json. From the outside this behaves like a feature that is staged but not switched on. If that's intentional, the silent success on reload is still worth fixing on its own.

Filed separately from the feature side of this: #81457 asks for remote session origination scoped to a published root, and #65972 asks for agent-view background sessions to be exposed on mobile. Both depend on this daemon.