[BUG] /stats Ctrl+S screenshot copy always fails on WSL2 — platform string is "wsl", the xclip branch added in #54695 only matches "linux"

Summary

Pressing <kbd>Ctrl</kbd>+<kbd>S</kbd> on the /stats (or /usage) screen under WSL2 always shows copy failed in the footer. Nothing reaches the clipboard.

This is the WSL half of #54695 (/usage Ctrl+S silently fails to copy stats screenshot on Linux/X11, fixed 2026-05-05). That fix added an xclip branch keyed on the platform string "linux". On WSL the platform string is "wsl", so the branch never runs and the function falls through to its "unsupported platform" return.

It is the same shape as #82909 (clipboard paste on WSL only tries powershell.exe, Linux fallback unreachable): a platform-string branch that treats wsl and linux as disjoint when the Linux path works perfectly well on WSL2 + WSLg.

Root cause

In 2.1.241 the screenshot-to-clipboard helper branches on zt():

async function KkA(e){
  let t = zt();
  if (t === "macos")   { /* osascript */ }
  if (t === "linux")   { if (await YkA("xclip", ["-selection","clipboard","-t","image/png","-i", e]) === 0) return {success:true, …};
                         return {success:false, message:"Failed to copy to clipboard. Please install xclip: sudo apt install xclip"} }
  if (t === "windows") { /* powershell Clipboard::SetImage */ }
  return { success:false, message:`Screenshot to clipboard is not supported on ${t}` }   // <-- WSL lands here
}

and getPlatform() classifies WSL as its own platform, never as linux:

if (env.WSL_DISTRO_NAME || env.WSL_INTEROP) this.platform = "wsl";
else { let e = this.kernelString(); this.platform = (e !== undefined && v4o(e)) ? "wsl" : "linux" }

So on WSL KkA returns success:false with "Screenshot to clipboard is not supported on wsl". The caller discards the message and renders only the two-word footer:

n(s.success ? "copied!" : "copy failed")

which is why the reason is invisible to the user.

Note the codebase already has the wsl→linux collapse elsewhere — NVo() does let t = e === "wsl" && !$rb() ? "linux" : e — it just isn't applied on this path.

Repro

1. WSL2 (WSLg available), xclip installed and working.
2. claude → /stats → <kbd>Ctrl</kbd>+<kbd>S</kbd>
3. Footer shows copy failed.
4. xclip -selection clipboard -t TARGETS -o — no image/png target; clipboard unchanged.

Expected

Same as on native Linux: the PNG lands on the clipboard via xclip (WSLg bridges the X11 clipboard to the Windows clipboard, so it pastes into Windows apps too).

Evidence that the Linux path itself works on WSL

Everything upstream of the platform check succeeds; only the branch selection is wrong.

• xclip is present (/usr/bin/xclip, 0.13) and round-trips a PNG:

``
$ xclip -selection clipboard -t image/png -i /tmp/t.png ; echo $?
0
$ xclip -selection clipboard -t TARGETS -o
TARGETS
image/png
``

• Replicating YkA's exact spawn options ({cwd: undefined, detached: true, stdio: "ignore", windowsHide: true}, 5 s kill timer) returns exit 0 in 4 ms.
• The render/write step runs fine: $CLAUDE_CODE_TMPDIR/screenshots/ is created and its mtime bumps on every Ctrl+S (the PNG is written, then unlinked in the finally). So the failure is strictly the platform branch, not ansiToPng and not the temp path.

Suggested fix

Treat wsl like linux on this path, e.g. if (t === "linux" || t === "wsl"), or reuse the existing NVo()-style collapse before the branch. Verified locally: binary-patching that one comparison to t !== "macos" makes Ctrl+S copy the screenshot correctly on WSL2.

A second, independent nit: the "unsupported platform" and "install xclip" messages are both swallowed by the copied!/copy failed footer, so every distinct failure mode presents identically. Surfacing s.message on failure would have made this self-diagnosing.

Environment

• Claude Code: 2.1.241
• WSL2 on Windows 11, kernel 6.18.33.2-microsoft-standard-WSL2
• Distro: Ubuntu 24.04.3 LTS
• WSL_DISTRO_NAME=Ubuntu, WSL_INTEROP=/run/WSL/<pid>_interop
• WSLg: DISPLAY=:0, WAYLAND_DISPLAY=wayland-0 (XDG_SESSION_TYPE unset)
• xclip 0.13 installed and functional; wl-clipboard not installed
• TERM=xterm-256color

Related

• #54695 — same bug on Linux/X11, fixed by adding the linux branch this report says WSL misses
• #82909 — clipboard paste on WSL only tries powershell.exe; same class of platform-branch gap