[BUG] Remote Control: --no-create-session-in-dir never writes bridge-pointer.json, so every restart rotates the environment and kills its live sessions

Preflight Checklist

• [x] I have searched existing issues and this hasn't been reported yet
• [x] This is a single bug report
• [x] I am using the latest version of Claude Code

What's Wrong?

claude remote-control --no-create-session-in-dir never writes ~/.claude/projects/<slug>/bridge-pointer.json. That file is the only thing that makes the environment survive a restart: at startup the bridge reads environmentId from it and asks the backend to reuse it (reuseEnvironmentId). Without the file, every restart registers a new environment. The sessions served by the old environment are then dead: posting to one returns 409 session_not_active, and the new bridge never picks them up.

In other words, the environment's identity depends on whether a session was pre-created in the directory at startup. It does not depend on whether any sessions exist. Three probes on the same machine and version show this:

| Probe | Pointer written | Environment after restart | Sessions after restart |
|---|---|---|---|
| Default (anchor pre-created), then a second session spawned, anchor archived, restart | yes, at startup | same env id | archived anchor: resume attempt fails, non-fatal; second session: re-attached on its next message |
| --no-create-session-in-dir, no sessions, restart | no | new env id | n/a |
| --no-create-session-in-dir, one session created via the Sessions API and attached (Capacity: 1/3), restart | no (still absent while the session was attached) | new env id | the session is gone: 409 session_not_active |

The first probe shows that the anchor session itself is not needed after startup: once the pointer exists, you can archive the anchor, restart the bridge, and still get the same environment back, with no new anchor created. So the pointer write seems to depend on the pre-created session only by accident, not by design.

A related consequence: tools that find running bridges through bridge-pointer.json cannot see an anchorless bridge at all.

What Should Happen?

The bridge should write bridge-pointer.json (with an empty sessionId, which the pointer schema already allows: the writer uses sessionId: <id> ?? "") whenever it registers an environment, whether or not it pre-creates a session. A restarted --no-create-session-in-dir bridge would then reuse its environment the same way a default bridge does.

Error Messages/Logs

# probe 3: --no-create-session-in-dir, session attached, SIGTERM, restart
run 1: environment=env_019Gcc1…   (Capacity: 1/3, no bridge-pointer.json on disk)
run 2: environment=env_018zGMi…
POST /v1/code/sessions/<session>/events -> 409 {"type":"session_not_active"}

Steps to Reproduce

1. mkdir /tmp/rc && cd /tmp/rc && git init && git commit --allow-empty -m init
2. claude remote-control --name probe --spawn same-dir --capacity 3 --no-create-session-in-dir and note the environment=env_… in the link line.
3. Start a session in that environment (from claude.ai/code, or by POST /v1/code/sessions with that environment_id) and wait until the bridge shows Capacity: 1/3.
4. Check ~/.claude/projects/-tmp-rc/bridge-pointer.json: it does not exist.
5. Stop the bridge with SIGTERM (what systemctl restart sends) and start it again with the same command: the link line shows a different env_…, and the session from step 3 can no longer be reached.

For comparison, run steps 2–5 without --no-create-session-in-dir. The pointer is written at startup, and the environment id survives the restart, even after the pre-created session has been archived.

Claude Model

Not model-specific

Is this a regression?

I don't know

Claude Code Version

2.1.280

Platform

Anthropic API (claude.ai subscription, OAuth)

Operating System

Linux (Ubuntu, kernel 7.0), bridges run as systemd user units

Terminal/Shell

bash (non-interactive, no TTY)

Additional Information

Why it matters: an always-on bridge under systemd is the natural place for --no-create-session-in-dir, because nobody needs an idle pre-created session there. But choosing that flag currently means losing the environment, and every live session in it, on each restart or package update.

Related, but none of them covers this case:

• #87413: unstable environment identity for always-on bridges
• #90777, #93345: activeSessionIds is rarely or never persisted
• #93409: a stale pointer re-adopts a deleted session on every launch (we see the same non-fatal resume attempt for an archived anchor)
• #56977 / #50884: environment ids should be sticky across restarts