osw --json writes non-UTF-8 bytes on Windows for any non-ASCII text #187

osw --json <command> produces output that is not valid UTF-8 whenever the result contains a non-ASCII character. The command exits 0, so the failure appears only in whatever consumes the output.

Code is on feat/mcp-server, not yet on main.

Reproduction (Windows, redirected stdout):

osw --instance <instance> --json entity get Item:OSWf21509637dba4f18844ab42b1754d6e0 > out.json

The label is Bugs fixen und Änderungen paketieren. The bytes written are:

b' und \xc4nderungen '

\xc4 is cp1252. UTF-8 requires \xc3\x84. open('out.json','rb').read().decode('utf-8') fails with 'utf-8' codec can't decode byte 0xc4 in position 439: invalid continuation byte.

Cause

• src/osw/cli/render.py#L27 serialises with ensure_ascii=False, so non-ASCII characters reach stdout literally. Same at #L53 and #L59, and in src/osw/service/serialization.py#L20 and #L48.
• typer.echo at src/osw/cli/main.py#L157 then writes through a stdout that Python encodes with the locale encoding, not UTF-8, when output is redirected.

Impact

Every German label on the AFIN instances hits this. An agent or script piping --json into a JSON parser gets a decode error with no indication of which command produced it. Observed costing two wasted CLI invocations and three decode attempts in one automated run.

Possible directions

• Use the json.dumps default of ensure_ascii=True in the --json path, which escapes non-ASCII to \uXXXX and makes the output encoding-independent.
• Or write to a UTF-8 wrapped stdout explicitly, for example io.TextIOWrapper(sys.stdout.buffer, encoding='utf-8').

Workarounds today

Read with encoding='cp1252', run the consumer with -X utf8, or set PYTHONIOENCODING=utf-8 before the call.