macOS: Single tab/surface becomes unresponsive while rest of app stays alive (1.3.1, Tahoe 26)

[torselen]

Issue Description

A single Ghostty tab becomes completely unresponsive — keyboard input and shortcuts (including Ctrl-C / Ctrl-Z) are dropped, while other tabs in the same Ghostty window stay fully responsive. Closing the tab is the only known recovery.

Likely the same surface-level wedge as anthropics/claude-code#5939 (closed by reporter without investigation, no fix).

This is a single-surface freeze (one tab dead, rest of the app alive) — distinct from the whole-window SecureKeyboardInput freeze in #9590. Diagnostics in the Actual Behavior section.

Expected Behavior

The Ghostty tab should continue to respond to keyboard input throughout the session, regardless of how long it has been running or how much git activity has happened in the same project directory.

Actual Behavior

After running claude in a Ghostty tab for an extended session in a project containing .git/, alongside parallel git commits via VS Code's git plugin, the tab eventually becomes totally unresponsive — keystrokes ignored, Ctrl-C / Ctrl-Z dead, scrollback dead. Other tabs keep working. Closing the affected tab is the only recovery.

Captured live during a freeze: 5 s user-stack sample of ghostty + 2 min unified log + ps state.

Triage signature check

Pattern	Hits	Implication
SecureKeyboardInput / TSMProcessRawKeyCode	0	Not the SKI freeze (#9590)
pasteboard / NSPasteboard	0	Not a clipboard hang
CGSConnectionByID / WindowServer	0	Not WindowServer-side
kevent / libxev	11	Normal idle waits on io / renderer threads

Main thread (1 ms sampling, 4017 hits over 5 s)

• 4016 / 4017 samples: parked in mach_msg inside _DPSNextEvent — normal idle.
• 1 / 4017 samples caught in cold-path dispatch:

__CFRunLoopRun + 1944
__CFRUNLOOP_IS_SERVICING_THE_MAIN_DISPATCH_QUEUE__
  _dispatch_main_queue_callback_4CF
    _dispatch_main_queue_drain
      _dispatch_main_queue_drain.cold.6     ← cold path
        _dispatch_client_callout
          object.Object.setProperty__anon_516913 (in ghostty)
            -[CALayer setContents:]
              CA::Layer::begin_change(CA::Transaction*, …)
                +[NSNull null]

Single sample only — a longer sample or spindump would confirm whether this is the steady-state hot path. Sharing because the cold.6 marker is unusual.

Thread layout

22 threads total: 3× renderer, 3× io, 3× io-reader, 3× cf_release (all parked in kevent64); plus NSEventThread, CVDisplayLink, Metal queues, main thread (state above). Three sets of renderer/io/io-reader implies three live surfaces; only one wedged from the user's perspective.

Unified log (last 2 min)

Routine StateRestoration flushes, CoreSpotlight indexing, AppKit XPC. Nothing pathological.

Full sample.txt (232 KB) and unified-log.txt (24 KB) available on request — non-maintainers can't attach files to discussions in this repo.

Reproduction Steps

1. Open a Ghostty tab in a project folder containing .git/.
2. Run a long-lived TUI process (Claude Code: claude) for an extended period.
3. In parallel, make multiple Git commits in the same project via VS Code's integrated Git plugin (separate process, same .git/).
4. Eventually the Ghostty tab running the TUI freezes — keys dropped, Ctrl-C / Ctrl-Z dead, scrollback dead. Other tabs OK.

Probabilistic; not every session, but recurring. Not reproduced in Terminal.app, iTerm2, or VS Code's integrated terminal.

Ghostty Logs

No response

Ghostty Version

Ghostty 1.3.1

Version
  - version: 1.3.1
  - channel: stable
Build Config
  - Zig version   : 0.15.2
  - build mode    : .ReleaseFast
  - app runtime   : .none
  - font engine   : .coretext
  - renderer      : renderer.generic.Renderer(renderer.Metal)
  - libxev        : kqueue

OS Version Information

macOS Tahoe 26.4.1 (Apple Silicon, M-series, build 25E253)

(Linux only) Display Server

None

(Linux only) Desktop Environment/Window Manager

No response

Minimal Ghostty Configuration

macos-option-as-alt = left

# Tab navigation (match Warp: opt+cmd+arrows)
keybind = super+alt+arrow_left=previous_tab
keybind = super+alt+arrow_right=next_tab

# Match macOS text-field word-deletion behavior at the zsh prompt.
# opt+backspace      -> ESC+DEL (M-BS) -> backward-kill-word (deletes word before cursor)
# fn+opt+backspace   -> ESC+d   (M-d)  -> kill-word (deletes word after cursor)
# fn translates backspace -> forward-delete at the hardware layer, so Ghostty
# sees `alt+delete` for the fn variant. `fn` itself is not a valid modifier.
keybind = alt+backspace=text:\x1b\x7f
keybind = alt+delete=text:\x1bd

# Pass cmd+z / cmd+shift+z through to TUI apps (Claude Code chat:undo/redo).
# Ghostty's defaults are super+z=undo / super+shift+z=redo — its own prompt-input
# undo, which swallows the keys before they reach the app.
keybind = super+z=unbind
keybind = super+shift+z=unbind

# Shell integration (explicit — default 'detect' may not be activating)
shell-integration = zsh
shell-integration-features = no-cursor,no-sudo,title

# Bell: play system sound + bounce dock + mark title
bell-features = system,attention,title
bell-audio-path = /System/Library/Sounds/Funk.aiff
bell-audio-volume = 0.7

# Auto-notify when any command takes >10s and terminal is unfocused
notify-on-command-finish = unfocused
notify-on-command-finish-action = bell,notify
notify-on-command-finish-after = 10s

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.

[tor-selen]

Routing pointer: the active diagnostic thread is now on the closed companion issue #12629 — @eraseliu001 has posted a deterministic repro and an in-band-reset diagnostic that narrows the wedge to per-surface object-model state in Ghostty (not DEC/xterm/kitty mode flags). I hit it again today on two tabs simultaneously and have +1'd the reopen request there. Anyone following this discussion: that's where the live evidence is accumulating.

[bo2themax]

Took a look at that comment in the closed issue, it seems like a Claude issue, you can test your input by inspecting keyboard events in that "frozen" surface. Right click and select toggle terminal inspector in the menu.

[eggrollofchaos]

Independent reproduction on July 13 with Ghostty 1.3.1, macOS 26.5.1 on Apple Silicon, and Claude Code 2.1.206.

One Ghostty surface became completely keyboard-input-dead while:

• its Claude Code TUI continued rendering updates;
• sibling Ghostty tabs continued accepting keyboard input normally;
• macOS Accessibility still reported the affected Ghostty surface as focused;
• Claude remained the foreground process group, with stdin/stdout/stderr attached to the affected PTY;
• the PTY settings matched a working Claude tab, including input enabled and no IXON/IXOFF flow-control lock;
• Claude had completed its turn and was visibly idle at a prompt.

Closing only the affected tab and resuming the same Claude conversation in a fresh Ghostty tab/PTY restored input immediately.

The incident occurred near a high-system-load period and a tmux launch, but neither is established as causal. Tmux was attached to a different PTY. The contemporaneous unimplemented mode: 7727 log also appears unrelated: tmux emits CSI ? 7727 h/l for mintty's application-Escape optimization, while Ghostty logs and ignores the unsupported mode.

I saw the suggestion to inspect keyboard events through Ghostty's Terminal Inspector. Unfortunately, I closed the wedged surface before capturing that. On recurrence I can check whether key events reach the inspector and collect a Ghostty sample/spindump at the same time. Is there a preferred debug build, trace category, or diagnostic bundle for distinguishing surface event delivery from the PTY write path?