[UX] Ctrl+C should not exit OpenCode - conflicts with universal copy shortcut #4837

Open
opened 2026-02-16 17:45:38 -05:00 by yindo · 8 comments
Owner

Originally created by @SYRS-AI on GitHub (Jan 12, 2026).

Originally assigned to: @kommander on GitHub.

Description

Pressing Ctrl+C in OpenCode immediately exits the application. This is extremely frustrating because Ctrl+C is the universal copy shortcut on Windows (and commonly used on Linux too).

Users frequently press Ctrl+C out of habit when trying to copy text, and accidentally terminate their entire session - losing context and conversation history.

The Problem

Shortcut User Expectation OpenCode Behavior
Ctrl+C Copy selected text Exits application

This happens constantly during normal usage:

  • Copying error messages to search online
  • Copying code snippets from AI responses
  • Copying file paths or commands
  • General muscle memory from every other application

Expected Behavior

Option 1 (Recommended): Require double Ctrl+C or Ctrl+C twice within 1-2 seconds to exit

  • First Ctrl+C: Show message "Press Ctrl+C again to exit"
  • Second Ctrl+C: Actually exit

Option 2: Use a different exit shortcut

  • Ctrl+D (common in Unix terminals for EOF/exit)
  • Ctrl+Q (quit)
  • /exit or /quit command only

Option 3: Make Ctrl+C cancel current operation only (like Claude Code)

  • If AI is generating: Cancel generation
  • If idle: Do nothing or show exit hint
  • Never exit immediately on single Ctrl+C

Comparison with Other Tools

Tool Ctrl+C Behavior
Claude Code Cancels current operation, does NOT exit
Cursor Copy (normal IDE behavior)
VS Code Copy
Most CLI tools Interrupt current command, not exit shell

Environment

  • OS: Windows 11 (also affects Linux users)
  • Terminal: Windows Terminal, PowerShell, Git Bash

Related Issues

  • #7309 (mentions this issue but bundled with other requests)
  • #7074 (CTRL_C_EVENT handling)

This deserves a dedicated issue due to its significant impact on user experience. Accidental exits cause real productivity loss.

Originally created by @SYRS-AI on GitHub (Jan 12, 2026). Originally assigned to: @kommander on GitHub. ### Description Pressing `Ctrl+C` in OpenCode immediately exits the application. This is extremely frustrating because **Ctrl+C is the universal copy shortcut** on Windows (and commonly used on Linux too). Users frequently press Ctrl+C out of habit when trying to copy text, and accidentally terminate their entire session - losing context and conversation history. ### The Problem | Shortcut | User Expectation | OpenCode Behavior | |----------|------------------|-------------------| | `Ctrl+C` | Copy selected text | **Exits application** | This happens **constantly** during normal usage: - Copying error messages to search online - Copying code snippets from AI responses - Copying file paths or commands - General muscle memory from every other application ### Expected Behavior **Option 1 (Recommended):** Require double `Ctrl+C` or `Ctrl+C` twice within 1-2 seconds to exit - First `Ctrl+C`: Show message "Press Ctrl+C again to exit" - Second `Ctrl+C`: Actually exit **Option 2:** Use a different exit shortcut - `Ctrl+D` (common in Unix terminals for EOF/exit) - `Ctrl+Q` (quit) - `/exit` or `/quit` command only **Option 3:** Make Ctrl+C cancel current operation only (like Claude Code) - If AI is generating: Cancel generation - If idle: Do nothing or show exit hint - Never exit immediately on single Ctrl+C ### Comparison with Other Tools | Tool | Ctrl+C Behavior | |------|-----------------| | Claude Code | Cancels current operation, does NOT exit | | Cursor | Copy (normal IDE behavior) | | VS Code | Copy | | Most CLI tools | Interrupt current command, not exit shell | ### Environment - **OS**: Windows 11 (also affects Linux users) - **Terminal**: Windows Terminal, PowerShell, Git Bash ### Related Issues - #7309 (mentions this issue but bundled with other requests) - #7074 (CTRL_C_EVENT handling) This deserves a dedicated issue due to its significant impact on user experience. Accidental exits cause real productivity loss.
yindo added the opentui label 2026-02-16 17:45:38 -05:00
Author
Owner

@github-actions[bot] commented on GitHub (Jan 12, 2026):

