Bug: Options auto-select during session resume/respawn

[craigvandotcom]

Description

When the agent presents options in the UI and the user takes time to respond, the system sometimes appears to auto-continue as if an option was already selected. The user sees the conversation as "finished", then suddenly work appears as if they had responded.

Root Cause Analysis

After investigating the logs and source code, this appears to be a race condition in session resume with message queue timing:

Flow:

1. Agent presents options, finishes responding, waits for user input via message queue
2. Daemon respawns the Claude process (seen repeatedly in logs with --resume)
3. New process:
   • Resumes from existing Claude Code session
   • Calls await opts.nextMessage() at claudeRemote.ts:85
   • If message exists in queue or arrives during respawn, processes immediately

Contributing Factors:

• SESSION_READY_TIMEOUT_MS = 10000 (10s) in sync.ts sends messages after timeout even if not "ready"
• Multiple --resume flags in daemon logs showing frequent process restarts
• No idempotency checks between message queue and session resume state

Relevant Files:

• src/claude/claudeRemote.ts:85 - Initial message wait on resume
• src/api/apiSession.ts:140-144 - Message callback processing
• infrastructure/happy-web/sources/sync/sync.ts:287-289 - Ready timeout logic

Reproduction

1. Start a conversation with an agent
2. Get to a point where options are presented
3. Wait ~10+ seconds before selecting an option
4. Observe if work continues without explicit user selection

Potential Fixes

1. Add a "waiting for user input" lock state when options are presented
2. Implement idempotency/deduplication between session resume and pending messages
3. Clear message queue on session resume to prevent stale message processing
4. Add confirmation mechanism before processing option selections after delay

[craigvandotcom]

Update: Attempted a fix using session timestamp filtering (sessionStartedAt) to ignore stale messages on resume. The approach:

1. Track when session started with timestamp
2. Filter messages with createdAt < sessionStartedAt
3. Reset timestamp on resetSessionStartTime() called during remote launch

Result: Did not resolve the issue. The phantom execution still occurs - agent continues working after completing a response, and the work only becomes visible when user sends next message.

The root cause appears deeper than message timestamp filtering. May need to investigate the daemon respawn mechanism and how --resume interacts with pending message queues.