fix(node-host): decode Windows exec output with active code page by Sid-Qin · Pull Request #30652 · openclaw/openclaw

Sid-Qin · 2026-03-01T13:04:42Z

Summary

Problem: exec / system.run output was always decoded as UTF-8, so Windows shells running on legacy code pages (for example CP936/GBK) rendered Chinese text as garbled characters.
Why it matters: Users can run commands successfully but cannot trust tool output, which blocks debugging and file verification workflows on Windows.
What changed: src/node-host/invoke.ts now resolves the active Windows console code page (chcp) once per process and decodes captured stdout/stderr buffers with the matching encoding before returning results.
What did NOT change: Command execution policy, allowlist/security checks, and non-Windows decoding behavior remain unchanged.

Change Type (select all)

Scope (select all touched areas)

Linked Issue/PR

Closes [Bug] exec tool output encoding issue on Windows - Chinese characters display as garbled text #30640

User-visible / Behavior Changes

On Windows, system.run/exec output now preserves non-UTF-8 console text (e.g. GBK Chinese output) instead of showing replacement characters.

Security Impact (required)

New permissions/capabilities? No
Secrets/tokens handling changed? No
New/changed network calls? No
Command/tool execution surface changed? No
Data access scope changed? No

Repro + Verification

Environment

OS: macOS (dev) + Windows code page behavior validated via unit tests
Runtime: Node.js 24.x
Integration/channel: node-host system.run path

Steps

On Windows with code page 936, execute a command that emits Chinese text through exec/system.run.
Observe output rendering before vs after this patch.

Expected

Output keeps original Chinese characters.

Actual

Before fix: output contained garbled characters (�/乱码).
After fix: output is decoded with the active console code page and renders correctly.

Evidence

pnpm exec vitest run src/node-host/invoke.sanitize-env.test.ts
pnpm exec vitest run src/node-host/invoke-system-run.test.ts

Human Verification (required)

Verified scenarios: code page parsing from chcp output; GBK decoding path; existing node-host system-run tests.
Edge cases checked: unknown/unsupported encoding falls back to UTF-8; non-Windows platforms remain UTF-8.
What I did not verify: live manual run on a physical Windows machine in this environment.

Compatibility / Migration

Backward compatible? Yes
Config/env changes? No
Migration needed? No

Failure Recovery (if this breaks)

How to disable/revert: revert this PR commit.
Files/config to restore: src/node-host/invoke.ts and test updates.
Known bad symptoms: Windows output may revert to UTF-8-only decoding and show mojibake again.

Risks and Mitigations

Risk: chcp output may be unavailable in some shells.
Mitigation: decoding safely falls back to UTF-8 when code page resolution fails.

Decode system.run stdout/stderr on Windows using the current console code page so non-UTF-8 shells (for example CP936/GBK PowerShell) no longer produce garbled text. Adds regression coverage for code page parsing and GBK output decoding. Closes openclaw#30640

chatgpt-codex-connector

💡 Codex Review

Here are some automated review suggestions for this pull request.

Reviewed commit: a603fc8c09

ℹ️ About Codex in GitHub

Your team has set up Codex to review pull requests in this repo. Reviews are triggered when you

Open a pull request for review
Mark a draft as ready
Comment "@codex review".

If Codex has suggestions, it will comment; otherwise it will react with 👍.

Codex can also answer questions or update the PR. Try commenting "@codex address that feedback".

chatgpt-codex-connector · 2026-03-01T13:07:28Z

src/node-host/invoke.ts

+      const stdout = decodeCapturedOutputBuffer({
+        buffer: Buffer.concat(stdoutChunks),
+        windowsEncoding,
+      });


Avoid decoding all Windows output as console code page

runCommand now always decodes captured Windows output with windowsEncoding, which is derived from chcp and applied to every spawned process. On non-UTF-8 consoles, this mis-decodes tools that already emit UTF-8 bytes (for example Node-based CLIs and other cross-platform binaries), so valid UTF-8 output is converted into mojibake; this is a behavior regression from the previous UTF-8 decoding path for those commands. Restricting code-page decoding to cmd.exe-style output (or adding UTF-8 fallback heuristics per process) would avoid corrupting these cases.

Useful? React with 👍 / 👎.

greptile-apps · 2026-03-01T13:15:00Z

Greptile Summary

This PR fixes Windows command output decoding by detecting and using the active console code page instead of always assuming UTF-8. The implementation adds a chcp detection mechanism that runs once per process and caches the result, then decodes captured stdout/stderr buffers with the appropriate encoding (e.g., GBK, Shift_JIS) before returning results.

Key changes:

Added parseWindowsCodePage() to extract code page numbers from chcp output
Added resolveWindowsConsoleEncoding() to detect Windows console encoding once per process with caching
Added decodeCapturedOutputBuffer() to decode buffers using the detected encoding with UTF-8 fallback
Modified runCommand() to collect raw Buffer chunks instead of strings, then decode at finalization time
Added comprehensive test coverage for code page parsing and GBK decoding

Design strengths:

Robust error handling with UTF-8 fallback at every layer
Non-Windows platforms unchanged (early return)
UTF-8 code page (65001) explicitly handled to maintain existing behavior
Module-level caching prevents redundant chcp calls
Buffer-based collection preserves raw bytes for correct decoding

Confidence Score: 4/5

This PR is safe to merge with minimal risk - it's a well-contained bug fix with appropriate fallbacks and no security surface changes.
The implementation is solid with excellent error handling, comprehensive test coverage, and backward compatibility. Score is 4 instead of 5 only because manual verification on a physical Windows machine with legacy code pages hasn't been performed (as noted in PR description), though unit tests provide strong confidence.
No files require special attention - both changes are well-implemented with appropriate error handling and test coverage.

_{Last reviewed commit: a603fc8}

Takhoffman · 2026-03-02T13:50:28Z

PR #30652 - fix(node-host): decode Windows exec output with active code page (#30652)

Merged via squash.

Merge commit: 7b5a410
Verified: pnpm vitest run src/node-host/invoke.sanitize-env.test.ts src/node-host/invoke-system-run.test.ts
Changelog: no entry required for this canonicalization run.

Thanks @Sid-Qin!

@Sid-Qin