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

[MichalProchazka]

Running any kbagent --json ... command whose output contains non-ASCII characters (in our case an arrow present inside a flow name) crashes on Windows instead of printing JSON.

Reproduced with:

kbagent --json flow list

Traceback (trimmed):

File "keboola_agent_cli/commands/flow.py", line 200, in flow_list
    formatter.output(result)
File "keboola_agent_cli/output.py", line 57, in output
    sys.stdout.write(response.model_dump_json(indent=2) + "\n")
File ".../encodings/cp1250.py", line 19, in encode
    return codecs.charmap_encode(input,self.errors,encoding_table)[0]
UnicodeEncodeError: 'charmap' codec can't encode character '→' in position 28156: character maps to <undefined>

Environment: Windows 11, PowerShell/Git Bash, default console codepage cp1250 (not UTF-8).

Workaround: forcing UTF-8 before invoking the CLI avoids the crash:

PYTHONIOENCODING=utf-8 PYTHONUTF8=1 kbagent --json flow list

Why this matters: --json mode exists specifically for machine consumption (piping to a file or another program), so it shouldn't depend on the active console codepage. Any project/flow/config name containing a non-ASCII character (arrows, accented characters, emoji, etc.) makes --json unusable on a default Windows terminal.

Suggested fix: in JSON/machine-output mode, output.py should write to stdout using UTF-8 explicitly (e.g. reconfigure sys.stdout encoding, or write UTF-8 bytes directly) instead of relying on the inherited console codepage.

[padak]

Fixed in #549, now on main. Thank you for this one — the report was precise enough to
aim the fix properly, and the diagnosis you offered turned out to be exactly right.

Being specific about what was broken, because it is narrower than it looks: of the three
JSON writers, only the two pydantic ones could crash. model_dump_json emits raw
non-ASCII, whereas json.dumps escapes it to \uXXXX under its ensure_ascii default.
So output() and success() failed while the error envelope did not.

All machine-readable output now goes through one writer that emits UTF-8 bytes via
sys.stdout.buffer, bypassing the console encoder entirely. Your PYTHONUTF8=1
workaround is no longer needed.

Review also caught a place my first patch missed: kbagent --json agent run --stream
builds its own NDJSON with ensure_ascii=False and wrote it straight to stdout, so
streaming would still have crashed on cp1250. That is fixed too.

Verified by reproducing your failure end to end rather than only in unit tests:

PYTHONIOENCODING=cp1250 kbagent --json changelog --limit 8 --full

fails with UnicodeEncodeError: 'charmap' codec can't encode characters before the fix
and exits 0 with valid UTF-8 JSON after it. The regression tests simulate the cp1250
encoder, so they run on every platform, and I confirmed each one fails without the fix
rather than assuming it would.

One small behaviour change worth knowing: on Windows, JSON lines now end LF rather than
CRLF, because the binary buffer does no newline translation. For piped machine output
that is the better default and no JSON parser cares.

Your other report, #545, is fixed as well — same root cause as #528, and #543 landed for
it.

Both ship in v0.78.0, which will bundle several PRs. I am leaving this open until
that release is out so you can confirm on your own machine; please do reopen or shout if
anything still misbehaves.