Claude Code: Bash-to-PowerShell Start-Process silently strips -ArgumentList; agent then misdiagnoses as environment limitation

Summary

When the Claude Code agent launches a GUI helper on Windows via the Bash tool using powershell.exe -Command 'Start-Process ... -ArgumentList ...', the arguments get silently stripped during quote-nesting translation (bash → PowerShell → CreateProcess). The cmd/exe child starts with a bare command line and does nothing. More importantly, when the window doesn't appear, the agent misdiagnoses the symptom (blames the sandbox for not being able to show windows) instead of reading the actual Win32_Process.CommandLine which shows the args were dropped.

What happened

I asked Claude Code to launch my app's tracing terminal (a launch_trace.bat wrapper). Claude ran:

powershell.exe -NoProfile -Command 'Start-Process -FilePath "cmd.exe" -ArgumentList "/k","C:\Users\Me\project\launch_trace.bat"'

Two cmd.exe processes spawned (I could see them in Task Manager / via Get-CimInstance Win32_Process), but:

• MainWindowTitle was empty
• No python.exe child appeared
• launch_trace.bat never executed

The agent's first diagnosis:

"the sandbox Bash tool runs in a non-interactive desktop context, so Start-Process cmd.exe creates the process but cannot attach it to your desktop — the window never actually pops up for you to see. Root cause: tooling limitation, not a code/app issue."

This is wrong. The prior sessions launched the same bat file via the same mechanism and worked fine. I told the agent as much (in stronger language).

Actual root cause

Checking Get-CimInstance Win32_Process | ... Select CommandLine on the orphan cmd processes:

ProcessId   : 2728
CommandLine : C:\WINDOWS\System32\cmd.exe          <-- no /k, no batch file

The -ArgumentList "/k","C:\path\launch_trace.bat" was stripped somewhere in the bash single-quote → PowerShell single-quoted -Command → Start-Process parameter parsing chain. The cmd process started bare and sat there with no work to do. No error, no stderr, nothing in logs.

A corrected invocation (extra \" escaping) worked on first try:

powershell.exe -NoProfile -Command \"Start-Process -FilePath 'cmd.exe' -ArgumentList '/k','\\\"C:\Users\Me\project\launch_trace.bat\\\"' -WorkingDirectory 'C:\Users\Me\project'\"

After which Win32_Process.CommandLine correctly shows:

\"C:\WINDOWS\system32\cmd.exe\" /k \"C:\Users\Me\project\launch_trace.bat\"

and python.exe spawns as expected.

Issues with Claude Code here

1. The quote-nesting failure is silent

Bash → PowerShell → Start-Process -ArgumentList through a single-quoted -Command string is a well-known sharp edge on Windows. The agent should either:

• Use a more robust launch pattern (e.g. write the command to a temp .ps1 and invoke it, or use cmd /c start \"\" \"batfile\" directly from bash without PowerShell in the middle), or
• Verify the launched process received the args before reporting success.

2. The misdiagnosis is the bigger problem

The agent had direct access to Get-CimInstance Win32_Process and eventually used it to read the CommandLine of the orphan processes — which immediately showed the args were missing. But it did this after the user pushed back, not as part of the initial diagnosis.

First-pass diagnosis should read the actual state (what command line did the child get, what's its exit code, what's it doing) before inventing a theory about sandbox desktop-attach behavior. The project's own CLAUDE.md has a \"Rule 1: know what you don't know\" principle — this is a textbook case of skipping that rule.

3. Confusing user-facing message

\"Sandbox can't attach interactive windows\" is not just wrong — it's plausibly wrong, which wastes more user time than an obvious error would. The agent presented a fabricated architectural limitation with confidence. The user had to explicitly say \"it worked before\" to get the agent to re-investigate.

Suggested improvements

1. When the Bash tool invokes a GUI-launching command on Windows, the agent should verify with Get-CimInstance Win32_Process (or equivalent) that the child process received the expected command line — before reporting success or diagnosing failure.
2. Add a hard rule: before claiming a \"harness/sandbox/environment limitation,\" read the actual child process state. Environment limitations are the last hypothesis, not the first.
3. Consider providing a first-class helper in the Bash tool for \"launch this Windows GUI program in a visible terminal\" that handles quote-nesting correctly. This is a recurring pain point on Windows.

Environment

• Claude Code CLI (VS Code native extension)
• Model: claude-opus-4-7 (1M context)
• OS: Windows 11
• Shell exposed to Bash tool: MSYS bash (Git for Windows style)
• PowerShell: 5.1

Related prior incidents (same project)

• \anthropics/claude-code#46940\ — fabricated \"ALL PASSED\" test result
• \anthropics/claude-code#46945\ — ignored SESSION-STATE updates
• \anthropics/claude-code#47236\ — patching pattern on nesting dialog
• \anthropics/claude-code#47239\ — false claim about gh CLI availability

This one shares a family resemblance with #47239: agent claims a capability/environment constraint without actually checking. Might be worth a dedicated guardrail: \"before concluding 'X doesn't work in this environment,' run a probe that would distinguish a broken-invocation from an environment-constraint.\"