Remote Control: stale environment registrations cannot be removed from claude.ai/code picker

[madhu-korada]

Summary

Once claude remote-control has registered an environment for a directory, that environment entry appears in the claude.ai/code environment picker forever. There is no CLI command, web UI action, or documented mechanism to remove it, and it does not expire. If the directory layout later changes (or a server is ever started from a different directory), the picker permanently shows duplicate entries with identical display labels, and it is impossible to tell the live one from the stale one.

Environment

• Claude Code v2.1.212, Linux x86_64, headless server accessed via SSH
• claude.ai subscription account, Remote Control enabled

Steps to reproduce

1. On a server, run claude remote-control from ~/foo (a repo checkout). An environment myhost-name-a registers and appears in the claude.ai/code picker.
2. Restructure the disk layout so the checkout now lives at ~/foo/bar, and run claude remote-control from there. A second environment myhost-name-b registers.
3. The picker now shows two entries with identical labels (directory basename + hostname), one permanently stale. Both display "1 of 32", so the stale one does not even look offline.

What I tried (none removed the stale entry)

• Killing the stale server process (tmux kill-session)
• Killing the daemon-hosted sessions backing it (bg-pty-host and --session-id processes)
• Killing claude daemon run, clearing ~/.claude/daemon* and /tmp/cc-daemon-*, then starting fresh
• Re-claiming the stale environment by starting claude remote-control from its original directory (it correctly reused the same environment id, confirming per-directory identity), then exiting gracefully with Ctrl+C so the backend saw a clean shutdown rather than a kill

After all of the above and hard refreshes, the stale entry still shows in the picker as "1 of 32".

Expected

Any of:

• A way to remove or deregister an environment (CLI flag, or a delete action on the environment row in claude.ai/code)
• Stale environments auto-expiring after some period offline
• Offline environments visually distinguished (grayed out) in the picker instead of showing a stale capacity count

Notes

• Environment identity is stable per (machine, directory), which is great: restarts reuse the same environment id and do not accumulate entries. The problem is only that abandoned registrations are permanent and indistinguishable from live ones.
• The v2.1.200 fix note ("reconnection failure no longer creates a new session entry") addresses accidental accumulation, but abandoned registrations still have no cleanup path.
• Happy to share the environment ids and account details privately for debugging.

[rico-ocepek]

I think I'm seeing the same thing over here, although I didn't do an in-depth review of the whole situation

On my Mac I added a "launch agent" plist file that runs claude remote-control on every reboot / unexpected process exit.

After some testing of this setup I can also select two different environments in the iphone / ipad app.
One of those environments is dead however and any request lands in "allocating sandbox" limbo, the other one is working fine though.
I also see two environments when typing /remote-env in Claude on the mac itself.
What's curious to me though is that it stays at two envs, no matter how often I reboot my Mac.

Not a major bug but annoying to always have to guess which env is the alive one.

[alexpriest]

Confirming this on macOS with a seven-environment setup, plus two details that may help narrow it down.

Setup: Claude Code v2.1.232, macOS 15 (Apple silicon), claude.ai Max subscription. A launchd LaunchAgent runs an idempotent script that keeps a tmux session with seven windows, each running claude remote-control --spawn same-dir in a different directory. Same shape as the launch-agent setup described in the comment above, just with more directories.

One environment per directory, not per repo or per machine. All seven of my directories are subdirectories of a single git repository, and each one registered its own distinct env_... id. So the environment key is the working directory, and any repo with several working directories accumulates several permanent entries.

Requests to a dead environment are queued indefinitely, not rejected. This seems worth separating from the cosmetic complaint, because it is what makes the stale entries actively harmful rather than just untidy.

I ran a deliberate test:

1. Stopped all seven servers and unloaded the LaunchAgent, so nothing was serving any environment. Verified zero remote-control processes.
2. In the iOS app, the device still showed a green dot, and all directories were still listed and still selectable — no indication anything was unreachable.
3. Started a session against one of them from iOS. It hung in "allocating sandbox" indefinitely. No error, no timeout, no failure message.
4. Restarted the servers. The environment came back Connected carrying an extra session — the queued request from step 3 was picked up and served, minutes after the app had appeared to fail.

The queue is durable well beyond a session. A work item created at 2026-08-13T17:48:30Z was still state: queued the next day and was adopted at 2026-08-14T17:18:01Z — roughly 19 hours later — when a server was next started in that directory. It then immediately failed with:

[bridge:init] reconnectSession(...) failed: ReconnectSession: Failed with status 400: Session not found.
[bridge:ws] <<< {"request":{"reason":"archived","subtype":"end_session"}, ...}
[bridge:session] failed exit_code=1
[ERROR] Bridge session failed: Process exited with error

So on every server start, the first thing that happens is the adoption of a stale queued item that is guaranteed to fail, surfacing as Session failed: Process exited with error in the terminal. Harmless, but it looks like a real fault and cost me a while to trace.

What I could not find (v2.1.232, in case it saves anyone else the search):

• No removal, archive, or hide affordance in the iOS app. Long-press and swipe on a directory row do nothing.
• No claude environments, claude environment, claude devices, or claude device subcommand — all four fall through to the generic usage text.
• No removal flag on claude remote-control --help.
• --no-create-session-in-dir archives the server's sessions on stop, but does not stop the environment from being registered.
• /remote-env and remote.defaultEnvironmentId apply to cloud environments, which the docs state explicitly are a different thing from Remote Control.

Suggestions, roughly in order of how much they would help:

1. Mark environments whose server has not polled recently as offline in the picker, and fail fast instead of sitting in "allocating sandbox". An error beats an indefinite spinner.
2. Expire or garbage-collect queued work for an environment that has not been served in some window, so a server start does not begin with a guaranteed failure.
3. The removal UI from [FEATURE] Let users remove stale/dead Remote Control environments from the claude.ai/code environment list #50884.

[RyeGordo]

+1, hitting the same underlying problem from a different trigger: a local machine restart (not a directory move) killed the claude remote-control process, and the session it registered is still stuck showing as disconnected in the picker with no way to remove it — no CLI flag, no web UI delete action. Like OP found, killing/restarting the local process doesn't clear the stale registration on the backend. Would be great to get either a deregister command or at least a clear offline/stale visual state so it doesn't look like a live entry.

[bcherny]

Closing as a duplicate of #76811 — please follow and 👍 that issue instead so we can track it in one place. If you think this was closed in error, comment here and we'll reopen.

🤖 Generated with Claude Code