"Another live session" duplicate-name check fires against a session's own current name, seconds after a manual rename

Bug: "Another live session" duplicate-name check fires against a session's own current name, seconds after a manual rename

Environment

• Claude Code version: 2.1.232
• Build time: 2026-08-13T16:45:27Z
• Commit: a640e96821ee108129c1eed84b67aac4e7cff181
• OS: macOS 26.6 (build 25G72), Apple Silicon (arm64)
• Install method: native installer (~/.local/bin/claude -> ~/.local/share/claude/versions/2.1.232)

What happened

A long-running session in one project (~/claude-code) has carried the custom name "ops" since 2026-07-03 (set via /rename ops back on version 2.1.199, and stable across many version upgrades since). After upgrading to 2.1.232, this same session started firing a "duplicate session name" notice and force-renaming itself — even though nothing about the session's own name had changed, and no other active session on the machine is named "ops".

Exact system notices from the session transcript (~/.claude/projects/-Users-docchang-claude-code/15c7236c-186a-47f6-a9c9-0672d48b2648.jsonl):

2026-08-14T04:20:34.753Z  "Another live session on this machine goes by \"ops\", so this session is now \"ops-composed-bumblebee\". Use /rename to pick a different name."

I then ran /rename ops manually, which succeeded ("Session renamed to: ops"). 11 seconds later, the exact same notice fired again, against the exact same session:

2026-08-14T04:27:17.157Z  "Another live session on this machine goes by \"ops\", so this session is now \"ops-sorted-hellman\". Use /rename to pick a different name."

Why this looks like a bug, not a real collision

I checked the transcripts of every other session active on the machine at the time (across ~8 other project directories: ad-ingest, Desktop/Unity Builds, left-vs-right-4, hexario-revive, mochibits-unity-sdk, Desktop/Fertility, Development/session-agents) — none of them carry the name "ops." There is no genuine second live session that this one should be colliding with.

The fact that it re-triggered 11 seconds after a fresh, successful /rename ops — against the very session that had just (re-)claimed the name — strongly suggests the duplicate-name check is comparing against a stale/ghost registration (e.g. a session that already exited but wasn't cleaned out of wherever "live" session names are tracked) rather than truly-live sessions, or is otherwise mis-scoping "live" in a way that includes records that shouldn't count.

Expected behavior

A session that already legitimately owns a name, and has not changed processes/PID, should not be treated as colliding with itself (or with a name it just successfully reclaimed via /rename) moments later.

Workaround

Downgraded to 2.1.231 and set "autoUpdates": false in ~/.claude.json to stop the auto-updater from pulling back to 2.1.232.

Additional notes

Not related to the "Remote Control" feature (also new in this build) — this session was not using Remote Control, no other terminal had claimed it, and the collision message is a separate "duplicate session name" notice, distinct from the Remote Control "another Claude Code on this machine already has Remote Control for this conversation" message that also exists in the 2.1.232 binary.