Agent interrupt: direct send while running leaves session stuck when tools are active

[vedranjukic]

Bug Description

When sending a new prompt while the agent is actively running (direct interrupt), the OpenCode session can get stuck in a half-aborted state if the previous session had tools actively executing (e.g., Bash commands, terminal reads).

The bridge's handleStartAgent correctly aborts the old session via POST /session/:id/abort and starts a new one. However, when the previous session has in-flight tool executions, the abort doesn't cleanly terminate them. The new session starts (1 claude_message received) but then goes permanently silent — no more agent output, no error, no exit.

Steps to Reproduce

1. Start an agent on a thread (e.g., "start the app again")
2. Wait for the agent to begin executing tools (Bash, terminal operations)
3. While tools are running, send a new prompt (e.g., "let's start the project on port 5000") via the queued prompt Play button
4. The new prompt is sent directly to the bridge (no stop_agent first)
5. The bridge aborts the old session and starts a new one
6. The new session emits 1 claude_message (init) then goes completely silent

Expected Behavior

The old session should be cleanly terminated (including running tools), and the new session should start and produce output normally.

Actual Behavior

The new session gets stuck after initialization. No claude_message, claude_error, or claude_exit events are emitted. The thread remains in running status indefinitely until the activity timeout fires (5 minutes).

Root Cause Analysis

The OpenCode serve /session/:id/abort endpoint may not fully clean up running tool processes. When the bridge's poll loop detects the aborted session's status change, there's a race with the new session starting:

1. Bridge aborts old session (has running Bash/terminal tools)
2. 2-second drain delay passes
3. Bridge starts new session via sendPrompt
4. Old session's tool processes may still be running in OpenCode
5. New session gets stuck (possibly blocked by the old session's resources)

Current Workaround

Use the Stop button first, wait for the thread to reach completed, then send the new prompt. The stop-then-send flow via stop_agent → stopClaude is more aggressive and cleans up properly.

Investigation Notes

• The bridge's handleStartAgent adds the old session to suppressedAborts before aborting
• A 2-second drain delay was added to let in-flight poll callbacks exit
• The activeThreads.delete(threadId) stops the old poll loop, but in-flight callbacks may still fire
• The new session's poll loop starts but may conflict with lingering old session state in OpenCode serve

Related Work

This was discovered during the fix for destroyed proxy sandbox recovery (branch fix/proxy-recovery-and-agent-interrupt). The direct interrupt approach was reverted in favor of stop-then-send for reliability.