agents-cli update floods console with Python UnicodeDecodeError tracebacks on non-UTF-8 Windows consoles

[lenintorresact]

agents-cli update floods the console with Python UnicodeDecodeError tracebacks on non-UTF-8 Windows consoles

Note: this report was drafted with AI assistance. The root cause, the reproduction, and the captured output were all verified on a real affected machine before filing.

Repo: google/agents-cli
Version: agents-cli 0.5.0
Platform: Windows 11 (Spanish locale, OEM code page cp850), Python 3.12, Node v24.16.0

Summary

Running agents-cli update prints many copies of this traceback (one per spawned reader thread):

Exception in thread Thread-N (_readerthread):
Traceback (most recent call last):
  File ".../threading.py", line 1012, in run
    self._target(*self._args, **self._kwargs)
  File ".../subprocess.py", line 1599, in _readerthread
    buffer.append(fh.read())
  File "<frozen codecs>", line 322, in decode
UnicodeDecodeError: 'utf-8' codec can't decode byte 0xa2 in position 3: invalid start byte

The update still proceeds (these are non-essential daemon reader threads), so it's cosmetic — but it's alarming noise and looks like a crash.

Root cause

agents-cli runs the underlying npx skills ... update command as a subprocess and reads its stdout/stderr in subprocess._readerthread, decoding as UTF-8. On a non-UTF-8 Windows console (here Spanish, OEM code page cp850) the child's output contains bytes that are not valid UTF-8 — e.g. 0xa2, which is ó in cp850. UTF-8 decoding of that byte raises UnicodeDecodeError and kills the reader thread.

The decode encoding is hard-coded rather than matched to the console code page, and there's no errors= fallback.

Reproduction

1. Windows with a non-UTF-8 OEM console code page (e.g. Spanish cp850).
2. Run agents-cli update.
3. Observe the repeated UnicodeDecodeError: 'utf-8' codec can't decode byte 0xa2 ... tracebacks.

Note: running the wrapped command directly (npx skills update -g) produces no such tracebacks — they come only from the Python subprocess wrapper's UTF-8 decoding.

Suggested fix

When capturing subprocess output, either:

• decode with a fallback: subprocess.Popen(..., encoding="utf-8", errors="replace") (or errors="backslashreplace"), or
• decode using the console's actual code page instead of hard-coding UTF-8 (e.g. locale.getpreferredencoding(False) / the OEM code page on Windows), or
• read bytes and decode explicitly with a fallback.

Any of these stops the reader threads from crashing on non-UTF-8 console output.