[BUG] /clear typed in one CLI session is delivered to another concurrently-running session in the same cwd, causing context loss

Summary

When multiple interactive claude CLI sessions run concurrently in the same working directory, a /clear typed in one terminal is sometimes also delivered to a different session that is busy mid-turn. The receiving session gets it as a queued interrupt ("The user sent a new message while you were working: /clear"), and when its turn ends the queued /clear can be dequeued and executed — wiping the conversation context of a session the user never typed into.

Environment

• Claude Code v2.1.168–2.1.170 (first occurrence on 2.1.168; never observed on 2.1.133–2.1.167 despite the same heavy multi-session workflow)
• Windows 11 Pro (10.0.26200), CLI entrypoint, Windows Terminal
• 4–7 concurrent interactive sessions in the same cwd

Steps to reproduce (as observed; timing-dependent, 4 occurrences in 3 days)

1. Run claude in two terminals (A and B) in the same project directory.
2. In A, start a long-running turn (agent busy executing tools).
3. In B, type /clear (B switches to a fresh session as expected).
4. A simultaneously receives the same /clear as a queued interrupt. If A's turn ends while it is still queued, it is dequeued and executed, clearing A's context.

Not 100% reproducible — appears timing-dependent.

Evidence from session jsonl files

Receiving side (session A, busy running a task):

{"type":"queue-operation","operation":"enqueue","timestamp":"2026-06-10T06:14:52.102Z","content":"<command-name>/clear</command-name>..."}
{"type":"queue-operation","operation":"dequeue","timestamp":"2026-06-10T06:14:56.390Z"}
{"type":"user","timestamp":"2026-06-10T06:14:56.431Z","message":{"content":"<command-name>/clear</command-name>..."}}   <- executed

Typing side (session B): a new session file whose head contains the same /clear (local-command-caveat transcription) stamped 2026-06-10T06:14:51.746Z — 0.4s before the enqueue above.

After execution, the agent in session A continued the task with wiped context (it remarked it could no longer access earlier cached file reads).

Three more occurrences with the same signature (a /clear EXEC record in one session file + an enqueue of the same /clear into another session within 0.4s):

• 2026-06-08T08:54:42Z
• 2026-06-10T05:23:04Z
• 2026-06-10T05:33:17Z

In two of them the receiving session survived (the queued command was removed via queue-operation: remove, or was never executed).

Impact

• Context loss in a session the user never typed /clear into (destroyed an in-progress task run)
• Confusing UX: the agent is told "the user sent /clear" when the user didn't

Expected behavior

/clear should only affect the terminal/session where it was typed.