[BUG] Image paste (Alt+V) always fails under WSL when login shell is fish — clipboard command run via $SHELL, which rejects "$(...)" in command position

Preflight Checklist

• [x] I have searched existing issues and this hasn't been reported yet
• [x] This is a single bug report (please file separate reports for different bugs)
• [x] I am using the latest version of Claude Code

What's Wrong?

On WSL2 with fish as the login shell, pasting a clipboard image (Alt+V) in the
Claude Code REPL always reports:

No image found in clipboard. Use ctrl+v to paste image

The clipboard genuinely contains an image. The failure is not in clipboard
access or WSL interop — it is that Claude executes its clipboard helper command through the user's login shell ($SHELL), and that command uses POSIX
command-substitution-in-command-position syntax that fish refuses to run.

The clipboard image detection/extraction command embedded in the bundle is:

"$(command -v powershell.exe 2>/dev/null || echo /mnt/c/Windows/System32/WindowsPowerShell/v1.0/powershell.exe)" \
    -NoProfile -NonInteractive -Sta \
    -Command 'Add-Type -AssemblyName System.Windows.Forms; if (-not [System.Windows.Forms.Clipboard]::ContainsImage()) { exit 1 }'

The leading "$(...)" is a command substitution in command position. POSIX shells accept it; fish does not, and aborts with exit code 127 before PowerShell is ever invoked. Claude interprets that failure as "no image in clipboard".

Notably, Claude's Bash tool already runs under bash (its shell snapshots are snapshot-bash-*.sh) — so only these auxiliary helper commands leak through to the raw login shell. Running the same helper under /bin/sh or bash works; only fish fails. The fix is to run these helper commands under /bin/sh (or bash) rather than $SHELL.

What Should Happen?

Pasting an image should detect and attach it regardless of the user's login
shell. Claude's internal/auxiliary shell commands should be executed with a
POSIX-compatible shell (e.g. /bin/sh), not the interactive login shell, since the commands are written in POSIX syntax that non-POSIX shells like fish cannot parse.

Error Messages/Logs

# Claude's UI toast:
No image found in clipboard. Use ctrl+v to paste image

# Reproducing the exact helper command Claude runs, under each shell:

$ fish -c '"$(command -v powershell.exe 2>/dev/null || echo /mnt/c/Windows/System32/WindowsPowerShell/v1.0/powershell.exe)" -NoProfile -NonInteractive -Sta -Command (...)'
fish: command substitutions not allowed in command position. Try var=(your-cmd) $var ...
# exit code: 127   <-- helper never runs; Claude concludes "no image"

$ /bin/sh -c '"$(command -v powershell.exe 2>/dev/null || echo /mnt/c/Windows/System32/WindowsPowerShell/v1.0/powershell.exe)" -NoProfile -NonInteractive -Sta -Command (...)'
# exit code: 0     <-- image detected correctly

# Proof the clipboard really holds an image (PowerShell via the same fallback path):
[System.Windows.Forms.Clipboard]::ContainsImage()  -> True
GetImage().Save(...)  -> valid PNG, 1019 x 322

# The login shell Claude inherits (from /proc/<claude-pid>/environ):
SHELL=/run/current-system/sw/bin/fish

Steps to Reproduce

1. Use WSL2 with fish set as the login shell (echo $SHELL -> .../fish).
2. Launch claude from that fish session.
3. Take a screenshot on Windows (Win+Shift+S) so the Windows clipboard holds an image.
4. Press Alt+V in the Claude Code prompt.

-> Toast: "No image found in clipboard. Use ctrl+v to paste image"

Confirm the cause:

1. Quit, relaunch with a POSIX shell: env SHELL=/bin/bash claude
2. Press Ctrl+V on the same screenshot -> image attaches correctly.

Claude Model

Opus

Is this a regression?

I don't know

Last Working Version

_No response_

Claude Code Version

2.1.158 (Claude Code)

Platform

Anthropic API

Operating System

Other Linux

Terminal/Shell

WSL (Windows Subsystem for Linux)

Additional Information

Environment

• OS: NixOS-WSL on WSL2, kernel 6.6.114.1-microsoft-standard-WSL2
• Terminal: Windows Terminal hosting the WSL distro
• Login shell: fish (SHELL=/run/current-system/sw/bin/fish)
• WSL interop enabled; /mnt/c mounted; powershell.exe reachable via the

hardcoded fallback path. None of these are the problem.