anomalyco/opencode
1
0
Fork 0
mirror of https://github.com/anomalyco/opencode.git synced 2026-07-22 02:05:26 -04:00
Code Issues 5.9k Packages Projects Releases 19 Wiki Activity

Provide means to disable Ctrl-C #1976

New Issue
Open
opened 2026-02-16 17:33:31 -05:00 by yindo · 26 comments
yindo commented 2026-02-16 17:33:31 -05:00
Owner
Copy Link
Copy Source

Originally created by @hwacookie on GitHub (Oct 6, 2025).

Originally assigned to: @kommander on GitHub.

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

Originally created by @hwacookie on GitHub (Oct 6, 2025). Originally assigned to: @kommander on GitHub. 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
yindo added the windows label 2026-02-16 17:33:31 -05:00
yindo commented 2026-02-16 17:33:31 -05:00
Author
Owner
Copy Link
Copy Source

@github-actions[bot] commented on GitHub (Oct 6, 2025):

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

  • #1455: Similar terminal state corruption and Ctrl-* key handling issues
  • #2232: Related Ctrl+C behavior problems with prompt handling
  • #2512: Issues with Ctrl-C interrupts and exit behavior

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

@github-actions[bot] commented on GitHub (Oct 6, 2025): This issue might be a duplicate of existing issues. Please check: - #1455: Similar terminal state corruption and Ctrl-* key handling issues - #2232: Related Ctrl+C behavior problems with prompt handling - #2512: Issues with Ctrl-C interrupts and exit behavior Feel free to ignore if none of these address your specific case.
yindo commented 2026-02-16 17:33:31 -05:00
Author
Owner
Copy Link
Copy Source

@rekram1-node commented on GitHub (Oct 6, 2025):

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?

@rekram1-node commented on GitHub (Oct 6, 2025): 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?
yindo commented 2026-02-16 17:33:31 -05:00
Author
Owner
Copy Link
Copy Source

@rekram1-node commented on GitHub (Oct 6, 2025):

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

@rekram1-node commented on GitHub (Oct 6, 2025): 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
yindo commented 2026-02-16 17:33:31 -05:00
Author
Owner
Copy Link
Copy Source

@hwacookie commented on GitHub (Oct 7, 2025):

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?!

@hwacookie commented on GitHub (Oct 7, 2025): 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?!
yindo commented 2026-02-16 17:33:31 -05:00
Author
Owner
Copy Link
Copy Source

@Thorium commented on GitHub (Oct 29, 2025):

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?

@Thorium commented on GitHub (Oct 29, 2025): 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?
yindo commented 2026-02-16 17:33:31 -05:00
Author
Owner
Copy Link
Copy Source

@Thorium commented on GitHub (Oct 29, 2025):

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 commented on GitHub (Oct 29, 2025): 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*
yindo commented 2026-02-16 17:33:32 -05:00
Author
Owner
Copy Link
Copy Source

@rekram1-node commented on GitHub (Oct 29, 2025):

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

@rekram1-node commented on GitHub (Oct 29, 2025): @Thorium you can use /sessions to navigate to previous sessions all the work is persisted to disk
yindo commented 2026-02-16 17:33:32 -05:00
Author
Owner
Copy Link
Copy Source

@pmarreck commented on GitHub (Oct 29, 2025):

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

  1. When any text is selected, it copies it.

  2. 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

@pmarreck commented on GitHub (Oct 29, 2025): I've configured my Wezterm to behave in 1 of 2 ways when control-C is pressed: 1) When any text is selected, it copies it. 2) 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
yindo commented 2026-02-16 17:33:32 -05:00
Author
Owner
Copy Link
Copy Source

@Thorium commented on GitHub (Nov 1, 2025):

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

  1. When any text is selected, it copies it.
  2. 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.

@Thorium commented on GitHub (Nov 1, 2025): > I've configured my Wezterm to behave in 1 of 2 ways when control-C is pressed: > > 1. When any text is selected, it copies it. > 2. 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.
yindo commented 2026-02-16 17:33:32 -05:00
Author
Owner
Copy Link
Copy Source

@Hona commented on GitHub (Nov 16, 2025):

Agreed on those 2 for natural feeling Windows defaults

@Hona commented on GitHub (Nov 16, 2025): Agreed on those 2 for natural feeling Windows defaults
yindo commented 2026-02-16 17:33:32 -05:00
Author
Owner
Copy Link
Copy Source

@u-dadashek commented on GitHub (Dec 1, 2025):

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.

