Hyperlink arena exhaustion (StringAllocOutOfMemory) spins the write path instead of degrading

[co-cy]

Summary

When the terminal's hyperlink string arena is exhausted, the write path appears to spin / not make forward progress instead of dropping the hyperlink and continuing. Writing a large, OSC 8-dense buffer in one shot floods this warning and then pins the thread:

warning(terminal): error reallocating for more hyperlink space, ignoring hyperlink err=error.StringAllocOutOfMemory

The ignoring hyperlink wording suggests the intent is to degrade gracefully, but in practice the containing write does not return.

Environment

• ghostty-web@^0.4.0, running as WASM in an Electron renderer (embedded by Nimbalyst).
• Trigger: replaying a terminal's saved scrollback (~500 KB, very hyperlink-dense — Claude Code / Codex emit many OSC 8 clickable file paths) into the terminal in a single write on session restore.

Observed behavior

• A burst of ~70 identical StringAllocOutOfMemory hyperlink warnings within ~7 ms, then silence.
• The renderer's main thread then sits at ~100% of one core with 0 syscalls over a 6 s strace sample — i.e. a pure userspace loop, not I/O or a lock.
• A paused JS stack shows the top frame inside the WASM invoke trampoline — control went into the terminal write and never came back.

So once the arena is full, processing the remaining OSC 8 sequences in that write seems to loop rather than skip-and-advance.

Question / hypothesis

• Is hyperlink-arena exhaustion expected to be recoverable within a single terminal.write? It looks like the post-failure "ignoring hyperlink" path may retry the allocation (or fail to advance the parser) when the arena stays full for the next hyperlink in the same write, turning many consecutive OSC 8 sequences into an unbounded loop.
• Could you point me to where StringAllocOutOfMemory from the hyperlink path is handled? If the fix is "drop the hyperlink, advance, and don't re-attempt until space frees", that would turn this from a hang into graceful degradation.

Caveats

I don't yet have a standalone ghostty-web reproduction — this was diagnosed through the Nimbalyst embedding (traces above). If a minimal repro would help, I can try to build one that writes a synthetic OSC 8-dense buffer larger than the arena in a single call; a pointer to the arena size / relevant source would speed that up.

Filing here since ghostty-web owns the WASM build; if this is upstream Ghostty behavior, happy to move it.

[co-cy]

Root cause found — and upstream Ghostty already fixed it; this needs a submodule bump

I traced the spin into the vendored Ghostty. Screen.cursorSetHyperlink recursively retries itself, growing the page, when the hyperlink arena is full. At the commit this package pins (ghostty submodule @ 5714ed07, shipped in 0.4.0) the growth is unguarded — src/terminal/Screen.zig:

// FIXME: This SUCKS
if (page.string_alloc.alloc(u8, page.memory, uri_size)) |slice| {
    _ = &slice;
} else |_| {
    const before = string_bytes;
    while (string_bytes - before < uri_size) string_bytes *= 2;   // unbounded doubling
}
_ = try self.adjustCapacity(self.cursor.page_pin.node, .{
    .hyperlink_bytes = page.capacity.hyperlink_bytes * 2,          // unbounded doubling
    .string_bytes = string_bytes,
});
if (self.cursor.hyperlink_id > 0) return try self.cursorSetHyperlink();   // recursive retry

Replaying a large, OSC 8-dense scrollback in one write drives this into runaway page reallocation — the renderer main thread spins (0 syscalls, ~100% CPU) and memory balloons (~1.2 GB RSS observed in the Nimbalyst embedding). The per-cell caller floods error reallocating for more hyperlink space, ignoring hyperlink err=error.StringAllocOutOfMemory and then goes silent as the loop takes over.

The good news: upstream main has already fixed the infinite-loop class in PageList.increaseCapacity, which now guarantees forward progress and caps growth:

// Doubling zero stays zero, which would break our guarantee that we always
// increase by at least one unit and turn caller retry loops into infinite loops.
if (old == 0) { ... break :new @field(default, field_name); }
// checked math; once a dimension is maxed out, fail cleanly instead of looping
break :new std.math.mul(Int, old, 2) catch |err| overflow: {
    if (old < std.math.maxInt(Int)) break :overflow std.math.maxInt(Int);
    return error.OutOfSpace;
};

With that, cursorSetHyperlink either makes progress or returns error.OutOfSpace, which Terminal.print already catches and ignores (drops the hyperlink) — graceful degradation instead of a hang.

Ask: the fix shipped in Ghostty v1.3.0 (2026-03-09) and v1.3.1 — v1.2.3 and earlier don't have it. This package still pins the pre-fix ghostty submodule (5714ed07, 2025-12-01) on both 0.4.0 and main, so increaseCapacity isn't there yet. Bumping the submodule to Ghostty ≥ v1.3.0 and cutting a release fixes this for embedders with no JS-side change. Happy to help test a build.

(Context: hit via Nimbalyst restoring many terminals with heavy Claude Code scrollback. We're shipping a temporary embedder-side workaround that flattens OSC 8 links out of replayed scrollback, but the real fix is here.)