Bash-tagged Run-button code blocks with cross-drive cd on Windows fail silently depending on which shell executes them

On Windows, when Claude gives a \\\bash-tagged code block (which renders a "Run" button) containing a two-line pattern like:
\\\
cd D:\Synchronized\SomeProject
uv run script.py
\\\
the reliability of the \cd\` line depends entirely on which shell actually executes the Run button — and this isn't consistently signaled to Claude:

• If executed via Git Bash, backslash paths (\D:\Synchronized\...\) are misinterpreted as escape sequences rather than path separators.
• If executed via cmd.exe, even a corrected forward-slash or drive-lettered \cd D:/Synchronized/...\ will NOT switch drives — cmd.exe's \cd\ only changes directory within the current drive unless given the \/d\ flag (\cd /d D:\...\). If the pwd starts on \C:\\, the shell silently stays on \C:\\, and the following line (e.g. \uv run script.py\) then fails to find the script or runs the wrong thing entirely, with no obvious error tying the failure back to the \cd\.

This has recurred across multiple separate chat sessions over the past few months (each occurrence has to be independently rediscovered, since there's no reliable mechanism ensuring a past correction generalizes to new sessions).

Suggested fixes (any of):

1. Have Claude default to single-command, full-path invocations that avoid a separate \cd\ line where possible (e.g. \uv run "D:/path/to/script.py"\ instead of \cd\ + \uv run script.py\).
2. If a \cd\ is unavoidable in a bash-tagged block, always use \cd /d\ on Windows-path arguments so it's correct under cmd.exe as well as Git Bash/PowerShell.
3. Make it unambiguous/documented which shell actually executes a \\\`bash-tagged Run-button block on Windows, so Claude can reliably target it instead of guessing.

🤖 Generated with Claude Code