Skip to content

fix(output): force UTF-8 for machine output on non-UTF-8 consoles (#546) - #547

Draft
padak wants to merge 1 commit into
mainfrom
claude/issue-546-json-utf8-stdout
Draft

fix(output): force UTF-8 for machine output on non-UTF-8 consoles (#546)#547
padak wants to merge 1 commit into
mainfrom
claude/issue-546-json-utf8-stdout

Conversation

@padak

@padak padak commented Aug 1, 2026

Copy link
Copy Markdown
Member

What

kbagent --json <anything> crashed with UnicodeEncodeError on Windows whenever the payload contained a non-ASCII character (the reporter hit an arrow inside a flow name via kbagent --json flow list).

Machine output is now written as UTF-8 regardless of the console codepage:

  • New write_machine_output() in output.py, used by OutputFormatter.output/error/success, kbagent http, and the agent --stream NDJSON events.
  • force_utf8_stdout() reconfigures sys.stdout to UTF-8 (covers every real TextIOWrapper).
  • Belt-and-braces: on UnicodeEncodeError the payload is written as UTF-8 bytes to sys.stdout.buffer, which bypasses the text layer's codec. A stream with neither reconfigure nor buffer re-raises — for a machine consumer, a silently mangled payload is worse than a crash.

Why

sys.stdout inherits the console codepage — cp1250 on Czech/Polish/Hungarian Windows 11. pydantic's model_dump_json() emits raw UTF-8 rather than \uXXXX escapes, so the write hits the cp1250 codec and aborts the command. --json exists specifically for machine consumption (piping to a file or another program), so it must not depend on which terminal happens to be attached.

agent.py's stream events serialize with ensure_ascii=False and shared the same exposure; kbagent http used the json.dumps default (ensure_ascii=True) so it never crashed, but it is routed through the same helper for consistency.

Unlike the kbagent serve startup banner (#522, fixed in #526), transliterating to ASCII is not an option here: the banner is decoration, this is data.

How it was tested

  • New tests/test_json_output_encoding.py (24 tests): a cp1250 stdout double that raises exactly like a real Windows console, plus a fidelity guard proving the double reproduces the crash (so the passing tests are not vacuous). Covers the reconfigure path, the byte-level fallback, the no-fallback re-raise, and OutputFormatter.output/error/success round-tripping a through json.loads.
  • Live check under PYTHONIOENCODING=cp1250: a raw sys.stdout.write("extract → load") raises UnicodeEncodeError, while OutputFormatter(json_mode=True) now emits valid UTF-8 JSON that parses back with json.load, both to a terminal and through a pipe.
  • make check: lint + format + changelog-check + full suite (4707 passed, 8 skipped).

Modern UTF-8 terminals are byte-identical to before — no \uXXXX escaping is introduced.

Fixes #546

`kbagent --json <anything>` crashed on Windows with UnicodeEncodeError as
soon as the payload carried a non-ASCII character -- an arrow in a flow
name, an accented config name, an emoji. sys.stdout inherits the console
codepage (cp1250 on Czech/Polish/Hungarian Windows 11), and pydantic's
model_dump_json() emits raw UTF-8 rather than \uXXXX escapes, so the
write hit the cp1250 codec and aborted the command instead of printing
JSON. --json exists for machine consumption -- piping to a file or
another program -- so it must not depend on the attached terminal.

Add write_machine_output() in output.py and route every machine-output
writer through it: OutputFormatter.output/error/success, `kbagent http`,
and the agent --stream NDJSON events (the latter also serialized with
ensure_ascii=False, so it shared the crash).

Two layers: force_utf8_stdout() reconfigures the stream to UTF-8, which
covers every real TextIOWrapper; a UnicodeEncodeError fallback then
writes UTF-8 bytes to sys.stdout.buffer for streams that cannot be
reconfigured. A stream with neither surfaces the original error -- for a
machine consumer, a mangled payload would be worse than a crash.

Unlike the serve startup banner (#522), transliterating to ASCII is not
an option here: the banner is decoration, this is data.

Verified end to end under PYTHONIOENCODING=cp1250: the raw write raises,
the formatter now emits valid UTF-8 JSON that round-trips through
json.load. Modern UTF-8 terminals are byte-identical to before.
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.

--json output crashes with UnicodeEncodeError on Windows when data contains non-ASCII characters

1 participant