Provide means to disable Ctrl-C

Maybe it's just me, but using opencode under windos in WezTerm or Microsofts Terminal App is nearly impossible for me if I cannot stop opencode from crashing whenever I press Ctrl+C. I can live with this not doing what its supposed to do (Copy to clipboard), but simply quitting the program is really bad. Now, I have read about keybindings and the possibility to set an action to "none", (default for "quit" is Ctrl+C), but this does not help because (I guess) Ctrl+C is captured somewhere before it even reaches the keyboard handler. This is what I see in the terminal:

panic: close of closed channel

goroutine 1 [running]:
github.com/sst/opencode/internal/components/status.(*statusComponent).Cleanup(0xc00020a1e0)
/home/runner/work/opencode/opencode/packages/tui/internal/components/status/status.go:319 +0x25
github.com/sst/opencode/internal/tui.Model.Cleanup(...)
/home/runner/work/opencode/opencode/packages/tui/internal/tui/tui.go:948
main.main()
/home/runner/work/opencode/opencode/packages/tui/cmd/opencode/main.go:166 +0xce9

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

Terminal state corruption after opencode exit - spurious sequences on Ctrl-* inputs #1455: Similar terminal state corruption and Ctrl-* key handling issues
Preserve Prompt on Ctrl+C #2232: Related Ctrl+C behavior problems with prompt handling
Opencode stuck in "generating" #2512: Issues with Ctrl-C interrupts and exit behavior

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

hm isn't ctrl+c used to stop programs? It shouldn't be causing a panic we will need to check that out but when doing a ctrl + c on a running program, doesn't the kernel send a SIGINT or whatever the windows equivalent is?

to copy things you should be able to drag select with your cursor to copy user & assistant messages, in next version of tui the copy behavior will be better right now it is poor

@sageil

Thanks for the hints, I know that Ctrl+C is used to interrupt applications (especially CLI apps) in the Linux/Unix world.
However, having that behaviour is very unusual for a Windows user, especially since the Ctrl+C, Ctrl+V keystrokes are "hardwired" for copy/paste operations. Having this abort the app is a real bad UX, especially since the session is not automatically continued upon restart. Two other things: e.g. nano does NOT simply "die" when pressing Ctrl+C. Heck, not even opencode itself simply dies upon Ctrl+C - but only when I use it under WSL. The "drop-dead" behaviour only occurs when being used in Windows Terminal (or WezTerm, and probably others as well)

@sageil : No, I think this is not correct: Yes, Ctrl+C is one of the keybindings that is used to exit the applications, but the documentation also mentions that it is possible to redefine that key to something else, so Ctrl+C should then NOT exit the application anymore. I think, opencode does not even "handle" or "see" the Ctrl+C at all, at least thats what I'd guess from the stacktrace that I get when the app terminates. I suppose they'd need to integrate a "Break" handler or something like that, I remember I had to do something like that for my Java-apps as well: https://stackoverflow.com/questions/1611931/catching-ctrlc-in-java
I suppose the same applies to go programs as well?!

Ok, half an hour of waiting opencode work done, and here we have the results... Let me copy the file answer with default Windows copy short-cut "Ctrl+C", oops, it terminated opencode... how do I now restore the session to recovered the lost job?

I do know the old MS-DOS Ctrl+Shift+Insert and Shift+Insert works, it's just that last 25 years have rewired my brain to try first the Windows standard.

Edit: It works if you press it quickly, it asks for confirm, but pressing long and hard, then it dies immediately

@Thorium

@Thorium you can use /sessions to navigate to previous sessions all the work is persisted to disk

I've configured my Wezterm to behave in 1 of 2 ways when control-C is pressed:

When any text is selected, it copies it.
If no text is selected, it does the normal ctrl-C, which on linux distros stops the current process (sends SIGTERM to it).

Here is the part of my wezterm config that makes this work:

https://github.com/pmarreck/dotconfig/blob/yolo/wezterm/wezterm.lua#L133

I've configured my Wezterm to behave in 1 of 2 ways when control-C is pressed:

When any text is selected, it copies it.

If no text is selected, it does the normal ctrl-C, which on linux distros stops the current process (sends SIGTERM to it).

I'd love this to be the default behaviour config.

Agreed on those 2 for natural feeling Windows defaults

to copy things you should be able to drag select with your cursor to copy user & assistant messages, in next version of tui the copy behavior will be better right now it is poor

Seriously? We are the data, not your brain. I do not use opencode because this quirk makes me think if you can't figure this out what else is really wrong with your thinking.

I've configured my Wezterm to behave in 1 of 2 ways when control-C is pressed:

