fix(tui): queue busy prompts after interrupt - #34530
Conversation
Sorry, something went wrong.
|
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:
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. |
Sorry, something went wrong.
Issue for this PR
Closes #9291
Related to #10966, #30494
Type of change
What does this PR do?
The full-screen TUI could accept another normal prompt while the current session was still busy. That path sent session.prompt immediately, but the runner does not start ordinary new work while a run is already active, so the typed prompt could appear accepted while not actually running next.
This changes the TUI prompt behavior to snapshot normal prompts submitted during a busy session into a local queue. When the session transitions back to idle, it flushes one queued prompt. Pressing Esc with text in the prompt now queues that text before aborting the active response, so the latest user message is preserved and runs after the interrupt.
Shell mode keeps its existing behavior.
How did you verify your code works?
I also ran bun run --cwd packages/tui test. The package suite reached existing tests and failed on an unrelated Windows path expectation in test/runtime.test.tsx (~/project expected, ~\project received).
Screenshots / recordings
No recording. This is a TUI behavior change covered by the queue/escape unit tests.
Checklist