Repository navigation
TUI double-ESC loops and Desktop stop button fails to interrupt #24217
Description
Description
I am experiencing two related interruption issues on Windows with OpenCode v1.14.24: one in the TUI and one in the Desktop GUI. This happens when using DeepSeek V4 models via OpenCode Go or Ollama Cloud.
TUI: When I press ESC to interrupt an ongoing session, the UI enters a loop displaying:
ESC to interruptESC again to interruptESC interrupt
This cycles repeatedly and does not actually stop the running session.
Desktop: When a session is running, clicking the Stop button has no effect. The task continues and I cannot force it to stop.
These issues do not happen 100 % of the time, but they occur frequently enough to make the interrupt/stop functionality unreliable.
Possibly related issues:
- Desktop: v1.14.21 Desktop: Extreme lag, erratic behaviour, cannot stop task, cannot restart, cannot start new task #23968 (v1.14.21 — cannot stop task, UI freezes)
- TUI: Shell/session interrupt regression in 1.4.2 can leave TUI stuck and shutdown timing out #21743 (shell/session interrupt regression, ESC unreliable), Background agents cannot be force-interrupted/stopped via ESC #22638 (background agents cannot be interrupted via ESC), interrupt not working #14694 (interrupt not working on Windows)
Plugins
No response
OpenCode version
1.14.24
Steps to reproduce
TUI:
- Start a session (using DeepSeek V4 via OpenCode Go or Ollama Cloud) and let the agent begin working.
- Press
ESConce to trigger interruption. - Press
ESCagain when prompted. - Observe that the UI loops between "ESC to interrupt" / "ESC again to interrupt" / "ESC interrupt" without stopping the session.
Desktop:
- Start a session in OpenCode Desktop (using DeepSeek V4 via OpenCode Go or Ollama Cloud).
- While the agent is working, click the Stop button.
- Observe that the button does not stop the task; the session continues running.
Screenshot and/or share link
No response
Operating System
Windows 11
Terminal
PowerShell 7 / Windows Terminal (TUI); OpenCode Desktop (GUI)
Activity
github-actions commentedon Apr 24, 2026
This issue might be a duplicate of existing issues. Please check:
Since you've already referenced these issues in your report, the maintainers may decide to track this under one of them. If your issue covers a distinct new symptom (the ESC cycling loop specifically), it may still warrant a separate report.
shaofengluo-ctrl commentedon Apr 27, 2026
+1 — reproduces on v1.14.28 (Windows 11 24H2 / PowerShell 7.5.5 / Windows Terminal, TUI)
Confirming this is still broken in the latest release. Same symptoms as OP:
ESC to interrupt→ESC again to interrupt→ESC interruptcycling overlay but the agent loop keeps running and producing tokensCtrl+Ctwice or externaltaskkill /IM opencode.exe /Fto actually stopEnvironment
1.14.28Observation that matches #14694''s analysis
The failure rate correlates strongly with load — ESC lands reliably during idle/short outputs but gets swallowed during active token streaming or mid-tool-call. Consistent with the "opentui input pipeline drops events under high load" hypothesis from #14694.
Tracking: #14694 (root) → #21743 (1.4.2) → #22638 (opentui label) → #23968 (1.14.21) → #24217 (1.14.24+, still open in 1.14.28). No open PR addressing it as of today.
safa1018 commentedon May 10, 2026
+4
V1.14.46
cnDelbert commentedon May 28, 2026
version 1.15.11 the bug still exists.
andri commentedon Jun 3, 2026
This is insanly frusterating, I have to contantly kill opencode to stop the agent when its doing dumb things because ESC doesn't work unless you hit ESC 100 times.
github-actions commentedon Aug 3, 2026
To stay organized issues are automatically closed after 60 days of no activity. If the issue is still relevant please open a new one.
em commentedon Aug 12, 2026
Guys it's like having a car with a steering wheel covered in spiked and you're working on the paint job. How is this not your p000000? AI is dumb always doing the wrong thing, interrupting it to say its wrong is the most important feature to work flawlessly under any circumstances. Interrupt one esc has to mean force kill, 100% dead zero ai able to continue to mess things up more, instantly, always, until I can say what it's doing wrong now. Not queuing my messages, not waiting for it to finish breaking things...
opencode is the only harness that treats the user as waiting on the ai and your messages as a nice-to-have eventually rather than the dominant highest priority signal that kills takes over under any circumstance
for the longest time this was the main reason I could never use opencode, once again trying with v2 beta, loving so much about it, but this is just crazy broken and always has been and still is in v2
double-esc was the worst idea anyone has ever had, remove it, make esc kill. nobody wants a double esc. nobody cares about a session getting interrupted. it's not a mistake. i want to kill it and make the ai stop with one key.
kDuin commentedon Aug 25, 2026
Workaround
I found a workaround.
The issue seems to be related to ESC-key handling, which can be slightly delayed in some terminals.
I am using tmux on WSL with Powershell and Termux (both via SSH).
I was able to confirm the delayed ESC for my case with
showkey -a:ESC is detected by showkey only after a very brief delay, while other keys are detected instantly.
Re-mapping the
session_interruptkeybinding to something else worked. I used CTRL+/ (and CTRL+_ which emit the same sequence code).The keybinding can be overriden in
~/.config/opencode/tui.json{ "$schema": "https://opencode.ai/tui.json", "keybinds": { "session_interrupt": ["escape", "ctrl+/", "ctrl+_"] } }After adding this, opencode interrupts the session instantly when pressing CTRL+/ twice.
A long term-fix might be to allow longer delay between the ESC-presses in opencode?