Greptile Summary

This PR fixes garbled Chinese characters on Windows by switching to encoding: 'buffer' in exec calls and decoding via a UTF-8 validity check + TextDecoder with the detected code-page encoding. It also addresses previous review feedback: resolveWindowsConsoleEncoding is now exported, isValidUtf8Buffer does a full round-trip comparison (no partial sampling), the catch fallback is utf-8 instead of hardcoded GBK, and child.ts uses TextDecoder with { stream: true } to handle multi-byte characters across chunk boundaries.

Confidence Score: 5/5

Safe to merge; all remaining findings are minor style issues.

The core encoding logic is sound — UTF-8 validity is checked before falling back to the code-page encoding, the catch fallback is now UTF-8 (not GBK), streaming decode uses { stream: true }, and previous reviewer concerns have been addressed. Only P2 style findings remain (unused imports in exec.ts, Chinese comments).

No files require special attention.

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

Comment:
**Unused imports**

`TextDecoder` and `resolveWindowsConsoleEncoding` are both imported but never referenced in this file. Encoding is performed entirely through `decodeCapturedOutputBuffer`, which calls `resolveWindowsConsoleEncoding` internally.

```suggestion
import { promisify } from "node:util";
import { decodeCapturedOutputBuffer } from "../node-host/invoke.js";
```

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/node-host/invoke.ts
Line: 136-143

Comment:
**Chinese comments in English codebase**

Several new comments are written in Chinese (`// 先尝试用 GBK 解码 chcp 输出（Windows 中文默认编码）`, `// 不管标称编码是什么，先检测是否为有效 UTF-8`, etc.), while the rest of the file and repository use English comments. For consistency and readability across contributors, these should be in English. The same pattern appears in `isValidUtf8Buffer` and `decodeCapturedOutputBuffer`.

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

_{Reviews (12): Last reviewed commit: "Merge branch 'main' into fix/windows-exe..." | Re-trigger Greptile}

@greptileai review

@greptileai review

@greptileai review

Hi there! 👋

Just a gentle ping about this PR fixing the Windows exec Chinese character encoding issue.

The fix uses the existing project utilities (decodeCapturedOutputBuffer and resolveWindowsConsoleEncoding) to properly handle GBK/CP936 encoding on Windows, with graceful fallback to UTF-8.

I've verified the fix works correctly locally - Chinese output now displays properly!

@vincentkoc Would appreciate if you could take a look when you have a moment. Thanks! 🙏

(Also, let me know if anything needs to be adjusted!)

@greptileai review

@greptileai review

@greptileai review

Tip:

Greploops — Automatically fix all review issues by running /greploops in Claude Code. It iterates: fix, push, re-review, repeat until 5/5 confidence.

Use the Greptile plugin for Claude Code to query reviews, search comments, and manage custom context directly from your terminal.

@greptileai review

Closing this as duplicate or superseded after Codex automated review.

This PR is superseded by the open maintainer replacement #72393, which explicitly credits this TextDecoder/codepage-aware direction and tracks the same Windows CJK exec-output bug against the canonical issue #50519. Current main has not shipped the fix yet, so this is a superseded-PR close rather than implemented-on-main.

Best possible solution:

Close this PR as superseded by #72393. Maintainers should continue review and validation on #72393 as the canonical Windows command-output decoding fix, preserve the credit it already gives to this contribution, keep #50519 open until the replacement lands, and split any residual PTY-specific encoding concern into a narrow follow-up only if current behavior still reproduces there.

What I checked:

• Current main still forces UTF-8 in runExec: At current main 4b9c857, runExec still passes encoding: "utf8" to execFileAsync and returns already-decoded stdout/stderr, so the underlying bug is not fixed on main by this PR. (src/process/exec.ts:138, 4b9c85776d29)
• Current main still default-decodes spawn chunks: runCommandWithTimeout still appends stdout/stderr with d.toString(), which defaults to UTF-8 and does not preserve raw Windows codepage bytes or split multibyte characters. (src/process/exec.ts:340, 4b9c85776d29)
• Current main only has partial node-host decoding: The existing codepage map and decodeCapturedOutputBuffer helper are still local to the node-host path; current process exec and supervisor child paths do not use it. The only GBK regression coverage found is the node-host helper test, not process exec decoding. (src/node-host/invoke.ts:36, 4b9c85776d29)
• Maintainer replacement is now canonical: fix(process): decode Windows command output with console codepage awareness #72393 is open, authored by a MEMBER, labeled maintainer, says it fixes [Bug]: Windows exec tool produces garbled Chinese characters due to hardcoded UTF-8 encoding #50519, and explicitly says it supersedes this PR while carrying forward credit for @knightplat-blip / heiqishi666 and the TextDecoder/codepage-aware repair direction. (aeaf4697880d)
• Replacement covers the requested implementation shape: fix(process): decode Windows command output with console codepage awareness #72393 adds a shared Windows output decoder, prefers strict valid UTF-8 before console-codepage fallback, switches runExec to buffer capture, decodes runCommandWithTimeout from concatenated buffers, and adds a stateful streaming decoder for supervisor child output. (src/infra/windows-encoding.ts:52, aeaf4697880d)
• Replacement adds focused regression coverage: fix(process): decode Windows command output with console codepage awareness #72393 adds tests for GBK output, valid UTF-8 preference on Windows, GBK bytes split across chunks, and split UTF-8 streaming decode, plus process exec Windows tests for runExec and spawn output. (src/infra/windows-encoding.test.ts:17, aeaf4697880d)

So I’m closing this here and keeping the remaining discussion on the canonical linked item.

Codex Review notes: model gpt-5.5, reasoning high; reviewed against 4b9c85776d29.