PowerShell: backslash escapes in command args are mangled and land literally in output

Summary

When an agent (e.g. opencode on win32/Windows PowerShell) passes a shell-style backslash-escaped string into a command argument, the escapes are mangled and land literally in the output.

Concrete failure

Building a gh pr create body with backslash-escaped backticks (\`) inside a double-quoted PowerShell argument produced a PR body containing literal \ characters:

• Expected: `SENTRY_AUTH_TOKEN` renders as inline code in markdown
• Got: \SENTRY_AUTH_TOKEN\
• Additionally \t was interpreted as a literal TAB character (\turbo.json → tab + turbo.json)

Why it recurs

The model correctly writes shell syntax with backslash escapes (POSIX convention), but Windows PowerShell 5.1 uses the backtick (`) as its escape character, not backslash. The result is:

1. Escaped characters (\`, \t, \", etc.) are passed through literally or partially interpreted
2. Multi-line \n sequences appear as literal \n text instead of newlines
3. Content that should be verbatim (markdown, code, JSON) gets corrupted at the shell boundary

Repro sketch

# PowerShell 5.1
gh pr create --body "Closes #1`n`nBody with \`code\`"
# -> body shows literal \code\ and literal \n

Expected behavior

Arguments that flow from the agent into shell commands should preserve content verbatim (ideally the harness writes files / uses --body-file-style patterns, or the agent avoids backslash-escaped sequences in PowerShell contexts), so escapes never corrupt user-facing content like PR bodies or commit messages.

Notes

• Environment: opencode CLI on win32, PowerShell 5.1
• This already corrupted a real PR description once; a documented/guarded pattern would prevent recurrence