[FEATURE] Let users remove stale/dead Remote Control environments from the claude.ai/code environment list

Found 3 possible duplicate issues:

1. https://github.com/anthropics/claude-code/issues/37321
2. https://github.com/anthropics/claude-code/issues/47761
3. https://github.com/anthropics/claude-code/issues/39914

This issue will be automatically closed as a duplicate in 3 days.

• If your issue is a duplicate, please close it and 👍 the existing issue instead
• To prevent auto-closure, add a comment or 👎 this comment

🤖 Generated with Claude Code

I don't think any of these are actual duplicates:

• #37321 is a bug report about claude remote-control hanging on Windows. Stale environments are mentioned there only as a suspected cause of the connection hang. Fixing that bug wouldn't give users any way to clean up the list, which is the problem I'm describing.
• #47761 is about deleting individual sessions from claude.ai/code. This issue is about Remote Control environments — the dropdown entries that represent registered local machines. Different entity, different list.
• #39914 is specifically about the Claude mobile app. This issue is about the web UI at claude.ai/code.

The concern here is unaddressed by all three: after running claude remote-control multiple times on a local machine, dead environments accumulate in the claude.ai/code environment dropdown with no way to remove them — a UX/clutter problem on the web, separate from the connection bug, from regular session deletion, and from the mobile app.

still a problem - dead environments are pilling up with no way to delete them

Still a problem – specifically in mobile app!

How has this not been added yet

I confirm, this is still an issue on mobile. PR still showing and without a possibility to delete them.

Adding a data point on what actually creates these stale environments — the thread covers the symptom well but not the trigger.

Setup: headless Linux box, Claude Code 2.1.224, nine claude remote-control --spawn worktree servers under systemd (Restart=always), one per project directory, running continuously for weeks.

The environment ID is stable across ordinary restarts. Each service has restarted 38 times in two weeks — process exits, systemd restarts it 30s later from the same directory — and the environment ID is unchanged every time. That matches the observation in #78695 that identity is keyed per (machine, directory).

It rotates on whole-fleet events, and all environments rotate together. Only two changes in two weeks, and in both cases all nine environments got new IDs within the same second:

1. A clean OS reboot. Every service received a graceful SIGTERM and systemd logged Stopped for each one before the box went down. New IDs on the way back up.
2. An extended internet outage. The processes exit by design after ~10 minutes without network (documented behaviour), crash-looped while the link was down, and came back with new IDs.

The reboot case is the interesting one: a completely graceful shutdown does not preserve the environment identity. So "exit cleanly" is not a workaround — there is no shutdown discipline that avoids this. Every reboot permanently adds one dead environment per directory, and they can never be removed.

Why this is worse than clutter: a stale environment keeps advertising the session count it had at the moment it died. One of mine currently shows 8 of 32 while the live environment for the same directory shows 0 of 32. The two rows are otherwise identical — same directory, same branch — so in the picker the dead entry looks more alive than the real one. Selecting it leaves the mobile app on "Allocating sandbox" indefinitely, with no error and no timeout.

Two changes that would each fix the practical problem independently of the delete feature requested here:

• Show environments as offline when no server is connected, and stop displaying a stale session count for them.
• Fail fast with an error when a client targets an environment with no live server, instead of spinning on "Allocating sandbox" forever.

Just resubscribed to Claude after refunding my first annual subscription due to atrocious performance and usage limits. Considering doing this again! ChatGPT app has this out of the box!

How is this still not supported?

Remote Control is incredibly frustrating in its current state. Stale environments accumulate permanently, show 0 of 32, and there is apparently no way to delete or revoke them from Desktop, web, mobile, or the CLI.

Basic lifecycle management should not be missing from a feature like this. Please add a proper delete/revoke mechanism and automatic cleanup for dead environments. This should be table stakes.

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.

Quite annoying to always have to guess which env is the alive one.

<img width="590" height="1278" alt="Image" src="https://github.com/user-attachments/assets/11089fbd-ef11-42ea-8f07-d8ee4f18c6dc" />

+1 — same issue here. After a computer restart, the disconnected session just sits in the list with no delete option, in the CLI or on claude.ai/code. Archiving is the only workaround and it doesn't remove the entry. A per-entry "Remove" action or a bulk "clean up disconnected" button would be a big help for anyone using Remote Control regularly.

I found an undocumented workaround that may help until Anthropic adds a proper UI/CLI delete option.
This lists your environments, then lets you remove a stale one. It reads the local Claude OAuth token automatically and doesn’t print it:

GET https://api.anthropic.com/v1/environments
DELETE https://api.anthropic.com/v1/environments/bridge/<environment_id>
Authenticate with your Claude OAuth token from ~/.claude/.credentials.json

python3 - <<'PY'
import json, os, urllib.request

token = json.load(open(os.path.expanduser("~/.claude/.credentials.json")))["claudeAiOauth"]["accessToken"]
headers = {
  "Authorization": f"Bearer {token}",
  "anthropic-version": "2023-06-01",
  "anthropic-beta": "environments-2025-11-01",
}
base = "https://api.anthropic.com/v1/environments"

envs = json.load(urllib.request.urlopen(
  urllib.request.Request(base, headers=headers)
))
for e in envs["data"]:
  print(e["id"], e.get("name", ""), e.get("status", ""))

env_id = input("\nStale env_ ID to delete: ").strip()
req = urllib.request.Request(
  f"{base}/bridge/{env_id}", headers=headers, method="DELETE"
)
print(urllib.request.urlopen(req).read().decode())
PY

I’d stop any active claude remote-control bridge first, then delete only the stale env_... entry. It worked for me, but it’s undocumented, so a proper “remove disconnected environments” action is still badly needed.

@phishsticks works like a charm!

Also hitting this on Windows.

Setting up Remote Control on one machine (Windows 11, Claude Code 2.1.241 from npm, always the same directory) left 11 environments registered on my account within about an hour, purely from restarting the supervisor while testing. They all show the same hostname and the same path, and most still render as online, so the "Choose environment" list is unusable: you cannot tell which entry is the live one.

There is no way to remove them: nothing in the picker at claude.ai/code (the rows are select-only), nothing under Settings -> Claude Code, no swipe or long-press in the iOS app, and no CLI command.

One detail that may be worth documenting, because it makes the accumulation much worse:

• claude rc --no-create-session-in-dir creates a new environment on every start. With no pre-created session there is nothing recorded in bridge-pointer.json, so there is nothing to re-attach to.
• claude rc --name <x> (keeping the pre-created session) does re-attach and keeps the same environment across restarts. Verified: bridge-pointer.json holds the same environmentId before and after a restart.

So the flag that looks like the tidy option (no placeholder session cluttering the session list) is exactly the one that spams the environment list. Until there is a delete action, a warning in claude rc --help would already help a lot.

Possible work-around:

Stale remote control environments can be deleted using a browser (claude.ai/code). The tag for stale env has 3 vertical dot icon that opens a menu with a Delete button.

If /remote-control is used in a claude session, then you can see the session come and go in the mobile app under Code.

I learned about "claude rc" from the newsletter. It should have recommended using /remote-control in a session for better control.

I also set:
❯ Enable Remote Control for all sessions false

Controlling remote control manually is better for me at this time - quite new at this business.

FYI: Claude can't read these comments. Indicated concern that Anthropic is not reading comments. Was told that I was being unfair. Salty Claude.