fix(installer): support native Windows PowerShell install and CMD

[adybag14-cyber]

What does this PR do?

This PR fixes native Windows installation so Hermes can be installed directly from stock PowerShell without requiring WSL.

The main issue was that the PowerShell installer used Unicode/banner characters that parsed inconsistently in native Windows PowerShell environments. This change makes the installer output Windows-PowerShell-safe while preserving installer behavior, and updates the README so Windows users are directed to the supported native PowerShell install path instead of being told to use WSL.

Why this approach:

• keeps the change tightly scoped to native Windows installer support
• avoids unrelated feature work
• preserves the existing installer flow while making it parse and run reliably on native Windows PowerShell

Related Issue

No tracked GitHub issue found for this specific native Windows installer parsing/support gap.

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 scripts/install.ps1 to use PowerShell-safe ASCII banner/status output instead of Unicode characters that were causing native Windows PowerShell issues
• updated README.md to document native Windows PowerShell installation and remove the old WSL-only guidance

How to Test

1. On Windows, run the PowerShell installer path:
   • irm https://raw.githubusercontent.com/NousResearch/hermes-agent/main/scripts/install.ps1 | iex
2. Confirm the install completes in native PowerShell without requiring WSL.
3. Verify that hermes.exe exists under the installed venv\Scripts directory.
4. Run hermes --help from the installed path and confirm it starts successfully.

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

Native Windows validation performed on this branch:

• stock PowerShell parse check for scripts/install.ps1
• clean install into %LOCALAPPDATA%
• verified venv\Scripts\hermes.exe exists
• verified hermes --help runs successfully with no WSL involved

[adybag14-cyber]

let me fix this

[adybag14-cyber]

@chan-yuu @datalee @pangxianggang okay have a look

[adybag14-cyber]

#8806 review this pull request here its fixed

[adybag14-cyber]

#9196

[adybag14-cyber]

#8821 #7689 #7298 I have added cmd , powershell 5.1 and 7.5 all fully compatible now with hermes straight up no other issues.
output.webm

[adybag14-cyber]

@alt-glitch i have both cmd and powershell compatibility thus superseeding all other pr's for windows native

[adybag14-cyber]

@chan-yuu have a look

[adybag14-cyber]

@pangxianggang also have a look

[wx528]

Hi @adybag14-cyber
Thanks for the great installer work! My PR #19800 focuses on the runtime terminal environment (command execution, path handling, env snapshot) rather than the install path. These two PRs are complementary — installer gets users set up, environment makes the agent actually run tools on Windows. Would love to coordinate so we don't conflict.

[teknium1]

Thanks for this — appreciate the work. We're closing the entire cluster of open native-Windows PRs (44 of them spanning installer, terminal routing, file ops, gateway PID handling, encoding, docs, and more) because the surface area needs a designed, consolidated approach rather than piecemeal merges. Cherry-picking individual fixes keeps leaving inconsistencies and we'd rather land Windows support properly, in one coherent pass.\n\nYour PR is catalogued in our internal Windows support plan. When we pick this back up (soon), we'll mine every PR in the cluster for its fix shape and credit all contributors whose work informs the final patch via lines. Watch for the consolidating PR and feel free to chime in with context on the specific failure mode you were hitting.\n\nClosing for now, not as a rejection of the fix — just queueing it for the designed rollout. Thanks again.