When any text is selected, it copies it.

If no text is selected, it does the normal ctrl-C, which on linux distros stops the current process (sends SIGTERM to it).

Here is the part of my wezterm config that makes this work:

https://github.com/pmarreck/dotconfig/blob/yolo/wezterm/wezterm.lua#L133

Personal bias: Just don't use Windows unless you are gaming. It's going to constantly be an uphill battle for any sort of real development work these days, unless you are doing PURELY Windows-focused dev (which pretty much doesn't apply to anything anymore UNLESS you are building Windows games). You can trivially configure any AMD/Intel box to dual-boot Linux alongside Windows, with the added benefit of 1) fewer distractions from windows games since rebooting is a pain, 2) the entire huge library of linux open source software available to you without having to force WSL to work with graphical apps properly 3) you get access to really cool stuff like new sliding-window managers such as Niri (for Wayland-based) or PaperWM (for Gnome-based) that are completely unavailable on either macos or windows

/end-rant

This product has a reasonable chance of adoption by me if the folks running the software do not overlay. You may spend time in rabbit holes, I prefer not to. Ctrl-C is just a very large domain on the keyboard to start fighting over when opencode's adoption might be part of the mission. If not, whatever keep the charm - lose the user.

Windows Terminal, WSL1, i also find it absolutely annoying, i keep using my 40-years-usual shortcuts and most of all don't work or even worse :

CTRL+C makes me quit the app many times a day... (CTRL+X, CTRL+C, CTRL+V are windows standards...)
Home, End, Page Up, Page Down : doesn't behave as i use to use them for (navigation inside my prompt)
i also don't know how to create a new line in my prompt (how many times did i send the prompt instead of creating a new line with Enter or CTRL+Enter).

I love the app but, in its current state, shortcuts UX is a real messy PITA.
Would it be possible to have presets of shortcuts or at least to switch from Linux to Win shortcuts in settings ?

CTRL+C makes me quit the app many times a day

I had all the same issue with ctrl+c and home keys. This is what I'm using in my setup and it seems to work ok So give this a try. Shift+Enter adds a new line, you might have to add this https://opencode.ai/docs/keybinds/#shiftenter

~/.config/opencode/tui.json

{
  "$schema": "https://opencode.ai/tui.json",
  "keybinds": {
    "terminal_suspend": "none",
    "app_exit": "ctrl+d,<leader>q",
    "input_clear": "none",
    "session_interrupt": "escape",
    "messages_first": "ctrl+g",
    "messages_last": "ctrl+alt+g",
    "input_line_home": "home",
    "input_line_end": "end",
    "input_select_line_home": "ctrl+shift+home",
    "input_select_line_end": "ctrl+shift+end",
    "input_buffer_home": "ctrl+home",
    "input_buffer_end": "ctrl+end"
  }
}

Adding another data point from WezTerm on Windows 11:

Exit method	WezTerm	Windows Terminal
`exit`	pwsh stays alive ✓	pwsh stays alive ✓
`/exit`	pwsh killed ✗	pwsh stays alive ✓
Ctrl+C	pwsh killed ✗	pwsh stays alive ✓

Environment: WezTerm (latest) + pwsh 7 + Windows 11 Pro, opencode via scoop.

The fact that Windows Terminal handles all three exit methods fine but WezTerm doesn't suggests the issue is at the intersection of bun/openTUI and WezTerm's ConPTY implementation, not a general Windows SIGINT problem. Both /exit and Ctrl+C trigger the same bun-level process termination path that WezTerm's ConPTY doesn't handle correctly. The terminal_suspend: none tui.json workaround doesn't help.

Exit code shown by WezTerm: 2148734499 (0x80131523, .NET runtime exception).

Correction to my earlier comment — after further testing in Windows Terminal, all three terminals behave consistently:

Exit method	WezTerm	Windows Terminal
`exit`	pwsh alive ✓	pwsh alive ✓
`/exit`	pwsh killed ✗	entire terminal window closes ✗
Ctrl+C	pwsh killed ✗	entire terminal window closes ✗

So this is purely an opencode issue — /exit and Ctrl+C both kill the parent process across all Windows terminals, not just WezTerm. Only the plain exit command exits cleanly and returns to the shell. WezTerm shows the error message (exit code 2148734499) while Windows Terminal closes silently, but the root cause is the same: the bun/openTUI process termination path is taking the parent process with it.

Confirmed this is a regression. Tested across versions:

1.14.21: /exit and Ctrl+C both exit cleanly, pwsh stays alive ✓
1.15.6: /exit and Ctrl+C kill the parent process ✗

Consistent with #25677 which reports the same regression starting from 1.14.25. Rolling back to 1.14.21 (via scoop) is a working workaround on Windows.

Bisected this down to the exact commit: 4877ecc (PR #24215 — "Fix shell cwd after login startup").

1.14.24 (before the PR): /exit and Ctrl+C exit cleanly, shell stays alive ✓
1.14.25 (after the PR): /exit and Ctrl+C kill the parent terminal/process ✗

The PR changed packages/opencode/src/session/prompt.ts — refactored how the working directory is passed to shell commands (from $PWD capture to $1 positional parameter). This altered the shell process invocation signature for zsh/bash, and appears to have a side effect on how opencode spawns/terminates the TUI shell process on Windows, causing the parent terminal process to be killed when exiting via /exit or Ctrl+C.

@Hona

Update: Found the actual root cause, not PR #24215.

The real change that introduced this regression is the OpenTUI version bump in v1.14.25:

Dependency	v1.14.24 (working)	v1.14.25 (broken)
`@opentui/core`	0.1.99	0.1.103
`@opentui/solid`	0.1.99	0.1.103

PR #24215 (shell cwd fix) was coincidental — the OpenTUI bump from 0.1.99 to 0.1.103 changed how the TUI process terminates on Windows, causing the parent terminal process to be killed on /exit and Ctrl+C. This aligns with @Hona's earlier comment about it being a bun-level issue.

The move from pinned versions ("0.1.99") to workspace catalog references ("catalog:") in packages/opencode/package.json is what allowed this version jump to land unnoticed.

same

Ctrl + C should not be changed.
Anyone who uses the terminal on Windows knows that that stops the running script.
It is a last resort escape hatch for a runaway or hanging script.

There are other ways to trigger a copy: select alone, right click, shift + insert

feat(tui): require double ctrl+c to exit — guard both keybind and SIG…

https://www.unidadvirtual.com/opencode-cli-deseo-anular-la-combinacion-de-teclas-crl-c

Solucion:

Crear el archivo tui.json con app_exit deshabilitado:

Podemos crearlo en forma global o solo para el proyecto:

Opción A) Forma Global > Archivo: C:\Users\tu_usuario.config\opencode\tui.json

Si deseas puedes usar el atajo para encontrar la carpeta global opencode , presionas las teclas Windows+R (abre el formulario ejecutar) y alli digitas %USERPROFILE%/.config/opencode/ , se te abrira la carpeta global opencode y creas el archivo tui.json

Opción B) En el Proyecto > ./tui.json , El archivo lo creamos en la raiz del Proyecto.

