hermes - ✅(Solved) Fix [Bug]: Windows local terminal commands can complete without returning any output [1 pull requests, 1 participants]

Official PRs (…)
ON THIS PAGE

Recommended Tools

×6

Utilities matched from this issue’s tags and category — try them while you read without losing context.

GitHub issue graph ai analysis

Paste a GitHub issue URL. We fetch that issue, discover linked issues from bodies/comments/timeline, collect linked pull requests, and produce a structured English report.

The report is written in English Markdown for sharing and archival.

Helpful · Quick feedback

Loading…
GitHub stats
NousResearch/hermes-agent#16425Fetched 2026-04-28 06:53:25
View on GitHub
Comments
0
Participants
1
Timeline
7
Reactions
0
Author
Participants
Timeline (top)
labeled ×5cross-referenced ×2

On Windows, Hermes local terminal commands can execute successfully but fail to return their output back to the agent/CLI. From the user side this looks like:

  • the command appears to hang
  • or the command completes with an empty reply
  • or no terminal output is surfaced even though the subprocess ran

Error Message

Operating System

Windows 11

Python Version

3.12.0

Hermes Version

Hermes Agent v0.11.0 (2026.4.23)

Additional Logs / Traceback (optional)

Root Cause

Root Cause Analysis (optional)

Fix Action

Fixed

PR fix notes

PR #16418: Fix Windows terminal execution so foreground commands reliably return…

Description (problem / solution / changelog)

What does this PR do?

This PR fixes Windows local terminal execution so foreground commands reliably return output instead of appearing to hang or complete with an empty reply.

The fix addresses two Windows-specific issues in the local terminal stack:

  1. BaseEnvironment._wait_for_process() used Unix-style select.select() to poll subprocess stdout pipes. That works on Unix, but not reliably for ordinary subprocess pipes on Windows, which could prevent command output from being drained and surfaced back to Hermes.

  2. LocalEnvironment had path mismatches between native Windows paths and Git Bash/MSYS paths. This affected:

    • bash executable selection
    • cwd
    • sourced shell init files
    • session artifact paths such as snapshot/cwd temp files

This approach fixes the bug at the correct layers:

  • base.py now uses a Windows-compatible stdout polling path
  • local.py now bridges Windows and Git Bash paths consistently while still using native Windows paths where subprocess.Popen() requires them

Related Issue

Fixes #

Type of Change

  • 🐛 Bug fix (non-breaking change that fixes an issue)
  • ✨ New feature (non-breaking change that adds functionality)
  • 🔒 Security fix
  • 📝 Documentation update
  • ✅ Tests (adding or improving test coverage)
  • ♻️ Refactor (no behavior change)
  • 🎯 New skill (bundled or hub)

Changes Made

  • Updated tools/environments/base.py
    • added a Windows-specific stdout pipe polling path using PeekNamedPipe
    • preserved the existing Unix select() polling behavior
    • routed _wait_for_process() through the shared pipe polling helper
  • Updated tools/environments/local.py
    • improved Windows bash discovery
    • skipped C:\Windows\System32\bash.exe / sysnative\bash.exe WSL stub
    • preferred real Git for Windows bash.exe
    • searched both bin\bash.exe and usr\bin\bash.exe
    • added Windows <-> Git Bash/MSYS path conversion helpers
    • converted shell init file paths into bash-visible form before sourcing
    • used native Windows paths for subprocess.Popen(..., cwd=...)
    • rewrote local snapshot/cwd artifact paths into bash-visible paths in wrapped commands
    • converted bash-reported cwd values back into native Windows paths before storing state
  • Added tests
    • tests/tools/test_base_environment_pipe_poll.py
    • tests/tools/test_local_windows_paths.py

How to Test

  1. On Windows, run a foreground local terminal command through Hermes that previously returned no visible reply.
  2. Confirm the command output is returned normally instead of appearing to hang or complete with an empty response.
  3. Run:
    • python -m pytest tests/tools/test_base_environment_pipe_poll.py tests/tools/test_local_windows_paths.py -q and confirm the targeted regression tests pass.

Checklist

Code

  • I've read the Contributing Guide
  • My commit messages follow Conventional Commits (fix(scope):, feat(scope):, etc.)
  • I searched for existing PRs to make sure this isn't a duplicate
  • My PR contains only changes related to this fix/feature (no unrelated commits)
  • I've run pytest tests/ -q and all tests pass
  • I've added tests for my changes (required for bug fixes, strongly encouraged for features)
  • I've tested on my platform: Windows 11

Documentation & Housekeeping

  • I've updated relevant documentation (README, docs/, docstrings) — or N/A
  • I've updated cli-config.yaml.example if I added/changed config keys — or N/A
  • I've updated CONTRIBUTING.md or AGENTS.md if I changed architecture or workflows — or N/A
  • I've considered cross-platform impact (Windows, macOS) per the compatibility guide — or N/A
  • I've updated tool descriptions/schemas if I changed tool behavior — or N/A

Screenshots / Logs

Targeted verification run:

python -m pytest tests/tools/test_base_environment_pipe_poll.py tests/tools/test_local_windows_paths.py -q

Result:

8 passed

Note: I was not able to run the full repo-standard scripts/run_tests.sh / pytest tests/ -q flow in this Windows environment because the local bash/script setup has an independent environment issue. The targeted regression tests for this fix are passing.

#16425

Changed files

  • scripts/release.py (modified, +1/-0)
  • tests/tools/test_base_environment_pipe_poll.py (added, +47/-0)
  • tests/tools/test_local_windows_paths.py (added, +84/-0)
  • tools/environments/base.py (modified, +66/-11)
  • tools/environments/local.py (modified, +125/-7)
  • uv.lock (modified, +161/-2)

Code Example

echo hello

<img width="1375" height="444" alt="Image" src="https://github.com/user-attachments/assets/9640912a-f8fa-4336-80e6-515a89b081fe" />

### Steps to Reproduce

1. Run Hermes on Windows system (without WSL, without Docker)
2. Send, execute echo test
3. Output freezes

### Expected Behavior

should complete command execution normally

### Actual Behavior

Command cannot be executed

### Affected Component

Tools (terminal, file ops, web, code execution, etc.)

### Messaging Platform (if gateway-related)

N/A (CLI only)

### Debug Report

---

### Operating System

Windows 11

### Python Version

3.12.0

### Hermes Version

Hermes Agent v0.11.0 (2026.4.23)

### Additional Logs / Traceback (optional)
RAW_BUFFERClick to expand / collapse

Bug Description

Summary

On Windows, Hermes local terminal commands can execute successfully but fail to return their output back to the agent/CLI. From the user side this looks like:

  • the command appears to hang
  • or the command completes with an empty reply
  • or no terminal output is surfaced even though the subprocess ran

Environment

  • OS: Windows 11
  • Backend: local terminal / Git Bash
  • Hermes version: current main / recent checkout
  • Shell context: Windows host + Git Bash local execution path

What happens

Foreground terminal commands on Windows do not reliably surface stdout back to Hermes.

This makes normal local commands feel broken even when the command itself runs correctly.

Expected behavior

Foreground local terminal commands should return their stdout/stderr normally, just like on Linux/macOS.

Actual behavior

The command may run, but Hermes receives no visible output, or behaves as if the command is hanging until timeout / completion.

Steps to reproduce

  1. Run Hermes on Windows with the local terminal backend.
  2. Execute a simple foreground command such as:
    echo hello
<img width="1375" height="444" alt="Image" src="https://github.com/user-attachments/assets/9640912a-f8fa-4336-80e6-515a89b081fe" />

Steps to Reproduce

  1. Run Hermes on Windows system (without WSL, without Docker)
  2. Send, execute echo test
  3. Output freezes

Expected Behavior

should complete command execution normally

Actual Behavior

Command cannot be executed

Affected Component

Tools (terminal, file ops, web, code execution, etc.)

Messaging Platform (if gateway-related)

N/A (CLI only)

Debug Report

Debug report uploaded:
  Report       https://paste.rs/nxNJS
  agent.log    https://paste.rs/xK8f8
  gateway.log  https://paste.rs/B6L4m

Operating System

Windows 11

Python Version

3.12.0

Hermes Version

Hermes Agent v0.11.0 (2026.4.23)

Additional Logs / Traceback (optional)

Root Cause Analysis (optional)

No response

Proposed Fix (optional)

No response

Are you willing to submit a PR for this?

  • I'd like to fix this myself and submit a PR

extent analysis

TL;DR

The issue can be mitigated by investigating the stdout handling in the Windows local terminal backend of Hermes.

Guidance

  • Review the agent.log and gateway.log files from the debug report to identify any errors or warnings related to stdout handling.
  • Verify that the echo command is executed correctly in the Git Bash terminal outside of Hermes to rule out any shell-specific issues.
  • Investigate the differences in stdout handling between Windows and Linux/macOS in the Hermes codebase to identify potential platform-specific bugs.
  • Consider adding additional logging or debugging statements to the Hermes code to better understand the stdout handling flow on Windows.

Example

No code snippet is provided as the issue requires further investigation into the Hermes codebase and logging.

Notes

The root cause of the issue is unclear and requires further analysis of the Hermes code and logs. The provided information suggests a platform-specific issue with stdout handling on Windows.

Recommendation

Apply workaround: Investigate and fix the stdout handling in the Windows local terminal backend of Hermes, as the current implementation seems to be causing issues with command output.

Vote matrix · Quick signals

Works
Did the solution work? Tap to confirm.
Easy Fix
Was it a quick fix?
Time Saver
Did it save you time?
Blocking
Was it severely blocking?
Common Issue
Are others likely hitting this too?
Flaky / Intermittent
Is it intermittent?
Verified / Reproducible
Can you reproduce it reliably?
Loading…

FAQ

Expected behavior

Foreground local terminal commands should return their stdout/stderr normally, just like on Linux/macOS.

Still need to ship something?

×6

Another batch ranked right after the header list — different links, same matching logic.

Back to top recommendations

TRENDING