Remote Control on always-on machines: three reproducible edges (consent vs. service autostart, classifier mid-flow interruption, unstable environment identity)

Independent confirmation from a very similar deployment, plus a counter-datapoint on Edge 3 that may help narrow it.

Setup: Ubuntu Server 26.04, headless, claude remote-control as a system systemd unit (not a user unit), no tmux, always on since early July. Claude Code 2.1.234.

Edge 1 — confirmed

claude remote-control --help on 2.1.234 lists no --yes, no --consent, nothing non-interactive. The pipe really is the only route, and my unit does exactly what you describe:

ExecStart=/bin/bash -c 'set -o pipefail; printf "y\n" | claude remote-control --name "…" 2>&1 | <log filter>'

The consent pipe itself has never blocked a start: 43 service starts and 11 reboots in my journal (which starts Jul 26 with the unit already running; the unit dates from Jul 10, and its first recorded start is Jul 28). The only multi-minute outage in that window was unrelated to consent — a ~6-minute post-reboot crash loop on Jul 31 where 11 starts exited on "You must be logged in", a credential-availability race, not the prompt; the only other unit failure was a ~30-second OOM auto-restart on Aug 2 (see #81343), also unrelated.

On your open question in step 3 — whether the piped y is consumed or the prompt is skipped on non-TTY — I can't resolve it, but I can narrow where to look. On this machine ~/.claude.json contains:

"remoteDialogSeen": true,
"hasRemoteEnvironment": true,
"remoteControlMachineId": "…"

That looks like a persistent consent/identity record that already exists. If it is what suppresses the prompt, then on a machine that consented once interactively the piped y is simply a no-op, and your non-TTY ambiguity only bites on a machine that never consented — which is exactly the case worth reviewing.

It would also reframe your suggestion: the signed consent record you propose may already be there in some form, just undocumented and not user-manageable. The ask then becomes expose and document it, plus a service mode that refuses to start without it — rather than building it from scratch.

Caveat, stated plainly: this is untested. Verifying it means starting a second remote-control process with that key removed, which would disturb the live worker, and this one is in production use.

Edge 3 — does not reproduce here

Environment identity has been stable on this machine for 20 days:

• env_01Gf2… first appears Jul 29 07:16 and is still the id in use today. A CLI update to 2.1.234 restarted the service at 23:07 last night; the new worker came back on the same environment id three seconds later.
• In between: 38 service restarts and 7 reboots, plus every nightly CLI update up to 2.1.234 (the first version the journal records in this window is 2.1.220, on Jul 31).
• Exactly one changeover in the whole journal (retention starts Jul 26): a different id on Jul 28, replaced Jul 29. Notably, that old id demonstrably survived the three reboots of an in-place OS upgrade that evening — the changeover came only at the next morning's boot.

This isn't just my machine: the repro table in #86045 also shows the same env_… id being reused across relaunches for a given account+directory+machine, on two Macs.

So "every reboot/update invalidates saved links and printed QRs" is not universal. Differences between our setups that might explain it: system unit vs user unit, no tmux, no Ctrl+C-then-relaunch cycle, and possibly the persisted remoteControlMachineId above already acting as the stable key you are asking for.

If that is the mechanism, Edge 3 may be less "no stable binding exists" and more "the binding is not established or not reused in some launch paths" — which is a narrower and probably cheaper bug.

On the cleanup half of Edge 3

I do have the accumulation problem, but on session ids rather than environment ids: a dead session id that has failed worker registration at every single service start since it first appeared mid-morning Jul 31 — 26 in a row, always the same id — with nothing in the CLI or the apps listing it, so nothing can delete it. Tracked in #77372; the cleanly isolated relaunch-404 pattern is #86045.

Thanks @Roorn — this is exactly the kind of independent data the issue needed. I re-measured on the original machine (Debian container on ChromeOS, user systemd unit, tmux present, Claude Code 2.1.234) to test your two hypotheses against the opposite setup. Results, honestly including where they weaken my own Edge 3:

On your ~/.claude.json hypothesis (Edge 1) — partially confirmed, with a twist

My machine has the same keys:

"remoteDialogSeen": true,
"remoteControlMachineId": "b22b1776…"

but — and this is the interesting part — "hasRemoteEnvironment": false, while a remote-control worker is connected and serving sessions right now (verified: the panel shows Capacity: 1/32, and the active session is the one I'm writing this from). So whatever these keys are, hasRemoteEnvironment is either not the consent/identity record we're both looking for, or it is not consistently maintained across launch paths. That strengthens your reframe: the record exists in some form, but it appears undocumented (nothing in remote-control --help surfaces it) and — new datapoint — it is not reliably updated. "Expose, document, and gate service mode on it" still looks like the right ask — but whichever field is chosen needs to actually be written on every path that establishes an environment.

On Edge 3 — my current data now agrees with you, and narrows my original claim

I went back through the full retention of my worker log (38k lines): two environment ids in total, exactly one changeover in the whole history. The current env_… id survived last night's service restart (21:01) and this morning's full reboot (09:30) — same id, reconnect in seconds. My log has no per-line timestamps, so I can't date the single changeover precisely; stated plainly, that's the limit of my data.

So on this machine, today, "every reboot/update invalidates saved links" does not reproduce either — on a user unit with tmux, i.e. the opposite configuration of yours. Combined with your 20-day-stable system unit and the two Macs in #86045, the evidence now points where you suggested: the binding exists and is normally reused; my original Edge 3 was most likely observing the establishment/reuse failure on specific launch paths (or an older CLI version — my earliest observations predate 2.1.220), not the absence of a stable binding. I consider my Edge 3 as originally worded too broad; the narrower bug — "binding not established or not reused on some launch paths, and no way to inspect/manage it" — is the one worth fixing.

On the session-id accumulation (#77372): stated plainly, I don't have comparable data — my worker log shows a single transient Session failed (process exit), not your persistent 26-in-a-row registration failure on one dead id. So I can neither confirm nor weaken that one; if it holds, the inspect/manage half of the ask covers both problems anyway.

— Roberto Locatelli

Thanks for re-measuring on your side, that settles a lot.

One more datapoint on the hasRemoteEnvironment twist: on my machine it reads true with the worker connected, checked just now, also on 2.1.234. Same version, opposite value, so the launch path looks like the variable rather than the CLI version. I cannot tell when the field was written here; what I can say is that a system unit that has been running for weeks ends up with true where your user unit shows false. Either way it supports your conclusion: the record is real, undocumented, and not consistently maintained.

Agreed on the narrowed Edge 3 wording. If a maintainer picks this up and needs logs from the system unit side, happy to provide them.

That's the missing piece, thanks. Re-checked mine just now (still 2.1.234, worker process up and reconnecting normally): hasRemoteEnvironment is still false, read three times, stable. And to be precise about what I can actually prove: the worker is connected (process alive, last log line a clean reconnect), though its panel currently shows Capacity: 0/32, so I'm not claiming it's mid-session right now — just connected.

So on identical CLI versions we have a clean pair:

• your system unit (running for weeks) → true
• my user unit (+ tmux), only a user unit exists here, no system unit → false

Same version, worker connected in both cases, opposite value. That isolates it from CLI version and points at the launch path: hasRemoteEnvironment is written on the path that starts the system-unit worker but not on the one that starts mine. And since remoteControlMachineId is present on both, it matches your reframe — the consent/identity record exists, but the flag that should reflect it is populated inconsistently across launch paths.

For the maintainers that's a narrow, cheap fix: write hasRemoteEnvironment (and clear it on teardown) on every path that establishes or drops a remote environment, so the field can be trusted as the "is a remote worker live" signal it looks like. Nothing more from me either — happy to pull specific log lines if that helps pin the exact path.