Skip to content

fix(cli,hooks): UTF-8 robustness on Windows (GBK) locales - #210

Open
raymondginger2018-sudo wants to merge 2 commits into
HKUDS:mainfrom
raymondginger2018-sudo:fix/utf8-windows-robustness
Open

fix(cli,hooks): UTF-8 robustness on Windows (GBK) locales#210
raymondginger2018-sudo wants to merge 2 commits into
HKUDS:mainfrom
raymondginger2018-sudo:fix/utf8-windows-robustness

Conversation

@raymondginger2018-sudo

Copy link
Copy Markdown
Contributor

Summary

Windows defaults the console to GBK/cp936. Two small fixes make the CLI robust to non-UTF-8 locales; each is a no-op where the locale is already UTF-8.

Changes

  1. cli/loop_cli.py — headless deepcode loop now calls core.platform_compat.configure_utf8_stdio() before the parser/Console are set up. Fixes UnicodeEncodeError when rich or model output renders non-GBK text (the recent dsh headless runs crashed on Windows otherwise).
  2. core/harness/hooks/discovery.py — read hooks.json / .claude/settings.json explicitly as UTF-8 instead of the locale default, so a GBK-locale console does not mis-decode (or raise on) non-GBK bytes in a UTF-8 hooks config.

Tests

  • Both changed modules import cleanly against this branch.
  • ruff check + ruff format --check pass under the repo-pinned ruff (pre-commit rev v0.15.21).
  • No behavior change on UTF-8-locale systems; CI will run the full suite.

Notes

Two independent commits, one logical concern (UTF-8 robustness). The CLI hunk is taken verbatim from our local working tree fix for the same crash.

Windows consoles default to GBK/cp936, so rich rendering or model output
that emits non-GBK text crashes with UnicodeEncodeError. Reconfigure stdio
to UTF-8 before the parser/Console are set up.

No behavior change on UTF-8-locale systems (the reconfigure is a no-op
there); copied verbatim from the working tree (e1e00cc5, cli hunk only).
hooks.json / .claude settings.json are written as UTF-8 JSON, but
Path.read_text() defaults to the locale encoding, so on a GBK/cp936 Windows
console a config containing non-GBK bytes is mis-decoded (or raises) before
parsing. Read explicitly as UTF-8; no behavior change on UTF-8 locales.
Sign up for free to join this conversation on GitHub. Already have an account? Sign in to comment

Labels

None yet

Projects

None yet

Development

Successfully merging this pull request may close these issues.

1 participant