@u-dadashek commented on GitHub (Dec 1, 2025): > 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.
yindo commented 2026-02-16 17:33:32 -05:00
Author
Owner
Copy Link
Copy Source

@u-dadashek commented on GitHub (Dec 1, 2025):

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

  1. When any text is selected, it copies it.
  2. 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.

@u-dadashek commented on GitHub (Dec 1, 2025): > I've configured my Wezterm to behave in 1 of 2 ways when control-C is pressed: > > 1. When any text is selected, it copies it. > 2. 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.
yindo commented 2026-02-16 17:33:32 -05:00
Author
Owner
Copy Link
Copy Source

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

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?!

Agree 100%. As a lifetime Windows user, very frustrating. I press Ctrl+C out of habit and get kicked out 4-5x a day. Thanks for looking into this.

Looks like there's a PR open: https://github.com/anomalyco/opencode/issues/7074#issuecomment-3726421080

@carljuneau commented on GitHub (Jan 15, 2026): > 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](https://github.com/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?! Agree 100%. As a lifetime Windows user, very frustrating. I press Ctrl+C out of habit and get kicked out 4-5x a day. Thanks for looking into this. Looks like there's a PR open: https://github.com/anomalyco/opencode/issues/7074#issuecomment-3726421080
yindo commented 2026-02-16 17:33:32 -05:00
Author
Owner
Copy Link
Copy Source

@pmarreck commented on GitHub (Jan 19, 2026):

I switch between Windows, Mac and Linux OS'es a lot.

Terminals can be configured to automatically copy when you select something. And to then automatically paste if you click the middle mouse button (wheel). Many might even default to that (go ahead and try it). That allows you to avoid ctrl-C entirely in terminals while retaining the very longstanding (50+ year) convention in the Unix/Linux world of killing programs with ctrl-C.

Just because you've only used Windows and have gotten used to Windows only treating ctrl-C as "copy" is not justification for undoing decades of others' muscle memory. Microsoft up until recently was not even amenable to open source, period, and here you guys are now making demands. I would be very upset if ctrl-C suddenly didn't do what I have expected it to do from decades of macOS and Linux/BSD terminal usage simply because some Windoze noobs crash the party and think they can start calling the shots on changing 50+ year old conventions that have existed across the entire *nix space.

ctrl-D might be a possible alternative; that often suspends a process, but on Windows-only perhaps it should be the process-killer. Or make it ctrl-shift-C.

Unless it's inside WSL. Then you're arguably back in Linux land and those conventions should remain.

@pmarreck commented on GitHub (Jan 19, 2026): I switch between Windows, Mac and Linux OS'es a lot. Terminals can be configured to automatically copy when you select something. And to then automatically paste if you click the middle mouse button (wheel). Many might even default to that (go ahead and try it). That allows you to avoid ctrl-C entirely in terminals while retaining the very longstanding (50+ year) convention in the Unix/Linux world of killing programs with ctrl-C. Just because you've only used Windows and have gotten used to Windows only treating ctrl-C as "copy" is not justification for undoing decades of others' muscle memory. Microsoft up until recently was not even amenable to open source, period, and here you guys are now making demands. I would be very upset if ctrl-C suddenly didn't do what I have expected it to do from decades of macOS and Linux/BSD terminal usage simply because some Windoze noobs crash the party and think they can start calling the shots on changing 50+ year old conventions that have existed across the entire *nix space. ctrl-D might be a possible alternative; that often suspends a process, but on Windows-only perhaps it should be the process-killer. Or make it ctrl-shift-C. Unless it's inside WSL. Then you're arguably back in Linux land and those conventions should remain.
yindo commented 2026-02-16 17:33:32 -05:00
Author
Owner
Copy Link
Copy Source

@hwacookie commented on GitHub (Jan 20, 2026):

"simply because some Windoze noobs crash the party" ... yeah, sure. Great. I love that style of discussion. :-/

Once more: I am NOT asking because I want Ctrl-C to copy something. I KNOW its not doing that, and I'm fine with it. What bothers me is the fact that it just closes an app that arguably looks like a UI, and where copying is just part of the normal workflow. And, as I said: It seems to be able to withstand this when I open it on MacOs in a terminal. (of course, it doesnt matter because here I'd use Cmd-C instead of Ctrl-C if I want top copy something) All I am asking for is that it behaves in a windows terminal just as it does in a MacOS terminal. (I dont have a Linux system at hand right now so I cant check how its behaving there)
@pmarreck , are you also sending angry comments to the "noobs" that developed nano because Ctrl-C does NOT close the app? Heck, not even vi closes on Ctrl-C! (nor does emacs, IIRC)

