hermes - 💡(How to fix) Fix [Feature]: WSL ↔ Windows Host Command Bridge — invoke Windows-native executables from Hermes

Problem or Use Case

I run Hermes Agent inside WSL (Windows Subsystem for Linux). The terminal tool is restricted to WSL's Linux shell, but many essential workflows require invoking Windows-native executables that have no Linux equivalent.

Concrete use case that triggered this request:

I'm building an automated diskless system imaging pipeline (PXE boot + sysprep + MBR conversion). The entire workflow is scriptable — except for one step: mbr_read.exe, a Windows GUI tool that performs MBR read/write operations. There is no Linux equivalent. To complete my automation, I currently have to manually step out of Hermes, RDP into the Windows host, and run the tool by hand. This breaks the otherwise fully automated flow.

More broadly, any workflow involving:

• Windows system administration (DISM, dism++, sysprep, imagex)
• PXE / network boot tooling that only ships as Windows binaries
• Hardware interaction (BIOS flashing tools, disk sector editors like mbr_read.exe)
• Windows Performance Toolkit (xperf, WPR, WPA)
• Legacy enterprise tooling with no Linux port

…is currently impossible to automate through Hermes when running in WSL.

Proposed Solution

Add a new tool (or extend the existing terminal tool) that allows Hermes to execute commands on the Windows host from inside WSL. Several implementation approaches exist:

1. WSL interop passthrough: Windows executables are already accessible from inside WSL via /mnt/c/Windows/System32/ — but only interactive binaries (like notepad.exe) work well. CLI tools like cmd.exe /c and powershell.exe -Command work but capture stdout/stderr unreliably through the WSL interop layer. A dedicated Hermes tool that wraps this properly (handles stdio, exit codes, timeouts, env vars) would solve most use cases.

2. PowerShell Remoting bridge: Run powershell.exe -Command {script} on the Windows host via WinRM, with proper stdout/stderr/exit code plumbing back into Hermes.

3. Named pipe / TCP socket daemon: A lightweight Windows-side daemon (e.g., a small Go or .NET app) that listens on a configurable port and executes commands on behalf of Hermes, returning structured JSON results. This is the most reliable approach but requires an install step.

Ideal behavior:

• A config option host.command_bridge with modes: wsl-interop, winrm, or daemon:tcp://host:port
• The tool behaves like terminal but targets the Windows host: host_terminal(command: "...", timeout: 120)
• Supports stdout/stderr capture, exit code, working directory, and env vars
• Timeout and process lifecycle management identical to the existing terminal tool

Alternatives Considered

• SSH into Windows: Requires enabling OpenSSH Server on Windows, configuring auth, and keeping it running. Overkill for localhost WSL→Windows communication.
• WSH (Windows Script Host) / JScript workarounds: Fragile, limited stdout capture, no binary/PE support.
• Scheduled tasks: Trigger Windows tasks from WSL via schtasks.exe /RUN. Works but is async-only, no stdout capture.
• Manual RDP / VNC: Current workaround — breaks automation entirely.

All alternatives are workarounds. A dedicated bridge is the clean solution.

Feature Type

• New tool

Scope

• Medium (few files, < 300 lines)