fix: add explicit encoding="utf-8" to subprocess.run calls with text=True

[AlexFucuson9]

Problem

subprocess.run(..., text=True) without encoding= defaults to the system's locale encoding. On non-UTF-8 locales (Windows with CP1252, Linux with C locale), this can produce garbled output or UnicodeDecodeError.

# Current — uses locale encoding (may not be UTF-8)
result = subprocess.run(cmd, capture_output=True, text=True, timeout=120)

# Fixed — explicitly uses UTF-8
result = subprocess.run(cmd, capture_output=True, text=True, encoding="utf-8", timeout=120)

Files changed (11 fixes in 8 files)

File	Context
skills/creative/comfyui/scripts/auto_fix_deps.py	dependency install
tools/tts_tool.py	TTS engine
tools/transcription_tools.py	transcription (3 calls)
tools/environments/singularity.py	Singularity container
tools/voice_mode.py	voice mode (2 calls)
hermes_cli/setup.py	SSH setup
hermes_cli/main.py	CLI command runner
tui_gateway/server.py	TUI gateway

All changes verified with py_compile.

[alt-glitch]

This was generated by AI during triage.

Related to the ongoing Windows/non-UTF-8 subprocess-encoding rollout (#25200 helper, #43494 gateway, #45144 Copilot ACP, #49564 doctor) — this PR covers additional unguarded subprocess.run(text=True) sites, so it's complementary rather than a duplicate. Note it adds encoding="utf-8" but not errors="replace" that some sibling PRs use.

@christian-byrne Tagging you on this ComfyUI item (it touches skills/creative/comfyui/scripts/auto_fix_deps.py).

[AlexFucuson9]

This PR adds encoding='utf-8' to subprocess.run() calls with text=True that are missing it. This is part of the broader Windows encoding fix effort. The change is minimal and targeted — only adding the missing encoding parameter to prevent UnicodeDecodeError on non-UTF-8 Windows locales.

[teknium1]

Thanks for the targeted Windows-locale fix. The premise remains valid on current main: hermes_cli/main.py:1184, hermes_cli/setup.py:1430, tools/transcription_tools.py:1191, tools/tts_tool.py:1884, and tui_gateway/server.py:9723-9725 still use locale-decoded text=True subprocess output without an explicit encoding.

Problems

• GitHub reports this PR as conflicting. The current PDF-rendering call is at tui_gateway/server.py:9723-9725 and now includes creationflags=windows_hide_flags(); preserve that while applying the encoding change.
• The patch is incomplete for its stated bug class. The touched Singularity backend has additional unguarded calls at tools/environments/singularity.py:47-50, 137-141, and 252-256; the TUI gateway also has runtime paths at tui_gateway/server.py:11796-11806, 11865-11873, and 14416-14419.
• The diff adds no regression coverage; py_compile only validates syntax.

Suggested changes

• Salvage the TUI hunk onto its current location while retaining the Windows creation flags.
• Expand the rollout or align with cross-referenced PR fix: add explicit UTF-8 encoding to all subprocess text=True calls (#53428) #55339.
• Add a focused subprocess-boundary regression assertion for encoding="utf-8".

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.