Contenido del archivo tui.json

{
"$schema": "https://opencode.ai/tui.json",
"keybinds": {
"app_exit": "none"
}
}
Esto deshabilita Ctrl+C como atajo para salir. El valor "none" anula la combinación por defecto (ctrl+c, ctrl+d, q).

Después de crear el archivo, reiniciar opencode para que los cambios tomen efecto.

If you are PowerShell, before starting, try setting $env:OTUI_USE_ALTERNATE_SCREEN=0 and then restart. The same applies to other terminals.

fix(session): the range accounting names the machinery it omits inste…

Navigation Menu

Provide means to disable Ctrl-C #2999

19 remaining items

Metadata

Assignees

Labels

Type

Projects

Milestone

Relationships

Development

Provide means to disable Ctrl-C #2999

Description

Activity

github-actions commented on Oct 6, 2025

rekram1-node commented on Oct 6, 2025

rekram1-node commented on Oct 6, 2025

hwacookie commented on Oct 7, 2025

Thorium commented on Oct 29, 2025

Thorium commented on Oct 29, 2025

rekram1-node commented on Oct 29, 2025

pmarreck commented on Oct 29, 2025

Thorium commented on Nov 1, 2025

Hona commented on Nov 16, 2025

u-dadashek commented on Dec 1, 2025

u-dadashek commented on Dec 1, 2025

19 remaining items

ADiv0viDA commented on May 19, 2026

rossdonald commented on May 21, 2026

liangweidonggood commented on May 21, 2026

liangweidonggood commented on May 21, 2026

liangweidonggood commented on May 21, 2026

liangweidonggood commented on May 21, 2026

liangweidonggood commented on May 21, 2026

hondrytravis commented on May 28, 2026

DustinX commented on Jul 22, 2026

alextutor commented on Sep 4, 2026

Elvin-zhujunde commented on Sep 14, 2026

Metadata

Metadata

Assignees

Labels

Type

Projects

Milestone

Relationships

Development

Issue actions