Generated commands don't match the user's known OS/shell (Bash emitted for Windows/PowerShell)

Environment: Claude Code (VSCode extension), Windows 11 / PowerShell — the standing, stated environment, known to the assistant before it generated the commands.

Problem: Claude Code repeatedly generated commands for the wrong shell/OS despite the known Windows/PowerShell context, forcing the user to correct or debug them.

Concrete instances in a single session:

• Bash syntax emitted for PowerShell: VAR=value assignments and $(...) command substitution — both are parse errors in PowerShell (The term 'VAR=value' is not recognized as the name of a cmdlet…).
• Fragile command wrapping: wrapping a client CLI in sh -c '…' produced mangled/blank output through PowerShell, where the direct form worked cleanly.
• Windows path not handled: kubectl cp given a Windows absolute source path (C:\Users\…) fails because the drive-letter colon is parsed as the pod:path separator (error: one of src or dest must be a local file specification); a relative, colon-free source path is required. This is a well-known Windows kubectl cp gotcha that was not accounted for.
• Trailing inline # comments on command lines (with a → arrow) bled into command output through the paste flow, corrupting a query result.

Expected: Generated commands should default to the session's known OS/shell (PowerShell syntax here) and account for documented Windows-specific tooling quirks (e.g. the kubectl cp drive-colon).

Impact: Repeated corrections and lost time on an otherwise routine operational task; the OS/shell was known in advance, so the mismatches were avoidable.

Suggested fix: Bind generated commands to the session's known OS/shell; when a value, path, or quoting form is OS-sensitive, emit the form valid for that OS, and keep command blocks free of non-executable decoration.