Greptile Summary

This PR fixes Windows CJK (mojibake) output when running .cmd/.bat commands via runExec by prepending chcp 65001>nul && to the cmd wrapper command line when the encoding is UTF-8, and adds a regression test for this behaviour.

Key findings:

• Regression — unconditional buildCmdExeCommandLine call (P1): buildCmdExeCommandLine (which calls the argument-safety validator escapeForCmdExe) is now evaluated eagerly for every runExec call, not just those that go through the cmd wrapper. Arguments containing &, |, <, >, ^, or % will now throw "Unsafe Windows cmd.exe argument detected" on non-Windows paths and on Windows non-.cmd invocations, which is a behaviour regression from the original code.

• runCommandWithTimeout not updated (P2): The spawn-based runCommandWithTimeout function has an identical cmd wrapper path that does not receive the chcp 65001>nul && fix, leaving CJK output garbled in that code path.

• The encoding option addition and the chcp injection logic itself are correct; the UTF-8 code page change is guarded appropriately by process.platform === "win32", useCmdWrapper, and the encoding value.

Confidence Score: 2/5

• Not safe to merge as-is: the eager buildCmdExeCommandLine call introduces a regression that breaks non-cmd command invocations with shell-metacharacter arguments.
• The chcp injection concept is sound, but moving buildCmdExeCommandLine outside the useCmdWrapper guard is a correctness bug that causes spurious throws for previously-working call sites. This must be fixed before merging.
• src/process/exec.ts — specifically lines 135–139 where buildCmdExeCommandLine is called unconditionally.

This is a comment left during a code review.
Path: src/process/exec.ts
Line: 135-139

Comment:
**`buildCmdExeCommandLine` now called unconditionally, causing spurious throws**

`buildCmdExeCommandLine` calls `escapeForCmdExe`, which throws for any argument containing `&|<>^%\r\n`. In the original code this function was only invoked inside the `useCmdWrapper` ternary branch — JavaScript's lazy evaluation meant it was a no-op for non-`.cmd` commands. Now it is eagerly evaluated for *every* `runExec` call, including non-Windows paths and Windows calls to plain `.exe` commands.

For example, running a command like `runExec("grep", ["-P", "a|b"], ...)` on Linux, or `runExec("node.exe", ["--eval", "1+1"], ...)` on Windows, would now throw with `"Unsafe Windows cmd.exe argument detected"` even though neither path uses the cmd wrapper at all.

Move the call inside the branch where it is actually needed:

```suggestion
    const useCmdWrapper = isWindowsBatchCommand(execCommand);
    const wrappedCommandLine = (() => {
      if (!useCmdWrapper) return null;
      const cmdCommandLine = buildCmdExeCommandLine(execCommand, execArgs);
      return process.platform === "win32" && encoding.toLowerCase() === "utf8"
        ? `chcp 65001>nul && ${cmdCommandLine}`
        : cmdCommandLine;
    })();
```

Then reference `wrappedCommandLine!` in the `useCmdWrapper` branch and keep the `else` path unchanged.

How can I resolve this? If you propose a fix, please make it concise.

---

This is a comment left during a code review.
Path: src/process/exec.ts
Line: 235-239

Comment:
**`runCommandWithTimeout` not updated with the same fix**

`runCommandWithTimeout` uses `spawn` with a cmd wrapper path (lines 235–239) that passes its command line to `cmd.exe /c` without setting the UTF-8 code page. If a caller invokes a `.cmd`/`.bat` command that produces CJK output through this path the same mojibake issue will appear.

Consider applying the same `chcp 65001>nul &&` prefix here, or at minimum leaving a `// TODO` comment so the inconsistency is intentional and visible.

How can I resolve this? If you propose a fix, please make it concise.

_{Last reviewed commit: "process: fix Windows..."}

Thanks for the context here. I did a careful shell check against current main, and this is already implemented.

Close as implemented on main. Current main and v2026.4.26 fix the Windows exec CJK mojibake problem with a broader console-codepage-aware buffer decoder, and the merged maintainer replacement #72393 explicitly credited and superseded this PR.

Best possible solution:

Close this PR and keep the shipped #72393/v2026.4.26 implementation. It solves the same user problem more broadly than the chcp-prefix approach by decoding captured Windows process output with console-codepage awareness across exec and spawn paths.

What I checked:

• runExec implementation: runExec now asks execFile for raw Buffer output and decodes stdout/stderr through resolveWindowsConsoleEncoding plus decodeWindowsOutputBuffer, replacing the old hardcoded UTF-8 string decode path. (src/process/exec.ts:140, 2ccdbc7dd93b)
• spawn implementation: runCommandWithTimeout captures stdout/stderr chunks as Buffers, resolves the Windows console encoding once, and decodes the concatenated output through the same Windows decoding helper. (src/process/exec.ts:302, 2ccdbc7dd93b)
• Windows codepage helper: The shared helper maps Windows code pages including CP936/GBK, prefers valid UTF-8 output, and falls back to TextDecoder for the active console encoding when UTF-8 is invalid. (src/infra/windows-encoding.ts:4, 2ccdbc7dd93b)
• Regression coverage: Tests cover GBK stdout/stderr from runExec, valid UTF-8 output on Windows, split multibyte spawn chunks, and the lower-level codepage parser/decoder behavior. (src/process/exec.windows.test.ts:373, 2ccdbc7dd93b)
• Release evidence: The changelog records the shipped Process/Windows fix for [Bug]: Windows exec tool produces garbled Chinese characters due to hardcoded UTF-8 encoding #50519 and credits @zhangyongjie1997; the v2026.4.26 tag points at be8c246, which contains the implementation. (CHANGELOG.md:452, be8c24633aaa)
• Superseding PR context: Provided GitHub context shows fix(process): decode Windows command output with console codepage awareness #72393 was merged on 2026-04-27, says it fixes [Bug]: Windows exec tool produces garbled Chinese characters due to hardcoded UTF-8 encoding #50519, explicitly supersedes this PR, and carries forward credit for @zhangyongjie1997's focused regression coverage. (d1eedefc22a2)

So I’m closing this as already implemented rather than keeping a duplicate issue open.

Codex review notes: model gpt-5.5, reasoning high; reviewed against 2ccdbc7dd93b; fix evidence: release v2026.4.26, commit be8c24633aaa.