[Bug] Windows child-process output can use the wrong code page

[VeraPyuyi]

Affected area

CLI / daemon

Installation method

Built from source

Lody version or commit

d924231b95e91c8c25e073292d5f01b5a8549b97 (current main on 2026-08-28)

Operating system

Windows 11 x64 with a non-UTF-8 active console code page such as CP936

Agent or runtime

Lody CLI on Node.js 22.14+

What happened?

When a Windows child process emits bytes in the active console code page, the CLI chooses a decoder from locale variables instead of the active Windows code page. Locale variables can be absent or unrelated to the console setting; for example, a CP936 console combined with C.UTF-8 locale values can fall through to the wrong decoder and corrupt Chinese terminal or command output.

What did you expect?

The CLI should decode non-UTF-8 child-process output using the active Windows code page when it can be detected safely, while retaining deterministic locale fallback when probing is unavailable.

How can we reproduce it?

1. Use Windows with the active console code page set to 936.
2. Set locale variables to a value that does not identify CP936, such as C.UTF-8, or leave them unset.
3. Run a child command through Lody that writes synthetic Chinese text encoded as CP936.
4. Observe that the current locale-based fallback can select a different decoder and produce corrupted output.

How often does it happen?

Every time

Relevant log output

The same CP936 byte sequence decodes correctly with cp936 but is corrupted when the locale fallback selects another code page.

Additional context

An implementation already exists in #70. That PR was opened on 2026-08-27, before the contribution-intake policy in #91 merged on 2026-08-28. I am not treating this issue as retroactive approval. I am asking a Lody maintainer to explicitly confirm whether the proposed approach is acceptable: resolve the kernel-owned \\?\GLOBALROOT\SystemRoot\System32\chcp.com alias, execute that read-only system utility directly with bounded time/output, parse localized output defensively, cache successful detection with retry after transient failure, and retain locale fallback. A matching attacker-controlled SystemRoot / WINDIR / ComSpec regression is included. I will not push the prepared follow-up until explicit maintainer agreement is recorded. If a maintainer prefers a narrower approach or does not want the change, I will adjust or close the PR.

Before submitting

• I searched the existing issues and did not find a duplicate.
• This report concerns an open-source component in this repository, not a hosted service, Web or mobile app, account, or billing issue.
• This is not a security vulnerability; security reports follow the repository's security policy.
• I removed credentials, private source, conversations, prompts, personal data, and other sensitive information.
• If I plan to submit a pull request, I will wait for a Lody maintainer to explicitly agree on the scope and approach before implementation.

[VeraPyuyi]

This issue documents the scope for the existing PR #70, which predates the current intake policy. The reviewed follow-up uses a read-only, bounded active-code-page probe, fails closed to locale fallback, and adds focused regression coverage. Could a maintainer please confirm whether this scope and approach are acceptable before I update the PR branch?