[BUG] Remote Control: web and mobile derive the environment label from different payload fields, producing indistinguishable duplicates for subdirectory environments

Summary

Running claude remote-control in a tracked subdirectory of a git repo registers an environment whose label collides with the environment for that repo's root. The claude.ai/code environment picker shows two entries with the identical name and identical subtitle (machine name); the Claude mobile app shows the same two environments correctly and distinctly.

The two surfaces appear to label the environment from different fields of the same registration payload.

Cause

POST /v1/environments/bridge carries no name field at all. From --debug-file for a server started in <repo>/subproject (paths and names generalized):

[bridge:init] bridgeId=<uuid> dir=/home/user/projects/monorepo/subproject branch=dev gitRepoUrl=https://github.com/<owner>/monorepo machine=<host>
[bridge:api] POST /v1/environments/bridge -> 200 environment_id=env_…
[bridge:api] >>> {"machine_name":"<host>",
                  "machine_id":"<uuid>",
                  "directory":"/home/user/projects/monorepo/subproject",
                  "branch":"dev",
                  "git_repo_url":"https://github.com/<owner>/monorepo",
                  "max_sessions":32,
                  "metadata":{"worker_type":"claude_code"}}

Web labels the environment from git_repo_url; mobile labels it from directory. When the server's cwd is the repo root those two agree, so the inconsistency is invisible. It only surfaces for a subdirectory environment, where the same payload yields two different names depending on which client you open.

Observed across four concurrent environments — the three whose cwd is a repo root label identically on both surfaces; only the subdirectory one diverges:

| server cwd | directory basename | git_repo_url basename | web shows | mobile shows |
|---|---|---|---|---|
| projects/alpha | alpha | alpha | alpha | alpha |
| projects/beta | beta | beta | beta | beta |
| projects/monorepo | monorepo | monorepo | monorepo | monorepo |
| projects/monorepo/subproject | subproject | monorepo | monorepo ❌ | subproject ✅ |

Both entries are live and healthy (3/32 and 1/32 sessions), so this is not a stale-registration artifact — it is two distinct working environments that the web UI renders under one name.

Reproduction

1. In any git repo, run claude remote-control at the repo root.
2. In a second terminal, run claude remote-control in a tracked subdirectory of that same repo.
3. Open claude.ai/code and expand the Remote Control environment picker: the repo name appears twice, with no field distinguishing them.
4. Open the same picker in the Claude mobile app: the two entries are named for their directories and are distinguishable.

Expected

Consistent labelling across surfaces, and ideally some way to set it. Today there is none:

• --name sets the session title, per the documented precedence (--name → /rename → last meaningful message → myhost-graceful-unicorn). It is not part of the environment registration payload and has no effect on the picker's environment label. All four servers above pass distinct --name values.
• /rename renames a session within an environment, not the environment.
• Restarting re-mints the environment id but recomputes the same derived label.

Any of these would resolve it:

• Have web fall back to (or disambiguate with) directory when git_repo_url is not unique for the machine.
• Show directory or branch as the picker subtitle alongside machine_name.
• Accept an explicit environment name — e.g. --environment-name, or a settings key resolved per-directory.

Related

• #77372 — stale environments cannot be deleted. Same visible symptom (indistinguishable picker entries) but a different cause; both entries here are live.
• #88939 — configurable peer-registration session name. Adjacent motivation, different subsystem (cross-session messaging, not the environment registration).

Version

Claude Code v2.1.266