Decode cmd.exe output buffers before returning stdout/stderr

When runExec takes the Windows .cmd/.bat wrapper path and sets encoding: "gbk", Node does not decode that code page for execFile; it returns Buffers instead. The new fallback here then calls rawStdout.toString() / rawStderr.toString() with no encoding, which reinterprets those bytes as UTF-8, so any non-ASCII cmd.exe output (including the Chinese text from #50519) is still mojibake. This needs a real code-page decode step, like the existing Windows buffer-decoding logic elsewhere in the repo, rather than the default Buffer.toString().

Useful? React with 👍 / 👎.

GBK encoding fix is fundamentally broken

'gbk' is not a valid Node.js Buffer encoding — Buffer.isEncoding('gbk') returns false. The encoding option of execFileAsync (which wraps execFile) is only effective for the Node.js-native encoding list ('utf8', 'latin1', 'ascii', 'utf16le', 'base64', 'hex', etc.). Passing an unrecognized encoding like 'gbk' leads to one of these outcomes depending on the Node.js version:

1. ERR_UNKNOWN_ENCODING is thrown — breaking all cmd.exe executions entirely.
2. The encoding is silently ignored — output is decoded as UTF-8, same as before.
3. A raw Buffer is returned — which the code handles via the .toString() fallback below.

The third case is what the author observed (hence the comment on line 144), but then:

const stdout = typeof rawStdout === "string" ? rawStdout : (rawStdout?.toString() ?? "");

Buffer.prototype.toString() with no argument defaults to 'utf8'. This means GBK bytes are still decoded as UTF-8 — the original garbling problem is not fixed.

The correct approach is to request raw buffers explicitly and then decode with an encoding-aware API:

// Use 'buffer' encoding to always receive raw Buffers from execFileAsync
const bufferOptions = typeof opts === "number"
  ? { timeout: opts, encoding: "buffer" as const }
  : { timeout: opts.timeoutMs, maxBuffer: opts.maxBuffer, cwd: opts.cwd, encoding: "buffer" as const };

const { stdout: rawStdout, stderr: rawStderr } = useCmdWrapper
  ? await execFileAsync(process.env.ComSpec ?? "cmd.exe", [...], { ...bufferOptions, windowsVerbatimArguments: true })
  : await execFileAsync(execCommand, execArgs, bufferOptions);

// Decode using the appropriate encoding
// TextDecoder supports 'gbk' when Node.js is built with full ICU data
const decode = (buf: Buffer) =>
  useCmdWrapper ? new TextDecoder("gbk").decode(buf) : buf.toString("utf8");

const stdout = decode(rawStdout);
const stderr = decode(rawStderr);

Alternatively, use the iconv-lite package (already common in Node.js tooling) for robust cross-platform GBK decoding without ICU dependency.

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

Comment:
**GBK encoding fix is fundamentally broken**

`'gbk'` is not a valid Node.js Buffer encoding — `Buffer.isEncoding('gbk')` returns `false`. The `encoding` option of `execFileAsync` (which wraps `execFile`) is only effective for the Node.js-native encoding list (`'utf8'`, `'latin1'`, `'ascii'`, `'utf16le'`, `'base64'`, `'hex'`, etc.). Passing an unrecognized encoding like `'gbk'` leads to one of these outcomes depending on the Node.js version:

1. **`ERR_UNKNOWN_ENCODING` is thrown** — breaking all cmd.exe executions entirely.
2. **The encoding is silently ignored** — output is decoded as UTF-8, same as before.
3. **A raw Buffer is returned** — which the code handles via the `.toString()` fallback below.

The third case is what the author observed (hence the comment on line 144), but then:

```typescript
const stdout = typeof rawStdout === "string" ? rawStdout : (rawStdout?.toString() ?? "");
```

`Buffer.prototype.toString()` with no argument defaults to `'utf8'`. This means GBK bytes are _still_ decoded as UTF-8 — the original garbling problem is not fixed.

**The correct approach** is to request raw buffers explicitly and then decode with an encoding-aware API:

```typescript
// Use 'buffer' encoding to always receive raw Buffers from execFileAsync
const bufferOptions = typeof opts === "number"
  ? { timeout: opts, encoding: "buffer" as const }
  : { timeout: opts.timeoutMs, maxBuffer: opts.maxBuffer, cwd: opts.cwd, encoding: "buffer" as const };

const { stdout: rawStdout, stderr: rawStderr } = useCmdWrapper
  ? await execFileAsync(process.env.ComSpec ?? "cmd.exe", [...], { ...bufferOptions, windowsVerbatimArguments: true })
  : await execFileAsync(execCommand, execArgs, bufferOptions);

// Decode using the appropriate encoding
// TextDecoder supports 'gbk' when Node.js is built with full ICU data
const decode = (buf: Buffer) =>
  useCmdWrapper ? new TextDecoder("gbk").decode(buf) : buf.toString("utf8");

const stdout = decode(rawStdout);
const stderr = decode(rawStderr);
```

Alternatively, use the `iconv-lite` package (already common in Node.js tooling) for robust cross-platform GBK decoding without ICU dependency.

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

GBK hardcoded for all Windows — breaks non-Chinese locales

Windows cmd.exe's default code page depends on the system locale, not just whether it's Windows. Hardcoding 'gbk' (CP936) here means:

• Chinese (Simplified) Windows: correct fix
• Japanese Windows (CP932 / Shift-JIS): Japanese non-ASCII output is now garbled with GBK decoding
• Western European Windows (CP1252): accented characters like é, ü, ñ are misread
• Eastern European (CP1250), Cyrillic (CP1251), etc.: similarly broken

The code page should be read dynamically. A robust approach is to run chcp 65001 before the command to force UTF-8 in cmd.exe (a common technique used by many tools), or detect the current code page:

// Append 'chcp 65001 > nul & ' to the cmd.exe command line to force UTF-8
const cmdLine = useCmdWrapper
  ? `chcp 65001 > nul & ${buildCmdExeCommandLine(execCommand, execArgs)}`
  : buildCmdExeCommandLine(execCommand, execArgs);

With chcp 65001, encoding: 'utf8' (the existing default) would work correctly for all locales, including Chinese.

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

Comment:
**GBK hardcoded for all Windows — breaks non-Chinese locales**

Windows cmd.exe's default code page depends on the system locale, not just whether it's Windows. Hardcoding `'gbk'` (CP936) here means:

- **Chinese (Simplified) Windows**: correct fix
- **Japanese Windows (CP932 / Shift-JIS)**: Japanese non-ASCII output is now garbled with GBK decoding
- **Western European Windows (CP1252)**: accented characters like `é`, `ü`, `ñ` are misread
- **Eastern European (CP1250)**, **Cyrillic (CP1251)**, etc.: similarly broken

The code page should be read dynamically. A robust approach is to run `chcp 65001` before the command to force UTF-8 in cmd.exe (a common technique used by many tools), or detect the current code page:

```typescript
// Append 'chcp 65001 > nul & ' to the cmd.exe command line to force UTF-8
const cmdLine = useCmdWrapper
  ? `chcp 65001 > nul & ${buildCmdExeCommandLine(execCommand, execArgs)}`
  : buildCmdExeCommandLine(execCommand, execArgs);
```

With `chcp 65001`, `encoding: 'utf8'` (the existing default) would work correctly for all locales, including Chinese.

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

Test verifies encoding option value but not actual output decoding

This test confirms that options.encoding is set to 'gbk' when the cmd.exe wrapper is used, but it doesn't validate that the output is correctly decoded from GBK bytes into a proper JavaScript string. Since 'gbk' is not a valid Node.js buffer encoding, setting options.encoding = 'gbk' has no meaningful effect — the test passes regardless of whether the GBK decoding actually works.

A meaningful test would:

1. Mock execFile to return a Buffer containing known GBK-encoded bytes (e.g., the GBK encoding of a Chinese string).
2. Assert that runExec returns those characters as the correct Unicode string.

Without such a test, the actual decoding behavior is unverified, and the test gives a false sense of correctness.

This is a comment left during a code review.
Path: src/process/exec.windows.test.ts
Line: 122-147

Comment:
**Test verifies encoding option value but not actual output decoding**

This test confirms that `options.encoding` is set to `'gbk'` when the cmd.exe wrapper is used, but it doesn't validate that the output is _correctly decoded_ from GBK bytes into a proper JavaScript string. Since `'gbk'` is not a valid Node.js buffer encoding, setting `options.encoding = 'gbk'` has no meaningful effect — the test passes regardless of whether the GBK decoding actually works.

A meaningful test would:
1. Mock `execFile` to return a Buffer containing known GBK-encoded bytes (e.g., the GBK encoding of a Chinese string).
2. Assert that `runExec` returns those characters as the correct Unicode string.

Without such a test, the actual decoding behavior is unverified, and the test gives a false sense of correctness.

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

Avoid cmd.exe escaping when the wrapper is not used

cmdExeCommandLine is computed unconditionally here, so buildCmdExeCommandLine/escapeForCmdExe now runs even when useCmdWrapper is false. That regresses ordinary execFile calls on every platform: src/link-understanding/runner.ts:60-68 and src/media-understanding/runner.entries.ts:634-642 both pass templated URLs/prompts through runExec, and common values like ...?a=1&b=2 or 100% will now throw Unsafe Windows cmd.exe argument detected before the process is launched. The cmd-specific escaping needs to stay inside the .cmd/.bat branch only.

Useful? React with 👍 / 👎.

Avoid switching arbitrary batch files to UTF-8 before launch

This helper is not limited to the ASCII pnpm.cmd shim covered by the new tests: exported callers like src/plugin-sdk/run-command.ts:16-30 can pass an actual user/plugin-provided .cmd/.bat path through runExec/runCommandWithTimeout. Prepending chcp 65001 changes the active code page before cmd.exe starts reading that batch file, so legacy wrappers saved in the machine code page (common for localized Windows scripts with non-ASCII literals or paths) are now parsed as UTF-8 and can mis-execute or fail before the real command runs. Decoding captured output after execution avoids mojibake without changing how existing batch files are interpreted.

Useful? React with 👍 / 👎.