fix(browser): prevent UnicodeDecodeError on Windows with non-UTF-8 subprocess output

[allin2]

Description

Fix UnicodeDecodeError in browser_tool.py when running on Windows with Chinese locale (GBK/CP936).

Problem

When agent-browser.cmd fails on Windows with a Chinese locale, the error message from cmd.exe is encoded in the system default charset (GBK), not UTF-8. Reading stderr with strict utf-8 codec raises:

UnicodeDecodeError: 'utf-8' codec can't decode byte 0xb2 in position 9: invalid start byte

This masks the original error (e.g., node not found) and makes all browser tools completely unusable on Windows Chinese systems.

Root Cause

In _run_browser_command() (lines 2113-2116), stdout and stderr temp files are read with encoding="utf-8" without error handling:

with open(stdout_path, "r", encoding="utf-8") as f:
    stdout = f.read()
with open(stderr_path, "r", encoding="utf-8") as f:
    stderr = f.read()

When agent-browser.cmd fails (e.g., node not found), cmd.exe outputs the error in GBK encoding. Byte 0xB2 at position 9 is not a valid UTF-8 start byte, triggering UnicodeDecodeError.

Fix

Add errors="replace" to the open() calls:

with open(stdout_path, "r", encoding="utf-8", errors="replace") as f:
    stdout = f.read()
with open(stderr_path, "r", encoding="utf-8", errors="replace") as f:
    stderr = f.read()

This replaces non-UTF-8 bytes with the Unicode replacement character (U+FFFD) instead of crashing, so the actual subprocess error message is visible to users and agents.

Impact

Scenario	Before	After
Normal UTF-8 output	Works	Works (unchanged)
GBK error on Windows	UnicodeDecodeError	Error message visible
Browser tools on Windows Chinese	All broken	All work

Other open(encoding="utf-8") calls in this file

• Line 927: Already wrapped in try/except Exception - safe
• Line 1304: open(..., "w") - write-only, no decoding risk
• Line 2050: Inside try/except OSError - safe
• Line 3665: Reads /proc/1/cgroup (Linux-only, always UTF-8) - safe

[alt-glitch]

Duplicate of #47516 — same fix (adding errors="replace" to the open(stdout_path/stderr_path, "r", encoding="utf-8") reads in tools/browser_tool.py) for the same bug (#47456, GBK/non-UTF-8 subprocess output on Windows). #47516 is the earlier open PR with the identical mechanism at the identical edit site.

[teknium1]

Thanks for identifying the Windows locale failure. The strict UTF-8 reads are still present on current main at tools/browser_tool.py:2477 and tools/browser_tool.py:2479, so the underlying bug remains real.

Problems

• The two-site change is incomplete on current main: _read_command_output_files() still reads the same temp files strictly at tools/browser_tool.py:322 (used by the timeout path at :2461), and Chrome fallback still does so at :1120.
• This branch is a whole-file rewrite (+3891/-3891) and GitHub reports it DIRTY; current main has substantially moved since its base.
• No regression test is included; tests/tools/test_browser_open_timeout.py:81 currently exercises only valid UTF-8 output.

Suggested changes

• Re-scope to a targeted, line-ending-preserving helper shared by all three subprocess-output paths, with malformed-byte regression coverage. The open cross-referenced PR fix(browser): safely decode subprocess output with regression coverage #63512 already contains a broader implementation to compare or salvage.

Automated hermes-sweeper review.

[teknium1]

Closing as resolved by PR #70875 (merged, commit 0f732cb), which closed out this bug class codebase-wide: every text=True subprocess call now passes encoding="utf-8", errors="replace", and a CI linter rule (scripts/check-windows-footguns.py) rejects any future unguarded site. The sites this PR targeted are all guarded on current main — verified per-file. Credit for the class fix goes to @Stoltemberg (#55339, the original sweep) and @jinglun010-cpu (#60741 + the #60751 linter); thanks for your fix as well — the volume of independent PRs on this bug is what escalated it to a class-wide close-out.