[Bug]: terminal and write_file tools fail inside agent on Windows 11 (ATLAS OS) (exit 126 / empty file)

[mallo555]

Bug Description

Two agent tools fail consistently when invoked by the model during a chat session:

1. terminal — every command returns exit code 126 with empty stdout/stderr. Tested: echo, pwd, ls, whoami, mkdir, python --version. All fail identically.

2. write_file — returns {"error": "Failed to write file:"} or produces a 0-byte file.

The system shell itself works fine — hermes CLI runs in PowerShell, hermes debug share succeeds, PowerShell commands execute normally. The failure is specific to how the agent invokes these tools internally.

Browser tools, memory, read_file, skills, and Discord integration all work normally in the same session.

Steps to Reproduce

1. on a new windows 11 pro installation download and run atlas os
2. Run hermes chat (Ollama provider, model qwen3.5:9b)
3. Ask the agent: "run echo hello"
   → terminal tool returns exit 126, no output
4. Ask the agent to create a file via write_file
   → returns "Failed to write file:" or creates a 0-byte file
5. Same session, ask agent to navigate a URL or read a file
   → works normally

Expected Behavior

• terminal tool should execute commands and return their output
• write_file should write content to disk and return success

Actual Behavior

• terminal: exit code 126, empty output, every command, every session
• write_file: error "Failed to write file:" or 0-byte file created at the target path

Affected Component

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

Messaging Platform (if gateway-related)

No response

Debug Report

Report       https://paste.rs/EMiNP
agent.log    https://paste.rs/sdHTM
gateway.log  https://paste.rs/xWDcK

Operating System

Windows 11 Pro 10.0.26100 (Atlas OS variant)

Python Version

3.12.10

Hermes Version

0.12.0 (2026.4.30)

Additional Logs / Traceback (optional)

Possibly related — `~/.hermes/cache/checkpoints/` grew to ~240 GB on this machine over a few 2 days of normal use, with no apparent size cap or cleanup. Manually deleting it freed the space with no observable downside, but unbounded growth seems unintended. Happy to file separately if preferred.

Provider: Ollama 0.23.1, model qwen3.5:9b, OpenAI SDK 2.33.0.

Root Cause Analysis (optional)

No root cause identified yet. The system shell works fine (hermes debug share ran successfully from PowerShell), so the failure is specific to how Hermes invokes the terminal and write_file tools internally on Windows 11 (atlas os). Exact cause unknown.

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

[alt-glitch]

Duplicate of #18454 (Windows terminal exit 126 — WSL bash stub root cause). See also #14638 for comprehensive report with fix PRs #14644, #13397.

[mallo555]

@alt-glitch

the default config had shell: wsl.exe under the terminal section. Atlas OS disables Hyper-V which WSL2 requires, so every terminal call hung then timed out with exit 126.

Partial fix: changing shell: wsl.exe to shell: 'C:\Program Files\Git\bin\bash.exe' in config.yaml gets further — the 47-second WSL hang is gone and the error changes from exit 126 to "stdin is not a tty", which suggests bash is now being reached but launched without a pseudo-terminal.

For other Atlas OS users: the WSL default is the primary blocker. The TTY issue may be the secondary bug described in #14644 (the pty=True / pywinpty path). Will update if I find a further fix.

[teknium1]

Automated hermes-sweeper review: this Windows terminal/write_file failure appears fixed on current main.

Evidence:

• The issue discussion identified this as the Windows terminal exit-126 cluster tracked through [Bug]: Windows: terminal always returns exit_code 126 (root cause + fix) #18454 / Windows: Terminal exits 126 with empty output on every command (Git Bash backend) #14638, with the reporter confirming the primary blocker was shell: wsl.exe on an Atlas OS machine without WSL2.
• c2d6b385f19d812ca9e98d4746234fcb94beb11f fixes the Windows terminal empty-output / exit-126 path by avoiding select.select() on Windows pipe fds and converting Git Bash cwd paths before Popen; the commit explicitly says it fixes Windows: Terminal exits 126 with empty output on every command (Git Bash backend) #14638.
• Current main no longer routes Windows local terminal execution through a config-level shell: wsl.exe; tools/environments/local.py discovers HERMES_GIT_BASH_PATH, Hermes-managed PortableGit, then system Git Bash paths.
• The write_file zero-byte dropped-argument case is also fixed on main: tools/file_tools.py now rejects missing content instead of silently writing an empty string.

Closing as implemented on main. Thanks for the detailed Atlas OS reproduction and follow-up root-cause notes.