Use tmux negotiated hyperlink capability for compact Markdown links

Summary

Codex renders Markdown links as label (url) inside tmux even when tmux has negotiated OSC 8 hyperlink support with the outer terminal. This adds URL noise and can make long links wrap. Codex renders the same link as a compact, underlined label in bare Ghostty.

Reproduction

Environment: macOS 26.6.2, Ghostty 1.3.1, tmux 3.7c, Codex CLI 0.153.4.

Configure tmux:

set -as terminal-features ',xterm-ghostty:hyperlinks'

Verify the attached client:

tmux list-clients -F '#{client_termname} #{client_termfeatures}'

The attached client reports xterm-ghostty and includes hyperlinks; tmux info reports Hls.

Ask Codex to render:

[Ghostty mouse behavior](https://ghostty.org/docs/config/reference#mouse-shift-capture)

Bare Ghostty displays Ghostty mouse behavior. Inside tmux, Codex displays Ghostty mouse behavior (https://ghostty.org/docs/config/reference#mouse-shift-capture).

The OSC 8 transport itself works inside tmux. This opens from Ghostty with Shift-Command-click when tmux mouse mode is enabled, and tmux preserves the hyperlink in capture-pane -p -H:

printf '\033]8;;https://example.com\033\\This is a link\033]8;;\033\\\n'

Root cause

codex-rs/tui/src/markdown_render/web_links.rs returns WithDestination whenever it detects a multiplexer or screen*/tmux* TERM. This is a terminal-identity heuristic; it does not inspect tmux's negotiated client capabilities.

Proposed fix

Probe the active tmux server's attached clients at TUI startup using:

tmux -N -S <socket> list-clients -F '#{client_termname}\t#{client_termfeatures}'

Use label-only rendering when every attached client reports the exact hyperlinks feature. Keep the destination visible when the probe fails, is ambiguous, finds a mixed-capability server, or detects nested/other multiplexers. A bounded timeout and output limit keep startup responsive.

I implemented and tested this approach locally on branch fix/tmux-web-link-capabilities (commit f446f0f). The focused TUI test set passes (11/11), and the live probe against tmux 3.7c returns Supported.

The presentation decision can be a startup snapshot. A later enhancement could invalidate it when attached clients change; already-rendered scrollback would need an explicit policy.

References

• Existing expanded-link issue: #31554
• tmux terminal feature documentation: https://man.openbsd.org/tmux.1

Start in codex-rs/tui/src/markdown_render/web_links.rs and review the TUI startup path alongside the tmux probe command described in the issue. Run the focused TUI test set, then verify that exact hyperlinks-capable clients use label-only links while probe failures, mixed capabilities, and nested or other multiplexers retain destinations.