Skip to content

fix: add UTF-8 encoding for subprocess calls on Windows#139

Open
cabana8471-arch wants to merge 1 commit intoAutoForgeAI:masterfrom
cabana8471-arch:fix/windows-utf8-encoding
Open

fix: add UTF-8 encoding for subprocess calls on Windows#139
cabana8471-arch wants to merge 1 commit intoAutoForgeAI:masterfrom
cabana8471-arch:fix/windows-utf8-encoding

Conversation

@cabana8471-arch
Copy link
Contributor

@cabana8471-arch cabana8471-arch commented Jan 30, 2026

Summary

  • Fix Windows UTF-8 encoding issue in subprocess calls
  • Add encoding="utf-8" and errors="replace" to all subprocess calls that use text=True

Problem

Windows users experience UnicodeDecodeError when running parallel mode because subprocess.Popen with text=True defaults to CP1252 encoding instead of UTF-8.

Solution

Explicitly specify UTF-8 encoding for all subprocess calls that process text output from Claude agents.

Files Modified

  • parallel_orchestrator.py (3 locations)
  • start.py (2 locations)
  • start_ui.py (1 location)

Testing

  • Verified ruff linting passes: ruff check parallel_orchestrator.py start.py start_ui.py
  • The fix is low-risk and only explicitly specifies UTF-8 encoding which is already the expected behavior on non-Windows systems

Notes

Closes #138

🤖 Generated with Claude Code

Summary by CodeRabbit

  • Bug Fixes
    • Enhanced text encoding handling across system operations to improve Windows platform compatibility and prevent character encoding failures.
    • Improved error resilience during system initialization and background operations to ensure reliable text output processing.
    • Strengthened encoding error handling throughout critical system processes for more robust and stable operation.

✏️ Tip: You can customize this high-level summary in your review settings.

On Windows, subprocess.Popen/run with text=True defaults to CP1252
encoding instead of UTF-8. This causes UnicodeDecodeError when
Claude outputs characters outside the CP1252 codepage.

Add explicit encoding="utf-8" and errors="replace" parameters to
all subprocess calls that use text=True.

Files modified:
- parallel_orchestrator.py (3 locations)
- start.py (2 locations)
- start_ui.py (1 location)

Closes leonvanzyl#138

Co-Authored-By: Claude Opus 4.5 <noreply@anthropic.com>
@coderabbitai
Copy link

coderabbitai bot commented Jan 30, 2026

📝 Walkthrough

Walkthrough

Adds explicit UTF-8 encoding and error replacement parameters to subprocess invocations across three initialization and startup modules to resolve Windows CP1252 encoding issues. No control flow changes; parameters ensure robust text I/O handling on Windows environments.

Changes

Cohort / File(s) Summary
Subprocess Encoding Robustness
parallel_orchestrator.py, start.py, start_ui.py
Added encoding="utf-8" and errors="replace" parameters to subprocess.Popen and subprocess.run calls to handle Windows CP1252 encoding conflicts and prevent UnicodeDecodeError exceptions on non-ASCII byte sequences.

Estimated code review effort

🎯 2 (Simple) | ⏱️ ~8 minutes

Possibly related PRs

  • leonvarzyl/autocoder#89: Both PRs modify subprocess invocation parameters (Popen/run kwargs) in parallel_orchestrator.py and start.py for improved Windows compatibility and encoding robustness.

Poem

🐰✨ A little rabbit hops with glee,
UTF-8 flows so wild and free,
CP1252 troubles now fade away,
Windows encodes the proper way! 🖥️💨

🚥 Pre-merge checks | ✅ 5
✅ Passed checks (5 passed)
Check name Status Explanation
Description Check ✅ Passed Check skipped - CodeRabbit’s high-level summary is enabled.
Title check ✅ Passed The title accurately describes the main change: adding UTF-8 encoding to subprocess calls on Windows to fix encoding issues.
Linked Issues check ✅ Passed The PR directly addresses issue #138 by adding encoding='utf-8' and errors='replace' to all subprocess calls across three files, matching the exact solution proposed.
Out of Scope Changes check ✅ Passed All changes are directly scoped to the encoding fix in subprocess calls; no unrelated modifications were introduced.
Docstring Coverage ✅ Passed Docstring coverage is 100.00% which is sufficient. The required threshold is 80.00%.

✏️ Tip: You can configure your own custom pre-merge checks in the settings.

✨ Finishing touches
  • 📝 Generate docstrings
🧪 Generate unit tests (beta)
  • Create PR with unit tests
  • Post copyable unit tests in a comment

Thanks for using CodeRabbit! It's free for OSS, and your support helps us grow. If you like it, consider giving us a shout-out.

❤️ Share

Comment @coderabbitai help to get the list of available commands and usage tips.

rudiheydra added a commit to rudiheydra/AutoBuildr that referenced this pull request Feb 2, 2026
…toForgeAI#139)

Align the final_verdict enum values with the app spec (passed|failed|error).
The implementation previously used 'partial' instead of 'error'.

Changes:
- api/agentspec_models.py: VERDICT constant and column comment
- server/schemas/agentspec.py: VERDICTS Literal type and validator
- api/validators.py: Verdict determination logic in AcceptanceGate
- api/harness_kernel.py: Verdict logic in _run_acceptance_validators and _run_partial_acceptance_validators
- api/agentspec_crud.py, api/migration_flag.py, api/event_recorder.py: Docstring updates
- ui/src/lib/types.ts: AgentRunVerdict TypeScript type
- Updated all test assertions from 'partial' to 'error'
- All 3488 existing tests continue to pass (no regressions)

Co-Authored-By: Claude Opus 4.5 <noreply@anthropic.com>
rudiheydra added a commit to rudiheydra/AutoBuildr that referenced this pull request Feb 2, 2026
Co-Authored-By: Claude Opus 4.5 <noreply@anthropic.com>
Sign up for free to join this conversation on GitHub. Already have an account? Sign in to comment

Labels

None yet

Projects

None yet

Development

Successfully merging this pull request may close these issues.

Encoding issue with CP1252 / UTF-8

1 participant