New Chat creates two backend sessions and delivers the first message to both (v1.37.3, macOS, npm)

Environment

• CloudCLI: @cloudcli-ai/[email protected] (npm global), server via cloudcli start (launchd, localhost:3001)
• OS: macOS (Intel), Node v24.12.0
• Provider CLI: Claude Code 2.1.258
• Access: single browser tab (desktop UI)

Summary

Opening one new chat and sending one message results in two backend sessions. Both receive the full message, both spawn their own Claude process, and both work on the same task in parallel. This happened on both new chats I opened today (2/2); messages sent to an existing session never duplicate.

Repro

1. Click New Chat
2. Type or paste a message, send
3. Two sessions appear in the sidebar, both start answering the same message

Evidence (two incidents, 2026-09-10, UTC)

Incident 1 — one new chat, one send at 04:12:10.033Z:

• ~/.cloudcli/auth.db table sessions has two rows created at 04:09:03 and 04:09:06 — 3s apart, both before the message was sent
• Both provider JSONL transcript files begin with queue-operation: enqueue of the same content at the same millisecond (04:12:10.033Z)

Incident 2 — one new chat, one send:

• Two sessions rows created at 06:54:57 and 06:55:01 (4s apart, again before send)
• Enqueues into the two transcripts at 06:55:53.858Z / 06:55:54.102Z (244ms apart)
• Both Claude processes share the same parent (the cloudcli start daemon), each spawned as claude --resume <id> for the same turn; an independent observer plugin (claude-mem) also spawned two observer sessions pairwise ~20s later, corroborating that two live sessions existed

Suspected cause

Session creation appears non-idempotent. The 3–4s gap between the two sessions rows (always before the send) looks like a timeout-retry of the create-session call on a slow local server. Once two sessions exist for the same chat, the outgoing message is delivered to both (both bindings are treated as active).

Impact

• Double token consumption on every new chat
• Two agents executing the same task concurrently — risk of conflicting file writes
• Confusing UX (two windows answering one message)

Workaround

After clicking New Chat, check the session sidebar and delete the extra empty session before sending.

Happy to provide the auth.db rows, transcript excerpts, or logs if useful.

Possibly related: #1005 (key PTY sessions by client identity and pre-assign Claude session ids).