Ctrl+C not sent to TUI processes while Korean IME is in composing state (macOS)

[RoundTable02]

Issue Description

When the macOS native Korean (Hangul) input method is the active input source, Ctrl+C is not delivered to TUI processes (such as Claude Code, Codex, OpenCode). This occurs regardless of whether the IME is actively composing — simply having the Korean input source toggled on is enough to reproduce the issue. The key event appears to be consumed or dropped instead of being forwarded as an interrupt signal to the running process.

ghostty_ctrl_c_edit.mov

This issue is specific to Ghostty — the same processes in Terminal.app and iTerm2 correctly receive Ctrl+C regardless of the active input source.

Notably, Ghostty's own shell (non-TUI, cooked mode) handles Ctrl+C correctly even with the Korean input source active. The issue only occurs when a process has switched the terminal to raw/alternate screen mode.

Expected Behavior

When Ctrl+C is pressed while the Korean input source is active, the key event should be delivered to the foreground process as SIGINT (or equivalent key event \x03), consistent with the behavior in Terminal.app and iTerm2.

Modifier key combinations like Ctrl+ should be handled as control sequences regardless of which input source is currently active, as they are not text input.

Actual Behavior

When the Korean input source is active (toggled to Korean) and Ctrl+C is pressed inside a TUI process running in raw/alternate screen mode:

The Ctrl+C keystroke is not forwarded to the process — even if no text is being composed.
The process continues running and does not receive an interrupt.
The user must first switch to the English input source (via the language toggle key), then press Ctrl+C again to terminate the process.

In Ghostty's own shell (cooked mode), Ctrl+C works correctly even with the Korean input source active — this suggests the issue is in how Ghostty routes key events when a non-Latin input source is active and the terminal is in raw mode.

Reproduction Steps

1. Open Ghostty on macOS.
2. Switch to the Korean (두벌식) input method using the macOS input source switcher.
3. Start a TUI process that uses raw/alternate screen mode. For example:

claude

(or any other TUI application like opencode, codex, etc.)

4. Without typing anything (no composing in progress), press Ctrl+C.
5. Observe: The process does not terminate. The Ctrl+C is not delivered.
6. Workaround: Press the language toggle key to switch to English, then press Ctrl+C — the process terminates as expected.

Note: The issue also occurs while actively composing Korean text, but composing is not required to reproduce — simply having the Korean input source selected is sufficient.
Comparison test (confirming this is Ghostty-specific):

Repeat steps 2–4 in Terminal.app → Ctrl+C correctly terminates the process.
Repeat steps 2–4 in Ghostty's own shell (without a TUI process) → Ctrl+C correctly sends interrupt.

Ghostty Logs

English input source active + Ctrl+C in TUI process: Key event is logged and process receives interrupt as expected.

2026-02-17 11:55:18.799631+0900 0x3a687f   Info        0x0                  53405  0    ghostty: [com.mitchellh.ghostty:stream] OSC 1 (change icon) received and ignored icon=~
2026-02-17 11:55:18.799687+0900 0x3a687f   Error       0x0                  53405  0    ghostty: [com.mitchellh.ghostty:stream] unimplemented OSC command: change_window_icon
2026-02-17 11:55:18.804788+0900 0x3a687f   Error       0x0                  53405  0    ghostty: [com.mitchellh.ghostty:stream] unimplemented OSC callback: terminal.osc.Command{ .end_of_command = terminal.osc.Command__struct_18710{ .exit_code = 0 } }
2026-02-17 11:55:18.804818+0900 0x3a687f   Error       0x0                  53405  0    ghostty: [com.mitchellh.ghostty:stream] unimplemented OSC command: end_of_command

Korean input source active + Ctrl+C in TUI process: No log output at all. The key event does not appear in Ghostty's debug logs, suggesting it is being consumed before reaching Ghostty's input processing pipeline.

This indicates the issue is at the macOS input source / IME integration layer — the Ctrl+C key event is not being forwarded from the input method to Ghostty's key event handler when a non-Latin input source is active and the terminal is in raw mode.

### Ghostty Version

```text
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 Tahoe 26.2

(Linux only) Display Server

None

(Linux only) Desktop Environment/Window Manager

No response

Minimal Ghostty Configuration

No custom configuration required. This issue reproduces with the default Ghostty configuration.

Additional Relevant Configuration

No response

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.