This issue might be a duplicate of existing issues. Please check:

  • #7309: Missing /skills and /plugin commands, and Ctrl+C unexpected exit issue
  • #7074: [Windows] CTRL_C_EVENT not handled by bun (umbrella issue)
  • #6189: In the Windows system, pressing Ctrl+C will automatically exit the terminal
  • #2999: Provide means to disable Ctrl-C

For keybind-related issues, please also check our pinned keybinds documentation: #4997

Feel free to ignore if none of these address your specific case.

@github-actions[bot] commented on GitHub (Jan 12, 2026): This issue might be a duplicate of existing issues. Please check: - #7309: Missing /skills and /plugin commands, and Ctrl+C unexpected exit issue - #7074: [Windows] CTRL_C_EVENT not handled by bun (umbrella issue) - #6189: In the Windows system, pressing Ctrl+C will automatically exit the terminal - #2999: Provide means to disable Ctrl-C For keybind-related issues, please also check our pinned keybinds documentation: #4997 Feel free to ignore if none of these address your specific case.
Author
Owner

@carljuneau commented on GitHub (Jan 15, 2026):

Same here. I press Ctrl+C out of habit and get kicked out 4-5x a day. New user.

@carljuneau commented on GitHub (Jan 15, 2026): Same here. I press Ctrl+C out of habit and get kicked out 4-5x a day. New user.
Author
Owner

@stefanoallima commented on GitHub (Jan 15, 2026):

same the experience to copy text is very cumbersome

@stefanoallima commented on GitHub (Jan 15, 2026): same the experience to copy text is very cumbersome
Author
Owner

@HustCoderHu commented on GitHub (Jan 25, 2026):

Same here. If ctrl+d exits, why have ctrl+c too? Plus, ctrl+c is already bound to the 'clear input' function.

@HustCoderHu commented on GitHub (Jan 25, 2026): Same here. If ctrl+d exits, why have ctrl+c too? Plus, ctrl+c is already bound to the 'clear input' function.
Author
Owner

@shrwnsan commented on GitHub (Jan 30, 2026):

Workaround till its not default, set the following in opencode.json

"keybinds": {
  "app_exit": "ctrl+d,<leader>q"
}

Simply removes ctrl+c from default. HTH

@shrwnsan commented on GitHub (Jan 30, 2026): Workaround till its not default, set the following in `opencode.json` ``` "keybinds": { "app_exit": "ctrl+d,<leader>q" } ``` Simply removes ctrl+c from default. HTH
Author
Owner

@mcheiyue commented on GitHub (Feb 4, 2026):

相同问题确认 (Windows 11 + PowerShell)

环境:

  • 操作系统: Windows 11
  • 终端: Windows Terminal + PowerShell
  • OpenCode 版本: 最新版

问题描述:
在 Windows Terminal 中使用 OpenCode TUI 时,习惯性使用 复制内容,但每次都会导致 TUI 意外退出。这个操作习惯在 Windows 生态中非常根深蒂固,每天误触多次严重影响使用体验。

已尝试的解决方案:

  1. ✗ 修改 配置 - 无效(Ctrl+C 在到达 keybinds 处理器之前就被系统捕获)
  2. ✗ 修改 配置 - 无效(这只控制消息中断,不控制程序退出)
  3. ✗ 在 Node.js 包装层拦截 SIGINT - 无效(Windows 控制台直接广播信号给子进程)

根本原因:
根据我的调查,OpenCode 使用预编译的 二进制文件,Windows 控制台会直接将 (SIGINT) 广播给所有前台进程,配置文件和包装脚本层面都无法拦截。

临时 Workaround:
目前唯一有效的方案是使用 AutoHotkey 在系统级拦截 Ctrl+C:

#Requires AutoHotkey v2.0

IsOpenCodeRunning() {
    if ProcessExist("opencode.exe")
        return true
    return false
}

#HotIf IsOpenCodeRunning()
^c::
{
    ToolTip("Ctrl+C 已禁用 (使用 Ctrl+Q 或 Ctrl+D 退出)")
    SetTimer () => ToolTip(), -2000
    return
}
#HotIf

请求:
希望能够在配置文件中添加选项彻底禁用 Ctrl+C 退出行为,例如:

{
  "tui": {
    "disableCtrlCExit": true
  }
}

