[BUG] Statusline OSC 8 hyperlinks no longer clickable (regression in 2.1.181)
Preflight Checklist
- [x] I have searched existing issues
- [x] This is a single bug report
- [x] I am using the latest version of Claude Code
What's Wrong?
Custom statusline programs that emit OSC 8 hyperlinks render as plain (non-clickable) text. Claude Code's statusline rendering layer honors SGR color codes from the same output but strips the OSC 8 hyperlink sequences, so labels show in color but are not clickable.
This was reported before and auto-closed for inactivity without a fix:
- #23438 (closed NOT_PLANNED + locked; bot explicitly requested a new issue referencing it)
- #21586 "OSC 8 hyperlinks in custom statusline no longer render" (closed)
This report adds the missing data point those issues lacked: it is a confirmed regression with a known working→broken window.
Is this a regression?
Yes. My custom statusline emitted clickable tilt/dash hyperlinks for weeks. They stopped being clickable immediately after a Claude Code auto-update.
- Statusline script: unchanged since May 29 (verified mtime). It still emits valid OSC 8 — confirmed in source:
osc8() { printf '\033]8;;%s\033\\%s\033]8;;\033\\' "$1" "$2"; }
- Claude Code install dir mtime: Jun 18 — the only thing that changed between "worked" and "broken".
- SGR colors from the same script still render correctly (e.g. a green
CI✓), so it is specifically OSC 8 being dropped, not all escapes.
What Should Happen?
OSC 8 hyperlink escape sequences emitted by a custom statusline command should pass through Claude Code's rendering layer unchanged, so they are clickable (as they were prior to the regression and as they are when piping the same bytes directly to the terminal).
Steps to Reproduce
- Configure a
type: commandstatusline that emits an OSC 8 hyperlink:
printf '\033]8;;https://example.com\033\\link text\033]8;;\033\\'
- Run Claude Code (current: 2.1.181).
- Observe the label renders in color but is not clickable.
- Control: piping the same
printfdirectly to the terminal renders a clickable link, confirming the terminal supports OSC 8 and the bytes are correct.
Last Working Version
Prior to the auto-update on ~2026-06-18 (broke on upgrade to 2.1.181).
Claude Code Version
2.1.181
Platform
Claude API
Operating System
macOS (Darwin 25.5.0, arm64)
Terminal/Shell
tmux 3.6a (TERM=tmux-256color). Note: tmux 3.6 supports OSC 8 passthrough and a direct printf renders a clickable link in the same pane, so tmux is not the blocker — the sequence is dropped inside Claude Code's rendering layer.
Showing cached comments. Read the full discussion on GitHub ↗
3 Comments
Found 3 possible duplicate issues:
This issue will be automatically closed as a duplicate in 3 days.
🤖 Generated with Claude Code
adding a cross-platform confirmation + what looks like the actual lever.
same symptom here: a custom statusline's OSC 8 links render colored-but-dead while a bare
printfOSC 8 is clickable inline in the same pane. seen on WezTerm (Windows + WSL) and Ghostty (mac).the useful bit: setting
FORCE_HYPERLINK=1in theenvblock of settings.json brings the statusline links straight back. that points the regression at CC's hyperlink capability-detection rather than the render layer unconditionally stripping - the terminal-supports-hyperlinks check seems to have started returning false for terminals that do support them, and forcing past it restores the OSC 8. worth trying on your end - if it fixes it for you too, that basically pins it to the detection path rather than rendering.one tmux aside, only so it doesn't muddy this report: if anyone's still dead inside tmux after setting FORCE_HYPERLINK, that's a separate client-side thing - tmux only forwards OSC 8 outward if it knows the outer terminal does hyperlinks, which needs
set -as terminal-features '*:hyperlinks'when the outer TERM is a generic xterm-256color. not CC's bug, and not your case since your direct printf already works in tmux 3.6. just flagging it so the tmux-specific reports stay separate from this one.Data point while this is broken: for OSC sequences that don't need to wrap visible statusline text (cwd report, title, progress), there's a bypass — statusline child processes still inherit the session's console, so writing to the console device directly (CONOUT$ on Windows, /dev/tty where the child has one) skips the statusline output filter. Verified with OSC 9;9 so Windows Terminal duplicate-tab lands in the session's real cwd: https://github.com/ykdojo/claude-code-tips/issues/36
Doesn't help OSC 8 itself — hyperlinks must wrap text at its rendered position, which only Claude Code's renderer controls. Native passthrough (or native OSC 9;9/7 emission on cwd change) would cover both.