zmx aborts with HyperlinkSetOutOfMemory during long Codex sessions #182

Hey there! I’m using zmx through supacode, and several codex sessions disappeared mid-work today. The supacode side effect was that the terminal tabs closed, but the logs point to zmx itself aborting after HyperlinkSetOutOfMemory warnings.

This looks like it could be related to OSC 8 / terminal hyperlink handling, see #171.

Environment

• zmx: 0.6.0
• ghostty_vt: ghostty-1.3.2-dev-5UdBC8HuDgWFQtz8pKQ-0HH6z0Cb_PKbI0R7AunQhdDF
• macOS: 26.3 (25D125)
• Host app: Supacode v0.10.4
• Workload: multiple long-running Codex CLI sessions
• Codex output included many clickable file references / terminal links

What Happened

Several zmx-backed Codex sessions disappeared while agents were mid-work.

macOS generated multiple zmx crash reports with the same SIGABRT signature:

SIGABRT
terminal.Screen.clearCells
terminal.stream.Stream(...).nextNonUtf8
main.daemonLoop
main.Daemon.ensureSession
main.attach

The matching zmx session logs ended with:

[warning] (stream_terminal): error handling VT action action=.linefeed err=error.HyperlinkSetOutOfMemory
[warning] (stream_terminal): error handling VT action action=.linefeed err=error.HyperlinkSetOutOfMemory

Right after that, the global zmx log showed the affected sessions being cleaned up as stale:

stale socket found, cleaning up session=supa-e56597be-...
stale socket found, cleaning up session=supa-d2fd4263-...

Expected

zmx should not abort when the terminal state tracker hits hyperlink capacity / OSC 8-heavy output.

If hyperlink tracking fails, zmx should either ignore/strip those sequences for its internal state tracking or recover gracefully, while keeping the session alive for attached clients.