这个问题在 Windows 用户中非常普遍(参见 #2999, #10538),强烈建议作为高优先级 UX 改进项。

感谢团队的辛勤工作!期待官方解决方案 🙏

@mcheiyue commented on GitHub (Feb 4, 2026): ## 相同问题确认 (Windows 11 + PowerShell) **环境**: - 操作系统: Windows 11 - 终端: Windows Terminal + PowerShell - OpenCode 版本: 最新版 **问题描述**: 在 Windows Terminal 中使用 OpenCode TUI 时,习惯性使用 复制内容,但每次都会导致 TUI 意外退出。这个操作习惯在 Windows 生态中非常根深蒂固,每天误触多次严重影响使用体验。 **已尝试的解决方案**: 1. ✗ 修改 配置 - **无效**(Ctrl+C 在到达 keybinds 处理器之前就被系统捕获) 2. ✗ 修改 配置 - **无效**(这只控制消息中断,不控制程序退出) 3. ✗ 在 Node.js 包装层拦截 SIGINT - **无效**(Windows 控制台直接广播信号给子进程) **根本原因**: 根据我的调查,OpenCode 使用预编译的 二进制文件,Windows 控制台会直接将 (SIGINT) 广播给所有前台进程,配置文件和包装脚本层面都无法拦截。 **临时 Workaround**: 目前唯一有效的方案是使用 AutoHotkey 在系统级拦截 Ctrl+C: ```autohotkey #Requires AutoHotkey v2.0 IsOpenCodeRunning() { if ProcessExist("opencode.exe") return true return false } #HotIf IsOpenCodeRunning() ^c:: { ToolTip("Ctrl+C 已禁用 (使用 Ctrl+Q 或 Ctrl+D 退出)") SetTimer () => ToolTip(), -2000 return } #HotIf ``` **请求**: 希望能够在配置文件中添加选项彻底禁用 Ctrl+C 退出行为,例如: ```json { "tui": { "disableCtrlCExit": true } } ``` 这个问题在 Windows 用户中非常普遍(参见 #2999, #10538),强烈建议作为高优先级 UX 改进项。 感谢团队的辛勤工作!期待官方解决方案 🙏
Author
Owner

@R44VC0RP commented on GitHub (Feb 4, 2026):

Thanks for the detailed context on the Windows-specific behavior. You're right that on Windows, Ctrl+C can be intercepted at the console level before reaching the TUI keybind handlers in some scenarios.

Good news: There are already PRs open to address this:

  • #11291 - Removes ctrl+c from the default app_exit keybind entirely (simplest fix)
  • #9050 - Implements double Ctrl+C to quit with a 3-second timeout (better UX, matches Codex CLI behavior)

Your workaround in the keybinds config does work for most cases:

"keybinds": {
  "app_exit": "ctrl+d,<leader>q"
}

The AutoHotkey approach you shared is clever for cases where the signal gets caught at the OS/Bun level before OpenCode can handle it. That said, the config workaround should work for the majority of Windows users.

This issue is being tracked alongside #9041 (detailed implementation spec) and #2999. Will leave this open for visibility until one of the PRs lands.

@R44VC0RP commented on GitHub (Feb 4, 2026): Thanks for the detailed context on the Windows-specific behavior. You're right that on Windows, Ctrl+C can be intercepted at the console level before reaching the TUI keybind handlers in some scenarios. **Good news:** There are already PRs open to address this: - **#11291** - Removes `ctrl+c` from the default `app_exit` keybind entirely (simplest fix) - **#9050** - Implements double Ctrl+C to quit with a 3-second timeout (better UX, matches Codex CLI behavior) Your workaround in the keybinds config does work for most cases: ```json "keybinds": { "app_exit": "ctrl+d,<leader>q" } ``` The AutoHotkey approach you shared is clever for cases where the signal gets caught at the OS/Bun level before OpenCode can handle it. That said, the config workaround should work for the majority of Windows users. This issue is being tracked alongside #9041 (detailed implementation spec) and #2999. Will leave this open for visibility until one of the PRs lands.
Author
Owner

@lightcomc commented on GitHub (Feb 6, 2026):

same here

@lightcomc commented on GitHub (Feb 6, 2026): same here
Sign in to join this conversation.
1 Participants
Notifications
Due Date
No due date set.
Dependencies

No dependencies set.

Reference: anomalyco/opencode#4837