sweagent --help crashes with UnicodeEncodeError on default Windows consoles (cp1252 stdio)

Describe the bug

On stdio whose encoding cannot represent emoji — cp1252, the out-of-the-box console encoding on many Windows setups — every rich-rendered output path in sweagent dies with UnicodeEncodeError. In particular sweagent --help exits 1 having printed zero bytes of help.

It is a two-stage mechanism (traced first-hand at main = 3ea751c):

1. The import-time banner poisons rich's global Console buffer. sweagent/__init__.py:105 logs the version banner with a prefix through RichHandler, which renders via rich's global console. On a cp1252 stream the write raises UnicodeEncodeError mid-flush; logging swallows it (spewing a --- Logging error --- traceback to stderr on every import sweagent), but the unwritten segment — starting with the emoji — stays behind in the console's buffer.
2. The next rich print replays the poisoned buffer and dies unhandled. For --help that is rich.print(__doc__) at sweagent/run/run.py:80. The help docstring itself is pure ASCII (I checked every character); it never gets a chance. The same applies to any other rich output after import:

$ PYTHONIOENCODING=cp1252 python -c "import sweagent, rich; rich.print('hello')"
...
UnicodeEncodeError: 'charmap' codec can't encode character '\U0001f44b' in position 0: character maps to <undefined>
$ echo $?
1

A plain-ASCII rich.print('hello') exits 1 on the left over from the banner.

Related history: #1012 reported this class; the fix that closed it (#1013) pinned the log file handler to UTF-8 (FileHandler(path, encoding="utf-8")) — the console/stdout path was left as-is.

Steps/commands/code to Reproduce

On Windows with a default (cp1252) console:

git clone https://github.com/SWE-agent/SWE-agent
cd SWE-agent
python -m pip install --upgrade pip && pip install --editable .
sweagent --help

Deterministic on any OS/terminal (this is what makes it testable on ubuntu CI):

PYTHONIOENCODING=cp1252 sweagent --help

Controls, all run on this machine against the source install at 3ea751c:

The PYTHONUTF8=1 control shows it is purely a stream-encoding issue (not Python-version- or renderer-specific); the no-args control shows only the rich-rendered paths are affected. The piped repro takes rich's plain file.write path — the same one Linux uses — so it is not specific to the legacy Win32 console renderer either.

Error message/results

Trimmed to the two tracebacks (full stderr is 105 lines; the elision points are marked, nothing else altered):

--- Logging error ---
Traceback (most recent call last):
  File "...\rich\logging.py", line 186, in emit
    self.console.print(log_renderable)
  [...rich console internals...]
  File "...\Python313\Lib\encodings\cp1252.py", line 19, in encode
    return codecs.charmap_encode(input,self.errors,encoding_table)[0]
UnicodeEncodeError: 'charmap' codec can't encode character '\U0001f44b' in position 0: character maps to <undefined>
Call stack:
  [...]
Message: "This is SWE-agent version 1.1.0 (hash='3ea751c087f32b16e039a2233dd6eefecef325d5') with SWE-ReX version 1.4.0 (rex_hash='unavailable')."

Traceback (most recent call last):
  File "...\.venv\Scripts\sweagent.exe\__main__.py", line 5, in <module>
  File "...\sweagent\run\run.py", line 80, in main
    rich.print(__doc__)
  [...rich console internals: print → _exit_buffer → _write_buffer → write_text...]
  File "...\Python313\Lib\encodings\cp1252.py", line 19, in encode
    return codecs.charmap_encode(input,self.errors,encoding_table)[0]
UnicodeEncodeError: 'charmap' codec can't encode character '\U0001f44b' in position 0: character maps to <undefined>

The first block is the swallowed logging error (stage 1, printed on every import), the second is the unhandled one that kills the process (stage 2).

System Information

Windows 11 Home, Python 3.13.13 (python.org build), sweagent 1.1.0 installed from source at 3ea751c (pip install -e '.[dev]'), rich 15.0.0, swe-rex 1.4.0. No Docker involvement — this dies before any deployment code runs.

Checklist

• I'm running with the latest docker container/on the latest development version (i.e., I ran git pull))
• I have copied the full command/code that I ran (as text, not as screenshot!)
• If applicable: I have copied the full log file/error message that was the result (as text, not as screenshot!)
• I have enclosed code/log messages in triple backticks (docs) and clicked "Preview" to make sure it's displayed correctly.

I have a minimal fix ready — probe stdout/stderr at package init and, only where the stream cannot encode emoji, reconfigure it with errors="replace" so the banner degrades to ? instead of crashing — plus a regression test that forces the failure mode via PYTHONIOENCODING=cp1252, so it runs on the existing ubuntu CI. PR follows in a minute.