macOS: ctrl+c sometimes stops working after backgrounding helix

[stackotter]

Issue Description

Sometimes when I background helix editor (via ctrl+z), ctrl+c stops sending interrupts for the rest of my terminal session in that window. I get no indication that I ever hit ctrl+c except for a literal ^C getting printed when interacting with a standard stdin/stdout based program. I don't get a bell either. I unfortunately don't have a way to reproduce this consistently, but it happens maybe once or twice a day. ctrl+z keeps working so I don't think it's related to ISIG.

Here's the output of stty -a;

$ stty -a
speed 9600 baud; 75 rows; 425 columns;
lflags: icanon isig iexten echo echoe -echok echoke -echonl echoctl
        -echoprt -altwerase -noflsh -tostop -flusho pendin -nokerninfo
        -extproc
iflags: -istrip icrnl -inlcr -igncr ixon -ixoff ixany imaxbel -iutf8
        -ignbrk brkint -inpck -ignpar -parmrk
oflags: opost onlcr -oxtabs -onocr -onlret
cflags: cread cs8 -parenb -parodd hupcl -clocal -cstopb -crtscts -dsrflow
        -dtrflow -mdmbuf
cchars: discard = ^O; dsusp = ^Y; eof = ^D; eol = <undef>;
        eol2 = <undef>; erase = ^?; intr = ^C; kill = ^U; lnext = ^V;
        min = 1; quit = ^\; reprint = ^R; start = ^Q; status = ^T;
        stop = ^S; susp = ^Z; time = 0; werase = ^W;

isig and intr are set correctly.

If I run stty intr undef in a fresh ghostty session, I get a similar effect, but I still get a bell, whereas with my issue I don't get a bell.

Ctrl+c still works to comment out lines in Helix, so the keystroke is still getting processed by Ghostty.

I haven't found any way to restore ctrl+c interrupt functionality in a session once it stops working. reset doesn't help.

Expected Behavior

ctrl+c should send interrupts when isig is enabled and intr = ^C

Actual Behavior

ctrl+c doesn't send an interrupt.

Reproduction Steps

Unfortunately I can't reproduce this consistently. But here's my workflow that seems to eventually reproduce the issue, often after a few hours of coding.

1. Open Ghostty
2. Run hx . and start coding
3. Frequently use ctrl+z to background helix and build/run my GUI application project (with Swift Package Manager; nothing that does interactive terminal input), followed by fg to reopen helix and continue editing code
4. Eventually there comes a time that I background helix and ctrl+c stops sending interrupts for the rest of my terminal session

Ghostty Logs

No response

Ghostty Version

Ghostty 1.2.3

Version
  - version: 1.2.3
  - channel: stable
Build Config
  - Zig version   : 0.14.1
  - build mode    : builtin.OptimizeMode.ReleaseFast
  - app runtime   : apprt.Runtime.none
  - font engine   : font.main.Backend.coretext
  - renderer      : renderer.generic.Renderer(renderer.Metal)
  - libxev        : kqueue

OS Version Information

macOS 15.3.2 (24D81)

(Linux only) Display Server

None

(Linux only) Desktop Environment/Window Manager

No response

Minimal Ghostty Configuration

# As I can't reproduce this consistently, I haven't got a minimal configuration.
# This is my entire configuration. The only option that I'd be remotely suspicious
# of is macos-option-as-alt, but option isn't involved here so it should be unrelated.
macos-option-as-alt = left
window-padding-x = 10
window-padding-y = 0,10
macos-titlebar-proxy-icon = hidden

Additional Relevant Configuration

Helix config

Helix version: helix 25.01.1 (e7ac2fcd)

The only input-related setting that I have is mouse = true;

[editor]
mouse = true

I acknowledge that:

• I have reviewed the FAQ and confirm that my issue is NOT among them.
• I have searched the Ghostty repository (both open and closed Discussions and Issues) and confirm this is not a duplicate of an existing issue or discussion.
• I have checked the "Preview" tab on all text fields to ensure that everything looks right, and have wrapped all configuration and code in code blocks with a group of three backticks (```) on separate lines.

[jcollie]

Check and see if they Kitty keyboard protocol is left on when you suspend Helix. You can do that using the terminal inspector. If you're using the default bash shipped with macOS you probably should upgrade to a newer shell as the default bash is ancient.

[stackotter]

The mode seems to be legacy (with Xterm modifier keys set to false)

[rhodes-b]

Ill also note from the above ^C being SIGINT is entirely done by the shell not the terminal since you are still seeing a ^C literal that seems like a shell problem

[stackotter]

Ah interesting. My shell is zsh. Your comment lead me to try running zsh again within a broken session and that seems to have fixed the issue for that session. Running bash within that same broken session (first) didn't fix the issue.

[stackotter]

I believe that you’re correct. I’ve managed to find a way to repeatably reproduce the issue now, and could reproduce the same issue in kitty and iTerm so it’s not a terminal issue.

I can only reproduce it when using zsh and helix (zsh+nvim doesn’t have the issue, and bash+helix doesn’t either). I’ll close this discussion now.

Thanks for the pointers both of you!

[markpeek]

I've had this happen several times randomly so I looked further into it. I found this Open Radar bug report:
https://openradar.appspot.com/FB18565075

AI summary of the report:
A macOS kernel bug causes sigsuspend() to wake prematurely when a child exits and generates SIGCHLD, even when that signal is blocked.

Worse, after this premature return, macOS fails to restore the original signal mask. In zsh, this can leave SIGINT blocked, so Ctrl-C stops interrupting the shell and its child processes. The bad mask is inherited by subsequently launched programs.

The supplied reproducer confirms the bug on macOS 26.5.2. Apple fixed it in macOS 27 beta 3. On affected systems, running trap - at the zsh prompt restores normal Ctrl-C behavior.

Detecting the issue
If it happens again, try this to see if you have the same issue:

% python3 -c 'import signal; m=signal.pthread_sigmask(signal.SIG_BLOCK, set()); print("blocked:", ", ".join(sorted(s.name for s in m)) or "(none)"); print("BUG DETECTED: SIGINT is blocked" if signal.SIGINT in m else "SIGINT is unblocked")'
blocked: SIGINT
BUG DETECTED: SIGINT is blocked
% trap -
% python3 -c 'import signal; m=signal.pthread_sigmask(signal.SIG_BLOCK, set()); print("blocked:", ", ".join(sorted(s.name for s in m)) or "(none)"); print("BUG DETECTED: SIGINT is blocked" if signal.SIGINT in m else "SIGINT is unblocked")'
blocked: (none)
SIGINT is unblocked