@hwacookie commented on GitHub (Jan 20, 2026): "simply because some Windoze noobs crash the party" ... yeah, sure. Great. I love that style of discussion. :-/ Once more: I am NOT asking because I want Ctrl-C to copy something. I KNOW its not doing that, and I'm fine with it. What bothers me is the fact that it just closes an app that arguably looks like a UI, and where copying is just part of the normal workflow. And, as I said: It seems to be able to withstand this when I open it on MacOs in a terminal. (of course, it doesnt matter because here I'd use Cmd-C instead of Ctrl-C if I want top copy something) All I am asking for is that it behaves in a windows terminal just as it does in a MacOS terminal. (I dont have a Linux system at hand right now so I cant check how its behaving there) @pmarreck , are you also sending angry comments to the "noobs" that developed nano because Ctrl-C does NOT close the app? Heck, not even *vi* closes on Ctrl-C! (nor does emacs, IIRC)
yindo commented 2026-02-16 17:33:32 -05:00
Author
Owner
Copy Link
Copy Source

@pmarreck commented on GitHub (Jan 20, 2026):

I actually changed my mind and have to apologize.

Mainly because not long after my comment, I hit ctrl-C to copy (text was selected!) and it INSTANTLY killed it. 😮

I... also now think this isn’t good app behavior. My bad, guys 🤦

Even though I easily resumed it with -c

Apologies... Now I concur.

Sorry, @hwacookie . I flamed prematurely...

@pmarreck commented on GitHub (Jan 20, 2026): I actually changed my mind and have to apologize. Mainly because not long after my comment, I hit ctrl-C to copy (text was selected!) and it INSTANTLY killed it. 😮 I... also now think this isn’t good app behavior. My bad, guys 🤦 Even though I easily resumed it with -c Apologies... Now I concur. Sorry, @hwacookie . I flamed prematurely...
yindo commented 2026-02-16 17:33:32 -05:00
Author
Owner
Copy Link
Copy Source

@Hona commented on GitHub (Jan 20, 2026):

This is a bun issue btw - I have an active PR with them to resolve it.
Then ctrl+c for opencode will be the same macos/windows

@Hona commented on GitHub (Jan 20, 2026): This is a bun issue btw - I have an active PR with them to resolve it. Then ctrl+c for opencode will be the same macos/windows
yindo commented 2026-02-16 17:33:32 -05:00
Author
Owner
Copy Link
Copy Source

@JohanSpannare-if commented on GitHub (Jan 26, 2026):

+1 on this issue

I'm also experiencing this problem on Windows with Windows Terminal + PowerShell.

I have configured my opencode.json to remove Ctrl+C from both app_exit and input_clear:

{
  "keybinds": {
    "app_exit": "<leader>q",
    "input_clear": "escape"
  }
}

However, pressing Ctrl+C still terminates the application. The keybind configuration is completely ignored.

This makes OpenCode very frustrating to use on Windows, since Ctrl+C is deeply ingrained in muscle memory (for copying, canceling input, etc.).

It seems like Ctrl+C is being captured at a lower level (possibly in OpenTUI) before the keybind handler has a chance to process it.

Would really appreciate a fix for this - either by properly respecting the keybind config, or by adding a dedicated setting to disable Ctrl+C termination.

@JohanSpannare-if commented on GitHub (Jan 26, 2026): **+1 on this issue** I'm also experiencing this problem on Windows with Windows Terminal + PowerShell. I have configured my `opencode.json` to remove Ctrl+C from both `app_exit` and `input_clear`: ```json { "keybinds": { "app_exit": "<leader>q", "input_clear": "escape" } } ``` However, pressing Ctrl+C still terminates the application. The keybind configuration is completely ignored. This makes OpenCode very frustrating to use on Windows, since Ctrl+C is deeply ingrained in muscle memory (for copying, canceling input, etc.). It seems like Ctrl+C is being captured at a lower level (possibly in OpenTUI) before the keybind handler has a chance to process it. Would really appreciate a fix for this - either by properly respecting the keybind config, or by adding a dedicated setting to disable Ctrl+C termination.
yindo commented 2026-02-16 17:33:32 -05:00
Author
Owner
Copy Link
Copy Source

@Hona commented on GitHub (Jan 26, 2026):

A workaround for this is going to come in the next couple of weeks, please hold tight!

@Hona commented on GitHub (Jan 26, 2026): A workaround for this is going to come in the next couple of weeks, please hold tight!
yindo commented 2026-02-16 17:33:32 -05:00
Author
Owner
Copy Link
Copy Source

@aborruso commented on GitHub (Jan 27, 2026):

