macOS: config parser silently ignores keybinds after a documentation comment

[Nek-12]

Issue Description

Ghostty's config reader can silently stop reading a file when an ignored blank or comment line ends exactly at the end of its current reader buffer, even when the file has more content. This is a parser EOF bug, not a keybind-specific issue.

Config.loadFsFile uses a 2,048-byte reader buffer. In src/cli/args.zig, LineIterator.next() calls fillMore() only before its loop. When streamDelimiterEnding plus discardDelimiterInclusive('\n') consumes an ignored line through the final buffered byte, seek == end; continue then reevaluates while (seek != end) as false and returns null instead of refilling. The remaining configuration is silently ignored.

This affected Cmd+D only incidentally: a later super+d=new_split:right binding was either read or not read depending on this truncation. The same defect applies to any setting after the boundary and should be cross-platform.

Expected Behavior

Ghostty should continue reading after a comment or blank line at a reader-buffer boundary. All following configuration entries should be applied, and +validate-config should not silently accept a truncated parse.

Actual Behavior

With the broken configuration below, +validate-config exits 0 with no output, but the following keybind is not read:

keybind = cmd+d=paste_from_clipboard

+list-keybinds --plain instead reports the default:

keybind = super+d=new_split:right

Changing only the comment-line length by one byte makes the same keybind apply:

keybind = super+d=paste_from_clipboard

Reproduction Steps

1. Use an isolated Ghostty config directory:

   tmp=$(mktemp -d)
   mkdir -p "$tmp/home" "$tmp/xdg/ghostty"

2. Generate the broken minimal config. Its first line is exactly 2,048 bytes: #, 2,046 ASCII x bytes, then a newline.

   perl -e 'print "#", "x" x 2046, "\nkeybind = cmd+d=paste_from_clipboard\n"' \
     > "$tmp/xdg/ghostty/config"

3. Validate and list the binding:

   HOME="$tmp/home" XDG_CONFIG_HOME="$tmp/xdg" ghostty +validate-config
   HOME="$tmp/home" XDG_CONFIG_HOME="$tmp/xdg" ghostty +list-keybinds --plain | rg '^keybind = super\\+d='

   Validation succeeds silently; the output is:

   keybind = super+d=new_split:right

4. Change only 2046 to 2045 in step 2, then repeat step 3. The output becomes:

   keybind = super+d=paste_from_clipboard

Ghostty Logs

No log or validation diagnostic is emitted. In both variants, ghostty +validate-config exits 0 with no output.

Ghostty Version

Ghostty 1.3.2-main-+15484b607

Version
  - version: 1.3.2-main-+15484b607
  - channel: tip
Build Config
  - Zig version   : 0.16.0
  - build mode    : .ReleaseFast
  - app runtime   : .none
  - font engine   : .coretext
  - renderer      : renderer.generic.Renderer(renderer.Metal)
  - libxev        : kqueue

OS Version Information

macOS 27.0 on Apple Silicon.

(Linux only) Display Server

N/A

(Linux only) Desktop Environment/Window Manager

N/A

Minimal Ghostty Configuration

Broken variant:

# followed by exactly 2046 ASCII `x` bytes, then a newline (2,048 bytes total for this line)
keybind = cmd+d=paste_from_clipboard

Control variant: change the count to 2,045 x bytes. The commands above generate the exact files without ambiguity.

Additional Relevant Configuration

None. The reproduction uses a fresh temporary HOME and XDG_CONFIG_HOME; no shell, tmux, editor, theme, or other Ghostty configuration is required.

I acknowledge that:

• I reviewed the FAQ and confirm this issue is not among the documented common issues.
• I searched open and closed Ghostty Discussions and Issues. This is distinct from macOS: keybinds do not override macOS "application default" keybinds (regression) #11396 and macos: only run key equivalents for Ghostty-owned menu items #11403, which concern the macOS Cmd+D menu override rather than config-file truncation at a reader boundary.
• I checked the preview and wrapped configuration and commands in fenced code blocks.

[Nek-12]

config.renamed.txt

Here's my full config file for reproduction.

Correction: I found the actual root cause, and my earlier “68-byte comment makes later keybinds ignored” diagnosis was backwards.

This is a Ghostty LineIterator EOF bug, not a keybind parser error.

Config.loadFsFile creates a 2,048-byte file-reader buffer (src/config/Config.zig, around line 3944). In src/cli/args.zig, LineIterator.next() primes that reader only once before entering:

var entry = while (self.r.seek != self.r.end) {
    ...
    _ = self.r.streamDelimiterEnding(&writer, '\n') ...;
    _ = self.r.discardDelimiterInclusive('\n') catch {};
    ...
    if (entry.len == 0 or entry[0] == '#') continue;
    break entry;
} else return null;

If a blank/comment line’s newline is the final byte of the current reader buffer, discardDelimiterInclusive advances seek to end. Because the line is ignored, continue immediately evaluates self.r.seek != self.r.end as false and returns null — even though the underlying file still has more bytes. No refill occurs inside that comment-skipping loop, so the rest of the config is silently treated as EOF. +validate-config succeeds because there is no diagnostic.

In my config, removing the four Markdown backticks from line 280 shifted the divider comment at line 457 so its newline landed at zero-based byte 16,384 (a 2 KiB buffer boundary). Ghostty then stopped parsing at line 457. That accidentally made Cmd+D paste only because it never reached the later active line:

keybind = super+d=new_split:right

at line 531, which otherwise overwrites the intended earlier binding:

keybind = cmd+d=paste_from_clipboard

Restoring the original comment moves the divider newline to byte 16,388; parsing continues and the later super+d=new_split:right wins again. The deterministic reproducer is therefore: an ignored line ending exactly at the end of Ghostty’s 2,048-byte reader buffer, followed by additional config.

The fix belongs in LineIterator.next(): after skipping an ignored line, it must refill/check the underlying reader rather than treating seek == end as EOF. This needs a regression test using a buffered reader where a comment/blank line ends exactly at the buffer boundary and a valid setting follows.

On a personal note, this is a crazy issue, it took my agent 6 hours of work to debug this, decompiling the code, checking sources, automating macos computer use and recreating this setup with a fresh install over 50+ attempts.

[danielwe]

I can reproduce this. Your attached config file works (cmd+d pastes), but if I reinstate the four backticks on line 280, keybinds are dropped (cmd+d splits). That is wild.

The OP is now a bit of a red herring. I know you already spent a lot of time and energy on this, but it would be helpful if you could edit it to focus on your actual diagnosis and include actual steps/config to reproduce. Then hopefully a maintainer will come along and promote this to an issue.

(Also consider taking a look at the discussion template for issue triage at https://github.com/ghostty-org/ghostty/discussions/new?category=issue-triage, which asks for information in a structured way---your agent bypassed this by opening the discussion through the github API. That said, I can confirm that what you've already provided is sufficient to reproduce the issue on macOS 26, and since the bug seems to be in shared zig code I'd expect it to be cross-platform.)

[Nek-12]

Thank you and I'm sorry for not following the template - that's my first issue in ghostty. Body corrected.

[mitchellh]

Fixed: #13638