[BUG] Remote Control: when a server is at --capacity, "new session" silently opens the most recent existing session instead of refusing

Summary

When a claude remote-control server is at its --capacity limit, starting a new session against it from claude.ai/code or the Claude mobile app does not fail. The client silently drops you into the most recently used existing session. The message you type lands in that conversation's context.

The picker already displays the count (e.g. 10/10), so the client knows the server is full. It should refuse to create a session and say so, rather than substituting another session.

Environment

• Claude Code: 2.1.257 (server), launched via launchd as claude remote-control --capacity 10 --name "Mac Mini"
• OS: macOS 26 (Darwin 25.5.0), Mac Mini 8 GB
• Clients: claude.ai/code in browser, Claude iOS app

Reproduction

1. claude remote-control --capacity 2 --name Foo
2. From claude.ai/code, create two sessions on Foo. Picker shows 2/2.
3. Create a third session on Foo and send a message.
4. Observe: no error. The message is delivered to one of the two existing sessions (the most recent), and the UI switches to it.

Expected behavior

Either of:

1. Client shows "Foo is at capacity (2/2). End or archive a session to start a new one." and does not send the message.
2. Client offers to end an idle session and then creates the new one.

Substituting a different conversation is the wrong default. It mixes unrelated work into an existing context and there is no signal that it happened.

Related

Sessions never reap themselves (#62069, closed as dup of #59403), so a long-lived server on a small machine reaches capacity within a day of normal use. That makes this fallback path the common case rather than an edge case.