fix(browser): decode Browser Use CLI stdout as UTF-8

[olympusbuildz]

Problem

On Windows, browser_exec (Browser Use CLI backend) can return empty output even when the CLI succeeds. The subprocess reader thread dies with:

UnicodeDecodeError: 'charmap' codec can't decode byte 0x90 … (cp1252)

Root cause

tools/browser_use_cli.py browser_exec calls subprocess.run(..., text=True) without encoding=. On Windows that decodes pipes with locale.getpreferredencoding() while the Browser Use CLI emits UTF-8. Non-ASCII page text (em dash, €, …) crashes the reader.

The sibling install_cli path in the same file already passes encoding="utf-8", errors="replace". This call site was missed after the Browser Use CLI backend landed (related class: #47939 / #47456).

Fix

Pass encoding="utf-8", errors="replace" on the exec subprocess.run, matching install_cli and other Windows-safe tool call sites.

Why it matters

Windows users get intermittent empty browser_exec results on any page with non-ASCII text — looks like flaky browser automation, is a decode bug.

Test plan

python -m pytest tests/tools/test_browser_use_cli.py::TestBrowserExec -q

9 passed @ this head (includes new regressions: kwargs assert utf-8/replace; non-ASCII stdout round-trip via UTF-8 fake CLI).

Risk

Low — same decode policy as install path; errors="replace" avoids hard-fail on rare invalid bytes.

Closest work

none found (open PR search for #87152 / browser_use_cli encoding empty)

Fixes #87152

Acceptance retest (2026-08-18)

Rebased onto current main. Mini proof @ 1bafe2b68: tests/tools/test_browser_use_cli.py — 94 passed.

[Enough1122]

AI code review — automated review for reference, author can ignore or act on any point.

fix(browser): decode Browser Use CLI stdout as UTF-8

No blocking issues found. A few minor observations:

1. errors="replace" means genuinely non-UTF-8 output (e.g. a binary blob the CLI writes to stdout) is silently mojibake'd instead of surfaced as an error. For a text-oriented CLI this is the right default and matches the existing install_cli call site, but the replacement is silent — if binary output is ever expected (screenshots, file dumps), consider logging when the decode actually replaced bytes.
2. The two new tests exercise POSIX-only fixtures: test_exec_preserves_non_ascii_utf8_stdout writes a shebang script and relies on chmod + direct-exec, and _fake_cli uses cat > /dev/null — both fail to spawn on native Windows. Confirm these tests carry the appropriate OS marker (or are placed on a POSIX lane), otherwise the Windows test lane breaks despite this being a Windows-targeted fix.
3. Minor: test_exec_subprocess_decodes_stdout_as_utf8 asserts only the kwargs the subprocess was called with; the second test covers actual decoded content, so behavior is pinned — good pairing.

[lzmuhioin]

Confirmed reproduction on Chinese Windows (GBK locale, cp936), and it hits BOTH directions — not just reading the CLI's UTF-8 stdout:

1. Read direction (the reported one): while browser_exec runs, the subprocess reader thread throws UnicodeDecodeError: 'gbk' codec can't decode byte 0xae in position 203: illegal multibyte sequence — e.g. when the CLI prints a rich progress line like Opening the opencode usage page containing UTF-8 special chars. Because the failure lives in subprocess._readerthread, it only prints an "Exception in thread Thread-30 (_readerthread)" traceback and the parent keeps running with a None stdout.

2. Write direction (also reproduces on Chinese Windows): the input=code path is encoded with the ANSI/GBK locale, so any Chinese comment in the code argument crashes inside the CLI with UnicodeDecodeError: 'utf-8' codec can't decode byte 0xb2 in position 2: invalid start byte (0xb2 is the leading byte of 查 in GBK).

Both disappear after adding encoding="utf-8", errors="replace" to the subprocess.run(..., text=True) call in tools/browser_use_cli.py browser_exec, exactly matching the existing uv tool install call a few lines above which already has both kwargs. Confirmed working end-to-end on Windows 11 + Chrome via CDP after the fix.

Additional data point: Hermes 0.20.1 (git 423f92e) in an editable/git install still contains the unfixed call — so this affects the currently distributed version.

[Enough1122]

AI code review — automated review for reference, author can ignore or act on any point.

Confirmed — Both read and write GBK-decoding directions confirmed addressed. Good.