(os/open.zig stderr drain => journal flood / self-DoS) + (ghostty OSC 8 parser doesn't handle hostname= param)

[mjbommar]

Issue Description

I hit an issue today daily-driving tip that spiked CPU to 100% permanently until ghostty/service were killed. Claude and I debugged it and found that this to be two issues, one related to a long chain of tradeoffs/changes that are yet unresolved.

OSC 8 parser

When something like an SSH session renders a file URL, the OSC 8 standard says we should provide the FQDN as hostname= so that downstream users know how to resolve it. src/terminal/osc/parsers/hyperlink.zig doesn't do that, so when we try to use the result with something like xdg-open it fails.

open.zig stderr drain

Here's the Claude summary and timeline:

[CLAUDE]
openThread in src/os/open.zig drains the child's stderr with
reader.takeDelimiterExclusive('\n'). That std function returns the bytes
up to the delimiter and tosses only those bytes — it never consumes the
\n itself (implemented as peekDelimiterExclusive + toss(result.len),
Zig 0.15.2 lib/std/Io/Reader.zig:815). So once a single newline is
buffered, every subsequent call has peekDelimiterExclusive find the
delimiter at position 0 and return an empty slice straight from the
buffer — no read syscall, no pipe interaction, no EOF — and the loop
never advances:

while (true) {
    const line = reader.takeDelimiterExclusive('\n') catch ...;  // returns "" forever
    log.warn("open stderr={s}", .{line});                        // ~1,250 msg/s
}

All three platforms share this code (xdg-open/open/rundll32); the only precondition is
the child writing ≥1 newline-terminated line to stderr.

src/os/open.zig has cycled through adjacent failure modes; this
regression is the latest step. Not all of these co-occur — listed for
reviewer context, not as "all bugs are back at once."

Date	Event	Effect
2024-05-31	695bc307b "do not wait for commands which do not terminate"	fire-and-forget; children not reaped
2025-02-26	discussion #5999 "open actions create zombie xdg-open processes"	zombies reported
2025-06-23	PR #7657 (3d89fadc8): wait() in a detached thread; collectOutput capped at 50 KiB	zombies fixed; latent trap: error.StreamTooLong kills the thread, leaking pipe read-ends
2026-05-22	discussion #12767 "URL-opened apps freeze … open.zig leaks pipe read-ends"	child writing >50 KiB kills the drain thread; child then blocks at 64 KiB
2026-05-25	PR #12797 (bb375a2f7): stream stderr unbounded line-by-line, ignore stdout	freeze + leak fixed; introduces the busy-loop above

Use takeDelimiter, which advances past the delimiter and returns
null at end-of-stream (also restores exe.wait() reachability):

while (true) {
    const line = reader.takeDelimiter('\n') catch |outer| switch (outer) {
        error.ReadFailed => break,
        error.StreamTooLong => reader.take(buffer.len) catch |inner| switch (inner) {
            error.ReadFailed => break,
            error.EndOfStream => break,
        },
    } orelse break;
    log.warn("open stderr={s}", .{line});
}

[/CLAUDE]

I didn't check yet to see if there is a different safe idiom for consuming elsewhere, but you can see the propose fix there.

Expected Behavior

Drain properly

Actual Behavior

Infinite loop

Reproduction Steps

Try to open a file:// URL that fails

Ghostty Logs

ghostty[8688]: warning(os-open): open stderr=gio: file:///…/send.sh: Error when getting information for file … No such file or director
ghostty[8688]: warning(os-open): open stderr=y
ghostty[8688]: warning(os-open): open stderr=
ghostty[8688]: warning(os-open): open stderr=      ← repeats ~1,250/s until ghostty is killed

Ghostty Version

Ghostty 1.3.2-main-+e90b7c9fa

Version
  - version: 1.3.2-main-+e90b7c9fa
  - channel: tip
Build Config
  - Zig version   : 0.15.2
  - build mode    : .ReleaseFast
  - app runtime   : .gtk
  - font engine   : .fontconfig_freetype
  - renderer      : renderer.generic.Renderer(renderer.OpenGL)
  - libxev        : io_uring
  - kernel version: 7.1.0-rc7-autokernel-202606081346
  - desktop env   : other
  - GTK version   :
    build         : 4.22.2
    runtime       : 4.22.4
  - libadwaita    : enabled
    build         : 1.9.0
    runtime       : 1.9.0
  - libX11        : enabled
  - libwayland    : enabled

OS Version Information

Ubuntu 26.04

(Linux only) Display Server

Wayland

(Linux only) Desktop Environment/Window Manager

GNOME 4.22.4

Minimal Ghostty Configuration

(empty default)

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.

[lucas-rdc]

Confirming this on Void Linux (i3, GTK, Ghostty 1.3.2-main-+fea378e, Zig 0.16.0, build from 2026-08-09). I opened my config from Ghostty; the editor that launched (kate) printed a single line to stderr, and from that moment Ghostty logged warning(os-open): open stderr= with an empty value continuously at ~17.8 MB/s (≈1.4 TB/day) into ~/.xsession-errors. The logging continued after both the editor and the helper had exited. Truncating the file reclaims the space but it refills at the same rate.

Environment

Component	Version
OS	Void Linux (rolling), glibc 2.41
Kernel	6.18.43_1 x86_64
Filesystem (/)	ext4, rw,relatime
Display server	Xorg 21.1.24, libX11 1.8.13
Session manager	LightDM 1.32.0
Window manager	i3 4.25.1
Desktop environment	none (Ghostty reports desktop env: other)
Ghostty	1.3.2-main-+fea378e (tip), built 2026-08-09
Zig	0.16.0
Build mode	ReleaseFast
App runtime	GTK
GTK / libadwaita	4.22.4 / 1.9.1
Renderer	OpenGL
libxev backend	io_uring
Font engine	fontconfig + freetype
Opener	xdg-utils 1.2.1 (xdg-open)
Editor launched	kate 26.04.3 (kf6-kio 6.28.0)
glib / gio	2.88.0
xdg-desktop-portal	1.22.1 (gtk backend 1.15.3)
D-Bus	1.16.2