A workaround for this is going to come in the next couple of weeks, please hold tight!

We would like to disable this feature, but we don't want to impose it globally. Instead, we would like there to be a configuration parameter available to disable it. That way, everyone can choose for themselves.

Thank you.

@aborruso commented on GitHub (Jan 27, 2026): > A workaround for this is going to come in the next couple of weeks, please hold tight! We would like to disable this feature, but we don't want to impose it globally. Instead, we would like there to be a configuration parameter available to disable it. That way, everyone can choose for themselves. Thank you.
yindo commented 2026-02-16 17:33:32 -05:00
Author
Owner
Copy Link
Copy Source

@hubertlepicki commented on GitHub (Jan 28, 2026):

Everyone coming from Claude Code will appreciate this, ideally if it's a default. Claude Code forces you to use Ctrl+C all the time, to interrupt tasks and to exit, and switching between Claude Code and OpenCode is messing with my brain - I keep hitting Ctrl+C and exiting OpenCode by accident :(

@hubertlepicki commented on GitHub (Jan 28, 2026): Everyone coming from Claude Code will appreciate this, ideally if it's a default. Claude Code forces you to use Ctrl+C all the time, to interrupt tasks and to exit, and switching between Claude Code and OpenCode is messing with my brain - I keep hitting Ctrl+C and exiting OpenCode by accident :(
yindo commented 2026-02-16 17:33:32 -05:00
Author
Owner
Copy Link
Copy Source

@EgilSandfeld commented on GitHub (Jan 29, 2026):

A workaround for this is going to come in the next couple of weeks, please hold tight!

Waiting for a new bun release, or what is blocking this?

+1 for this. I hit Ctrl+C multiple times a day to find myself terminating opencode. Lost the local storage db as well now, so no sessions to return to...

@EgilSandfeld commented on GitHub (Jan 29, 2026): > A workaround for this is going to come in the next couple of weeks, please hold tight! Waiting for a new bun release, or what is blocking this? +1 for this. I hit Ctrl+C multiple times a day to find myself terminating opencode. Lost the local storage db as well now, so no sessions to return to...
yindo commented 2026-02-16 17:33:32 -05:00
Author
Owner
Copy Link
Copy Source

@Hona commented on GitHub (Jan 29, 2026):

Not a bun release (yes my bun PR would be nice), I have a number of tasks which will make sense in the next few weeks.
I'm a windows native guy and will make opencode feel like a windows app out of the box.
Stay tuned :)

@Hona commented on GitHub (Jan 29, 2026): Not a bun release (yes my bun PR would be nice), I have a number of tasks which will make sense in the next few weeks. I'm a windows native guy and will make opencode feel like a windows app out of the box. Stay tuned :)
yindo commented 2026-02-16 17:33:33 -05:00
Author
Owner
Copy Link
Copy Source

@JohanSpannare-if commented on GitHub (Feb 3, 2026):

+1

@JohanSpannare-if commented on GitHub (Feb 3, 2026): +1
yindo commented 2026-02-16 17:33:33 -05:00
Author
Owner
Copy Link
Copy Source

@BigDaddyShuiHuo commented on GitHub (Feb 9, 2026):

+1

@BigDaddyShuiHuo commented on GitHub (Feb 9, 2026): +1
yindo commented 2026-02-16 17:33:33 -05:00
Author
Owner
Copy Link
Copy Source

@Hona commented on GitHub (Feb 10, 2026):

so step one is in the beta see my demo here: https://x.com/LukeParkerDev/status/2021413272969498814

step two will be adding config that is default off on windows for copy on disable

@Hona commented on GitHub (Feb 10, 2026): so step one is in the beta see my demo here: https://x.com/LukeParkerDev/status/2021413272969498814 step two will be adding config that is default off on windows for copy on disable
Sign in to join this conversation.
No Branch/Tag Specified
Branches Tags
Labels
Clear labels
acp
bad
bug
discussion
docs
documentation
enhancement
extension
good first issue
growth
help-wanted
mcp
model-problem
needs:compliance
nix
opentui
perf
pull-request
Mirrored from GitHub Pull Request
 tui
web
windows
zen
No Label windows
Milestone
No items
No Milestone
Projects
Clear projects
No project
Assignees
Clear assignees
yindo
No Assignees
1 Participants
Notifications
Due Date
No due date set.
Dependencies

No dependencies set.

Reference: anomalyco/opencode#1976
Delete Branch "%!s()"

Deleting a branch is permanent. Although the deleted branch may continue to exist for a short time before it actually gets removed, it CANNOT be undone in most cases. Continue?