Remote Control: supervisor exits 5s after last client detaches, so it can't be left available overnight

What I'm trying to do

Start Remote Control before going to bed, so that in the morning I can attach from the Claude mobile app and pick up work on my desktop machine.

It is never running when I wake up.

What happens

The supervisor exits shortly after the last client detaches. From ~/.claude/daemon.log:

[2026-08-08T06:27:38.113Z] [bg] bg settled 816bd0ab (done)
[2026-08-08T06:27:43.114Z] [supervisor] idle 5s with no clients — exiting
[2026-08-08T06:27:43.117Z] [supervisor] shutting down (cause=idle_exit, uptime=11919s, leases=0, live_workers=0)

Once live_workers reaches 0 and no client is attached, the supervisor exits 5 seconds later. My phone is asleep overnight, so there is no client, so the daemon goes away and there is nothing to attach to in the morning.

This is consistent across every idle_exit in my log going back to June — it is clearly the intended design, not a fault.

What I'd like

An opt-in way to keep the supervisor alive while idle and reachable. Any of:

• a --no-idle-timeout flag
• a keepalive / remoteControlIdleTimeout setting in settings.json
• an explicit "available" mode, distinct from "actively serving a client"

Not asking to change the default. Exiting when nothing is attached is the right behaviour for most machines — this is specifically about wanting one machine to stay reachable.

Workarounds that don't fit

/goal or /loop with a trivial always-true condition would fake activity and keep the daemon alive, but that burns tokens all night purely to defeat a resource optimisation. That is worse than the problem.

Docs note

agent-view.md documents two separate rules: a ~1 hour timeout for an unattached session's process, and the supervisor exiting once all sessions finish and no terminal is connected. Both are accurate, but only the second governs this case, and it is 5 seconds, not an hour. Reading "about an hour" suggests a comfortable window that does not exist for the supervisor. Making that number explicit would have saved me a night of misdiagnosis — I went looking for host sleep, WSL suspension and OOM kills before finding daemon.log.

Reproduction

1. Start a Claude Code session with Remote Control on a machine that stays powered on.
2. Detach every client; let any background work finish.
3. Wait ~10 seconds.
4. cat ~/.claude/daemon/roster.json — supervisor PID is gone, workers is {}.

Environment

• Claude Code 2.1.226
• WSL2 (Ubuntu) on Windows 11
• Host confirmed awake throughout: no sleep/hibernate events, WSL VM uptime 5+ days, no OOM or memory pressure

Also worth noting

~/.claude/daemon.log is genuinely useful and was the only thing that explained this. It isn't mentioned anywhere I could find in the docs. Pointing at it from the Remote Control troubleshooting section would help people self-diagnose.