fix(opencode): CLI queued prompt drain after Esc interrupt

[jrb00013]

Issue for this PR

Closes #33812 (CLI / opencode run scope)

Type of change

• Bug fix
• New feature
• Refactor / code improvement
• Documentation

What does this PR do?

CLI-only — the web app follow-up queue fix lives in #33808; this PR no longer touches packages/app.

In direct CLI mode (opencode run), interrupt only called session.abort on the server and did not abort the active turn's local AbortSignal, so the prompt queue could stay blocked behind an in-flight turn. This wires Esc interrupt to:

1. Abort the active turn's local signal so runPromptQueue can finish the current turn and drain the next queued prompt
2. Expose pending queue depth via bindInterrupt for the runtime interrupt handler
3. Show a footer status hint when interrupting with queued prompts (e.g. interrupting · 1 queued)

Stacks cleanly on top of #33808 for the shared issue.

How did you verify your code works?

• bun test test/cli/run/runtime.queue.test.ts — 17 pass, including abort-active-turn + pending-queue count + queued prompt still runs
• bun typecheck in packages/opencode

Manual checks still needed:

• CLI direct mode: queue while running, double-press Esc, confirm the next queued prompt runs and the footer shows the interrupt hint

Screenshots / recordings

Terminal captures via rudycanshoot (attached in PR comments):

• opencode-fix-queued-interrupt-runtime-queue-test.png
• opencode-fix-queued-interrupt-typecheck.png

Checklist

• I have tested my changes locally
• I have not included unrelated changes in this PR

[github-actions]

Thanks for your contribution!

This PR doesn't have a linked issue. All PRs must reference an existing issue.

Please:

1. Open an issue describing the bug/feature (if one doesn't exist)
2. Add Fixes #<number> or Closes #<number> to this PR description

See CONTRIBUTING.md for details.

[github-actions]

The following comment was made by an LLM, it may be inaccurate:

Based on my search, I found several related PRs that address similar interrupt and queue handling issues:

Potentially Related PRs:

1. fix(tui): queue busy prompts after interrupt #34530 - fix(tui): queue busy prompts after interrupt

   • Directly related: handles queuing prompts after interrupt in the TUI

2. fix: preserve followup queue on ESC interrupt #33808 - fix: preserve followup queue on ESC interrupt

   • Directly related: addresses preserving the followup queue when ESC interrupts, which is the web app aspect of this PR

3. fix(tui): restore ESC interrupt for delegated subagent sessions #32767 - fix(tui): restore ESC interrupt for delegated subagent sessions

   • Related: handles ESC interrupt behavior for sessions

4. feat(opencode): interrupt a running subagent — steer / cancel / abort #32425 - feat(opencode): interrupt a running subagent — steer / cancel / abort

   • Related: broader interrupt/abort feature for sessions

5. fix(tui): recover stuck double-esc aborts by restarting worker #31079 - fix(tui): recover stuck double-esc aborts by restarting worker

   • Related: handles double-ESC abort scenarios in the TUI

These PRs share the same domain of interrupt handling, queue management, and ESC key behavior. PR #34530 and #33808 are particularly close in scope to the current PR #35008, addressing queue behavior after interrupt in both the TUI and web app contexts.

[github-actions]

Thanks for updating your PR! It now meets our contributing guidelines. 👍

[jrb00013]

[jrb00013]

Overlap with #33808

I compared this PR against #33808 (same issue, #33812). Here's the exact breakdown:

Identical / equivalent (web app)

Both PRs fix the same root cause in packages/app/src/pages/session.tsx:

Change	#33808	#35008
Remove if (followup.paused[sessionID]) return from the auto-send effect	yes	yes
Stop setting followup.paused on Esc abort	yes (onAbort: undefined)	yes (omit onAbort prop)

Functionally the same: Esc only interrupts the current turn; queued follow-ups resume via the existing idle auto-send path.

Only in #33808

• packages/app/src/pages/session/composer/session-composer-region.tsx — makes onAbort optional and passes onAbort: undefined through the composer region props.

On current dev, follow-up wiring goes through createSessionComposerRegionController + PromptInput directly (no onAbort on composer region), so that file may already be obsolete relative to this branch. If #33808 merges first, this PR shouldn't need that hunk.

Only in #35008

• packages/opencode/src/cli/cmd/run/runtime.queue.ts — bindInterrupt aborts the active turn's AbortController
• packages/opencode/src/cli/cmd/run/runtime.ts — call abortActiveTurn before session.abort on Esc
• packages/opencode/test/cli/run/runtime.queue.test.ts — test that aborting the active signal still drains the next queued prompt

This is the direct CLI mode (opencode run) path: interrupt previously only hit the server abort API and could leave the local prompt queue stuck with a queued message visible in the footer.

Not covered by either PR

• Legacy TUI (packages/tui) — separate interrupt/queue behavior; see also fix(tui): queue busy prompts after interrupt #34530
• Server-side delivery: "queue" promotion after interrupt (core session runner)

Suggested path for maintainers

1. If only the web app fix is wanted: fix: preserve followup queue on ESC interrupt #33808 is sufficient for the app; this PR could be narrowed to CLI-only (+ test) on top of that.
2. If both app + CLI matter: this PR is a superset; merging it would subsume fix: preserve followup queue on ESC interrupt #33808's session.tsx changes (composer-region hunk may still be worth pulling from fix: preserve followup queue on ESC interrupt #33808 if that refactor lands separately).

Test screenshots attached in thread. Local verification:

• bun test test/cli/run/runtime.queue.test.ts — 17 pass
• bun typecheck in packages/opencode

[jrb00013]

Scope update: dropped the duplicate packages/app follow-up fix — #33808 already covers that surface.

This PR is now CLI-only (opencode run):

• bindInterrupt aborts the active turn's local AbortSignal (not just server session.abort)
• pending queue depth exposed for the interrupt handler
• footer shows interrupting · N queued when Esc fires with prompts waiting
• test asserts pending count + queued prompt still drains after abort

Stacks on #33808 for #33812. Happy to rebase once that lands.

[github-actions]

Automated PR Cleanup

Thank you for contributing to opencode.

Due to the high volume of PRs from users and AI agents, we periodically close older PRs using automated criteria so maintainers can focus review time on the most active and community-supported contributions.

This PR was closed because it matched the following cleanup criteria:

• The PR was created more than 1 month ago
• The PR had fewer than 2 positive reactions
• Positive reactions are counted as thumbs-up, heart, celebration, or rocket reactions on the PR

PRs created within the last month are not affected by this cleanup.

If you believe this PR was closed incorrectly, or if you are still actively working on it, please leave a comment explaining why it should be reopened. A maintainer can review and reopen it if appropriate.

Thanks again for taking the time to contribute.