Fix Hermes install hint on Windows#6903
Conversation
![gemini-code-assist[bot]](https://avatars.githubusercontent.com/in/956858?s=60&v=4){kind=small}
There was a problem hiding this comment.
Code Review
This pull request introduces Windows-specific installation hints and support for the Hermes agent. It defines a PowerShell-based installation command for Windows alongside the existing Bash-based command for POSIX systems, dynamically selecting the appropriate command based on the operating system. Additionally, unit tests have been added to verify the correct installation behavior and command selection on both Windows and POSIX platforms. There are no review comments, so I have no feedback to provide.
Important
The consumer version of Gemini Code Assist on GitHub is being sunset. Starting June 18, 2026, new organization installations will be blocked, and all code review activity will officially cease on July 17, 2026.
For more details on the timeline and next steps, please review the Help Documentation.
|
@codex review |
![chatgpt-codex-connector[bot]](https://avatars.githubusercontent.com/in/1144995?s=60&v=4){kind=small}
There was a problem hiding this comment.
💡 Codex Review
Here are some automated review suggestions for this pull request.
Reviewed commit: a23150c73b
ℹ️ About Codex in GitHub
Your team has set up Codex to review pull requests in this repo. Reviews are triggered when you
- Open a pull request for review
- Mark a draft as ready
- Comment "@codex review".
If Codex has suggestions, it will comment; otherwise it will react with 👍.
Codex can also answer questions or update the PR. Try commenting "@codex address that feedback".
| _CODEX_ENV_KEY = "UNSLOTH_STUDIO_AUTH_TOKEN" | ||
| _HERMES_ENV_KEY = "UNSLOTH_API_KEY" | ||
| _HERMES_PROVIDER = "unsloth" | ||
| _HERMES_WINDOWS_INSTALL_HINT = "iex (irm https://hermes-agent.nousresearch.com/install.ps1)" |
There was a problem hiding this comment.
On a native Windows first run where hermes is absent and the user accepts the install prompt, this installer only adds the Hermes directory to the User PATH for future shells; the Hermes Windows docs explicitly tell users to open a new terminal after it finishes. _install_agent then immediately calls shutil.which("hermes") in the current process, so the install succeeds but the same unsloth start hermes invocation falls into the “installed but isn't on PATH yet” failure instead of launching. Please refresh/augment the current PATH or resolve the known installed executable before re-checking.
Useful? React with 👍 / 👎.
There was a problem hiding this comment.
Confirmed the installer only persists PATH for future shells (it prints "restart your terminal"), so the same-process shutil.which can miss a just-installed agent. _install_agent already handles this by failing with an accurate "installed but isn't on PATH yet, open a new shell and re-run" message that mirrors the installer's own guidance, so the flow is correct as a two-step. An in-process PATH refresh (registry on Windows, shell config on POSIX) is a reasonable enhancement but is broader than this Hermes-hint change and touches the shared install path for every agent, so leaving it as a follow-up.
There was a problem hiding this comment.
Update: implemented this. _install_agent now calls _refresh_windows_path() before the post-install shutil.which, merging the User/Machine PATH hives from the registry into the process so a just-installed agent resolves in the same invocation. Windows-only (no-op on POSIX and on any read error), augment-only, and covered by tests.
| _CODEX_ENV_KEY = "UNSLOTH_STUDIO_AUTH_TOKEN" | ||
| _HERMES_ENV_KEY = "UNSLOTH_API_KEY" | ||
| _HERMES_PROVIDER = "unsloth" | ||
| _HERMES_WINDOWS_INSTALL_HINT = "iex (irm https://hermes-agent.nousresearch.com/install.ps1)" |
There was a problem hiding this comment.
On a native Windows machine without hermes, accepting this prompt runs Hermes' normal installer in an interactive shell, and that installer starts hermes setup unless -SkipSetup/noninteractive mode is used (the Windows docs describe the setup wizard and show -SkipSetup as an option). In the unsloth start hermes path this is the wrong UX because Unsloth writes a session-scoped HERMES_HOME config after installation; the user can get blocked configuring Hermes' real %LOCALAPPDATA%\hermes provider before Unsloth ever launches. Use the scriptblock form with -SkipSetup (or another noninteractive installer mode) for this auto-install hint.
Useful? React with 👍 / 👎.
There was a problem hiding this comment.
Fixed. Both install hints now pass the installer's skip flag so the interactive setup wizard does not run during the unattended unsloth start hermes install and block the launch: the PowerShell scriptblock form with -SkipSetup, and bash -s -- --skip-setup for the piped POSIX installer. Confirmed against both installers (Invoke-SetupWizard gated on -SkipSetup; the shell script gates the wizard on --skip-setup).
unsloth start hermes auto-installs Hermes and then writes its own session-scoped Hermes config. The install commands, as written, drop into the installer's interactive setup wizard (hermes setup), which prompts for global API keys and model choice and points the user at a different global provider than the one Unsloth just configured, blocking the launch. Pass the installer's skip flag on both platforms: the PowerShell scriptblock form with -SkipSetup, and bash -s -- --skip-setup for the piped POSIX installer.
A Windows installer persists the agent's directory to the User/Machine PATH in the registry and updates only its own process, so the current process keeps a stale PATH until it restarts (the installers print 'restart your terminal'). The post-install shutil.which then misses the just-installed agent and unsloth start fails with 'installed but isn't on PATH yet', forcing a re-run in a new shell. Merge the registry PATH hives back into the process before re-resolving so a freshly installed agent launches in the same invocation. No-op off Windows and on any read error; only ever augments PATH.
|
@codex review |
|
Codex Review: Didn't find any major issues. Swish! Reviewed commit: ℹ️ About Codex in GitHubYour team has set up Codex to review pull requests in this repo. Reviews are triggered when you
If Codex has suggestions, it will comment; otherwise it will react with 👍. Codex can also answer questions or update the PR. Try commenting "@codex address that feedback". |
|
@codex review |
|
Codex Review: Didn't find any major issues. Keep it up! Reviewed commit: ℹ️ About Codex in GitHubYour team has set up Codex to review pull requests in this repo. Reviews are triggered when you
If Codex has suggestions, it will comment; otherwise it will react with 👍. Codex can also answer questions or update the PR. Try commenting "@codex address that feedback". |
|
@codex review |
There was a problem hiding this comment.
💡 Codex Review
Here are some automated review suggestions for this pull request.
Reviewed commit: baacbd025d
ℹ️ About Codex in GitHub
Your team has set up Codex to review pull requests in this repo. Reviews are triggered when you
- Open a pull request for review
- Mark a draft as ready
- Comment "@codex review".
If Codex has suggestions, it will comment; otherwise it will react with 👍.
Codex can also answer questions or update the PR. Try commenting "@codex address that feedback".
| for root, sub in hives: | ||
| try: | ||
| with winreg.OpenKey(root, sub) as key: | ||
| value, _ = winreg.QueryValueEx(key, "Path") |
There was a problem hiding this comment.
On fresh native Windows machines where install.ps1 has to provision or discover Git Bash, the installer persists HERMES_GIT_BASH_PATH as a User env var in addition to Path. This refresh only imports the Path registry value, so _launch copies a stale os.environ into the first Hermes process: shutil.which can find hermes, but Hermes itself may not see the bash path until the user opens a new shell, breaking terminal/bash tools in the just-installed session. Please refresh or pass the Hermes env vars written by the installer too.
Useful? React with 👍 / 👎.
There was a problem hiding this comment.
Valid: _refresh_windows_path only re-imports the Path hive value, so a var the installer persists alongside it (HERMES_GIT_BASH_PATH) stays stale in the launched process until a new shell. Suggested approach: after the PATH merge, also re-read the User Environment hive (HKCU\Environment) for the installer-written vars and set any that are missing from os.environ, without overwriting values already set in the current process (so we only fill in what the just-run installer added, and never clobber an intentional override). Keeping it to newly-absent names avoids picking up unrelated stale registry values. This is Windows-only and augment-only like the PATH merge; I can't exercise it here without a Windows host, so flagging for you since you own this path handling.
3 participants
Summary
Root Cause
unsloth start hermes always offered the Bash installer command. On Windows PowerShell, curl resolves to Invoke-WebRequest, so curl -fsSL fails before Hermes can install.
Validation