[BUG] Remote Control: new session requests silently reused into last open session once environment hits its concurrency cap (32/32)

Status Open
Reported on v2.1.204
Maintainer reply None cached
Activity 1 comment · opened Jul 23, 2026

Environment

  • Claude Code 2.1.204, mobile app connecting via Remote Control to a claude remote-control --name <redacted> daemon
  • Debian 12 (bookworm) container on a Linux 6.12 host (TrueNAS)
  • Environment picker shows this environment's session count as "N of 32" (screenshot on request)

Problem

The remote-control environment has a hard cap of 32 concurrent sessions. Reaching that cap is visible only as a counter ("26 of 32", etc.) in the environment picker — there is no warning as it climbs and no explicit block at 32.

When a new session is requested from the mobile app after the cap is already reached, the request is not rejected, not queued, and not surfaced as an error. Instead the new conversation is silently appended into whichever session was most recently open, interleaving an unrelated task/conversation into that session's transcript with no indication to the user that this happened. The user only discovers it after the fact, by noticing the "new" session's replies don't match what they asked and instead reflect the older session's context.

This is likely related to (but distinct from) #80311, which covers sessions dying permanently on limit-hit and on disconnect — that issue is about existing sessions being killed. This one is about new session requests being misrouted into an existing session once the concurrency cap is hit, with no error surfaced.

Expected behavior

One of:

  • Reject the new session request with a visible error ("session limit reached, close a session or open a new environment"), or
  • Queue the request until a slot frees up, or
  • Prompt the user to open a new environment (the picker already has a "Create new environment" affordance for this),

but never silently reuse an unrelated existing session as a drop target.

Impact

Conversations get silently cross-contaminated once a busy environment is at capacity, with no error to alert the user it happened.

View original on GitHub ↗

This issue has 1 comment on GitHub. Read the full discussion on GitHub ↗