Consider opt-in recovery of existing local paths split by cursor-positioned TUI rendering

[bjmatrix]

Ghostty 1.4.0 (18457), macOS 27.2 arm64; originally encountered with Codex CLI 0.166.0. This reproduction needs no Codex, tmux, or custom link configuration.

An existing local file path becomes a truncated clickable target when an application lays it out across rows using CUP cursor positioning. Cmd-clicking the first row sends a nonexistent prefix to the file safety check; the continuation is not recognized as the same file.

These rows are not terminal-native soft wraps. This is a request to consider bounded, opt-in recovery for local files, not to reinterpret arbitrary cursor movement as a wrap. Producer-side OSC 8 remains the clean protocol-level solution.

Reproduction

Run in a fresh window around 80 columns wide:

import shutil
import sys
import tempfile
from pathlib import Path

width = shutil.get_terminal_size((80, 24)).columns
if not 40 <= width <= 180:
    raise SystemExit("Use a fresh window between 40 and 180 columns wide")
file = Path(tempfile.mkdtemp(prefix="ghostty-cup-", dir="/tmp")) / ("example-" + "a" * width + ".txt")
file.write_text("Existing non-executable test file\n")
file.chmod(0o644)
text = "  Example (" + str(file) + ")"
rows = []
while text:
    count = width - 2
    rows.append(text[:count])
    text = "  " + text[count:] if text[count:] else ""
# Each row is explicitly positioned and ends before the right margin.
# No OSC 8 hyperlink and no terminal-native automatic wrap is emitted.
sys.stdout.write("\x1b[0m\x1b[2J\x1b[HCUP-rendered existing file path")
for y, row in enumerate(rows, 3):
    sys.stdout.write(f"\x1b[{y};1H" + row)
sys.stdout.write(f"\x1b[{len(rows) + 5};1HCmd-click either path row. Enter exits.")
sys.stdout.flush()
if sys.stdin.isatty():
    input()

The script creates a harmless temporary file and draws its path on independently positioned rows. Each row ends before the right margin; no OSC 8 metadata is emitted. Try Cmd-clicking either path segment.

Source observations at v1.4.0

• Terminal.setCursorPos clears pending-wrap state; printWrap creates native wrap markers.
• Surface.linkAtPin uses Screen.selectLine, which follows those markers. The independently drawn rows have no continuation relationship.

Possible narrow behavior

Only if the original matched path does not exist, inspect a few adjacent near-margin rows and accept a unique existing local-file candidate. Preserve existing literal filenames, reject ambiguous joins and clear record boundaries, and retain executable-file and URL safety checks. A local prototype has been tested; no branch or patch has been published.

Would this be an acceptable opt-in feature direction, or should it remain exclusively a producer-side OSC 8 responsibility?

Related: openai/codex#7983 (same symptom); #14984 (related application scrolling case; this reproduction needs no scrolling).

AI disclosure: OpenAI Codex assisted with source inspection, the reproduction, the local prototype, and drafting this report.

[jcollie]

If a TUI is using ESC sequences to lay out the screen it should definitely be using OSC 8 to create proper links. Anything we did in Ghostty would at best be a flaky heuristic.

[bjmatrix]

Thanks, I agree that producer-side OSC 8 is the proper solution when an application controls the layout.

What I had in mind was a disabled-by-default compatibility option for applications that do not emit that metadata yet, similar to iTerm2's ignoreHardNewlinesInURLs option.

The scope would be limited to existing local paths, preserving valid literal targets, checking only a few adjacent rows, and rejecting ambiguous candidates. I understand that these constraints reduce false positives without eliminating them.

Would this kind of opt-in compatibility fallback still be outside Ghostty's intended scope?

[jcollie]

I'd be against an option like that.