/ps Background terminals can leak OSC-8 hyperlink state from a session preview

[xukp20]

What version of Codex CLI is running?

codex-cli 0.117.0

What subscription do you have?

Pro

Which model were you using?

gpt-5.4

What platform is your computer?

Linux 5.4.0-144-generic x86_64 x86_64

What terminal emulator and version are you using (if applicable)?

VS Code integrated terminal

What issue are you seeing?

/ps can leak terminal hyperlink state from a background terminal into subsequent UI rendering.

In particular, if a background terminal emits an OSC-8 hyperlink open sequence without a matching close sequence, then opening /ps and viewing that
session under "Background terminals" can cause subsequent lines in the main Codex terminal UI to be rendered as the same hyperlink (underlined/
clickable), even though those later lines are unrelated text.

The leaked hyperlink target in my repro was:

file:///tmp/fake/Package.lean

Important detail: this does not reproduce with plain markdown link text, and it does not reproduce when the OSC-8 hyperlink is properly closed.
It only reproduced when the background terminal output contained an unclosed OSC-8 hyperlink.

This makes it look like /ps (or the background-terminal preview renderer it uses) is interpreting terminal hyperlink escape sequences and not fully
resetting hyperlink state at a rendering boundary.

What steps can reproduce the bug?

Minimal reproduction:

1. Start a persistent background terminal session in Codex.
2. In that background terminal, run a shell that stays open.
3. In that shell, print an OSC-8 hyperlink open sequence without printing the closing OSC-8 sequence.

For example:

printf '\033]8;;file:///tmp/fake/Package.lean\aOPEN-LINK-WITHOUT-CLOSE\n'

4. Now run /ps in the main Codex session.
5. In the /ps view, under "Background terminals", observe the session containing that output.
6. Return to the main terminal and continue interacting normally.
7. Observe that subsequent lines can appear underlined/clickable as if they are all linked to the same target (file:///tmp/fake/Package.lean).

Control experiments that did not reproduce the bug:

1. Plain markdown-like text only:

printf 'msg [Package.lean](/tmp/fake/Package.lean) /tmp/fake/Source.tex\n'

2. Properly closed OSC-8 hyperlink:

printf '\033]8;;file:///tmp/fake/Package.lean\aPackage.lean\033]8;;\a\n'

3. Putting markdown-link-looking text only in a process argv / command line, without emitting terminal hyperlink escape sequences.

So the reproducer appears to require an unclosed OSC-8 hyperlink sequence in a background terminal that is then viewed through /ps.

### What is the expected behavior?

/ps should never allow hyperlink state from one background terminal/session preview to affect subsequent UI rendering.

At minimum, one of the following should happen safely:

- OSC-8 sequences should be stripped from background terminal previews in /ps
- or OSC-8 parsing should be balanced and stateful, with unmatched opens safely discarded
- or hyperlink state should be force-reset at the end of each rendered preview/chunk/card

After viewing /ps, subsequent lines in the main Codex terminal UI should render normally and should not inherit a stale hyperlink target.

### Additional information

This feels related to the OSC-8 / TUI hyperlink rendering area, but I could not find an exact duplicate.

Possibly related, but not the same bug:

- #7983 Cmd+Click doesn't work on file paths that wrap across multiple lines
- #14998 Cmd+click doesn't work on long links (URL gets truncated)
- #13277 Hyperlinks not rendered properly and non-clickable now in VS Code extension
- #13500 Add terminal hyperlink support
- #15249 Render markdown links as OSC-8 in TUI

My current hypothesis is that /ps is rendering background terminal content with hyperlink escape interpretation enabled, and one of these is happening:

- an unmatched OSC-8 open sequence is preserved across rendering boundaries
- a closing OSC-8 sequence is dropped during truncation / chunking / preview generation
- hyperlink state is not reset after rendering a background terminal preview

The result is a stale hyperlink region that makes subsequent unrelated lines appear as the same clickable file:///... target.

If helpful, I can also provide a screen recording, but the minimal reproduction above should be enough to reproduce without any Lean/Steward/toolkit
setup.

[xukp20]

I traced this a bit further in the source and the bug seems to be in the /ps background-terminal preview path, not in markdown-link rendering.

The relevant flow appears to be:

• track_unified_exec_output_chunk() stores recent background terminal output into recent_chunks without sanitizing ANSI / OSC control sequences
  • codex-rs/tui_app_server/src/chatwidget.rs
  • codex-rs/tui/src/chatwidget.rs
• /ps then renders command_display and recent_chunks directly in UnifiedExecProcessesCell::display_lines()
  • codex-rs/tui_app_server/src/history_cell.rs
  • codex-rs/tui/src/history_cell.rs

So if a background session emits an unclosed OSC-8 hyperlink open sequence, /ps appears to replay that control sequence into the main UI render path, which leaves the terminal in a stale hyperlink state. That matches the minimal repro: plain markdown text does not trigger it, properly closed OSC-8 does not trigger it, but unclosed OSC-8 does.

I also noticed there is already precedent in the codebase for stripping OSC/ANSI in display-oriented paths:

• codex-rs/ansi-escape/src/lib.rs
• codex-rs/tui_app_server/src/custom_terminal.rs
• strip_osc8_for_snapshot() in codex-rs/tui_app_server/src/chatwidget/tests.rs

I put together a local PoC that sanitizes command_display and recent_chunks when constructing the /ps preview cell, in both mirrored
implementations:

• codex-rs/tui_app_server/src/history_cell.rs
• codex-rs/tui/src/history_cell.rs

That seems like the lowest-risk fix because it keeps the change scoped to /ps preview rendering instead of altering the unified-exec data pipeline globally.

I also added a small regression test covering:

• unclosed OSC-8 in a recent chunk
• normal ANSI color sequences
• preserving visible text while removing control sequences / hyperlink targets

I haven’t been able to fully run the Rust tests on this machine because the local build is blocked by an openssl-sys environment issue, but the source-level root cause looks pretty clear.

If this fix direction matches what you want, I’m happy to prepare a PR / patch for it.