Remote Control: "New session" on claude.ai/code attaches to the environment's most recent session instead of creating a new one

Status Open
Reported on v2.1.259
Maintainer reply None cached
Activity 2 comments · opened Sep 4, 2026

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 (2.1.259)

What's Wrong?

On claude.ai/code with a Remote Control environment selected in the composer (<machine> · <project>, server started with claude remote-control --spawn same-dir, CCR v2 multi-session bridge), clicking New (or the project's +) and sending a message does not create a new session. The URL switches to the environment's most recently used session (/code/session_…) and the message is appended there.

The bridge on the PC shows no new work/poll -> 200 workId=cse_… and no Spawning sessionId for a new session. It shows either nothing (the message went into a live session) or Previously completed workId=… was re-queued by the server (the message revived a session whose worker had already exited with a non-zero code).

Reproduced 4 times on 2026-09-04 (KST):

  1. 10:48 — the most recent session had crashed (exited status=failed exit_code=255). "New" + send → the dead session was re-queued and the message landed there.
  2. 11:01 — same session after the bridge had POSTed work/stop for it. Send hung at "connecting…" for 30+ s and never reached the bridge.
  3. 13:25 — the most recent session was alive and mid-turn (a long tool-using turn). "New" + a YouTube link → landed in that session (error_during_execution … result_type=user).
  4. 13:38 — fresh /code page with no session open. "New" + send → landed in the live session with the most recent activity.

What does work:

  • Archiving the most recent session in the sidebar → the very next "New" creates a real new session (Spawning … cse_<new>, reply in ~20 s). Verified twice.
  • Creating a session from the PC with POST /v1/code/sessions {title, environment_id, config:{cwd}} → the bridge spawns it within ~5 s and it works from the web.
  • Resuming older sessions from the sidebar works normally.

Browser localStorage/sessionStorage contain no per-environment "current session" key, so the routing seems to be in app state or server-side. The bridge was polling normally the whole time (capacity 32, 4–6 sessions running).

What Should Happen?

"New" with a Remote Control environment should always create a new session in that environment, regardless of whether the most recent session is alive, idle, or failed. Users should not have to archive the previous session to get a new one.

Error Messages/Logs

Bridge debug log (--debug-file), case 1 — user pressed "New" and sent at 10:48; no new session, old workId re-queued:

2026-09-04T01:34:05.303Z [DEBUG] [bridge:session] sessionId=[REDACTED] workId=cse_01Xt1nqxYfBEy5LhttNjRXSV exited status=failed duration=18m 43s
2026-09-04T01:34:05.328Z [DEBUG] [bridge:api] POST .../work/cse_01Xt1nqxYfBEy5LhttNjRXSV/stop force=false
2026-09-04T01:48:24.316Z [DEBUG] [bridge:api] GET .../work/poll -> 200 workId=cse_01Xt1nqxYfBEy5LhttNjRXSV type=session sessionId=[REDACTED]
2026-09-04T01:48:24.322Z [DEBUG] [bridge:work] Previously completed workId=cse_01Xt1nqxYfBEy5LhttNjRXSV was re-queued by the server, handling as new work
2026-09-04T01:48:25.747Z [DEBUG] [bridge:session] Spawning sessionId=[REDACTED] sdkUrl=https://api.anthropic.com/v1/code/sessions/cse_01Xt1nqxYfBEy5LhttNjRXSV

Case 3 — "New" + message while the latest session was mid-turn (13:25):

2026-09-04T04:25:50.985Z [DEBUG] [bridge:activity] sessionId=[REDACTED] result subtype=error_during_execution error="[ede_diagnostic] result_type=user last_content_type=n/a stop_reason=tool_use"
2026-09-04T04:26:52.533Z [DEBUG] [print.ts] end_session received, reason=archived
2026-09-04T04:27:01.254Z [DEBUG] [bridge:api] GET .../work/poll -> 200 workId=cse_019JgNXdxu57wtEvTXWL8g4j type=session   <- new session only after the user archived the old one

After archiving (11:05), the same composer produced a real new session:

2026-09-04T02:05:04.020Z [DEBUG] [bridge:api] <<< {"id":"cse_01QwGkuBb8wrs1eg8FiBzfLF","type":"work","environment_id":"env_…","state":"queued",...}
2026-09-04T02:05:04.731Z [DEBUG] [bridge:session] Spawning sessionId=[REDACTED] sdkUrl=https://api.anthropic.com/v1/code/sessions/cse_01QwGkuBb8wrs1eg8FiBzfLF

Steps to Reproduce

  1. On Windows, run claude remote-control --spawn same-dir (default capacity) in a project directory.
  2. On claude.ai/code, create a session in that environment and use it (send any message). Leave it open or let it finish; it can also be a session whose worker crashed.
  3. Go back to /code (or click the project's + / New), keep the same Remote Control environment selected, type a message, send.
  4. Observe: the URL becomes the previous session's URL and the message is appended there; the bridge log shows no new Spawning.
  5. Archive that previous session in the sidebar, repeat step 3 → a new session is created.

Claude Model

Fable 5.1 (also reproduced with the default model)

Is this a regression?

Not sure — the sidebar layout of claude.ai/code changed the same day (sessions now grouped by day), which suggests a recent web deploy.

Last Working Version

Unknown

Claude Code Version

2.1.259 (native install)

Platform

Windows 10 Pro 10.0.19045, Chrome (claude.ai/code). Plan: Max.

View original on GitHub ↗

This issue has 2 comments on GitHub. Read the full discussion on GitHub ↗