Skip to content

fix(install): resolve PowerShell host instead of bare powershell for uv install#48341

Merged
kshitijk4poor merged 2 commits into
NousResearch:mainfrom
xxxigm:fix/install-ps1-powershell-host-resolution
Jun 18, 2026
Merged

fix(install): resolve PowerShell host instead of bare powershell for uv install#48341
kshitijk4poor merged 2 commits into
NousResearch:mainfrom
xxxigm:fix/install-ps1-powershell-host-resolution

Conversation

@xxxigm

@xxxigm xxxigm commented Jun 18, 2026

Copy link
Copy Markdown
Contributor

Summary

A Windows user reported the installer getting stuck; running
irm https://hermes-agent.nousresearch.com/install.ps1 | iex failed at the uv
step with:

[X] Failed to install uv: The term 'powershell' is not recognized as the name
    of a cmdlet, function, script file, or operable program.
[X] Installation failed: uv installation failed

Root cause. Install-Uv spawned the astral uv installer with a hardcoded
bare powershell:

powershell -ExecutionPolicy ByPass -c "irm https://astral.sh/uv/install.ps1 | iex"

The bare name powershell resolves only to Windows PowerShell, and only
when its System32\WindowsPowerShell\v1.0 directory is on PATH. When
install.ps1 is run under PowerShell 7+ (pwsh) — or any session where
powershell isn't on PATH — the spawn dies with "The term 'powershell' is
not recognized"
, so uv never installs and the installer appears stuck. The
script already documents that it can be invoked from "any x64 PowerShell host"
(see the Get-WindowsArch note), so assuming powershell is on PATH is the
inconsistency.

Fix

Add Get-PowerShellHostExe, which resolves the host executable in priority
order:

  1. the absolute path of the host we're already running in
    ((Get-Process -Id $PID).Path) — PATH-independent, and matches the
    host the user actually launched (powershell.exe or pwsh.exe);
  2. fall back to powershell / pwsh via Get-Command;
  3. last-ditch bare powershell so the spawn surfaces its own error.

Install-Uv now invokes the resolved exe (& $psHostExe -ExecutionPolicy ByPass -c "irm https://astral.sh/uv/install.ps1 | iex"). The host filter only
trusts a current host whose leaf name is powershell.exe/pwsh.exe, so
powershell_ise.exe and other embedded hosts (which can't take
-ExecutionPolicy/-Command) fall through to Get-Command.

This is the only external powershell spawn in the script; the cross-process
stage driver lives in Hermes-Setup.exe, not here.

Test plan

  • tests/test_install_ps1_uv_powershell_host.py (new) — source-level guards
    (the script only runs on Windows, so there's no Linux CI runner to execute
    it): the bare-powershell astral literal is gone, the installer is invoked
    via & $-resolved host variable, and the resolver is PATH-independent
    (Get-Process -Id $PID) and pwsh-aware.
  • scripts/run_tests.sh tests/test_install_ps1_uv_powershell_host.py — 3 passed.

xxxigm added 2 commits June 18, 2026 16:26
…r uv

The Windows installer's Install-Uv spawned the astral uv installer with a
hardcoded bare `powershell -ExecutionPolicy ByPass -c "irm .../uv | iex"`.
That name resolves only to Windows PowerShell, and only when its System32
directory is on PATH. Run under PowerShell 7+ (`pwsh`) — or any session where
`powershell` isn't on PATH — the spawn dies with "The term 'powershell' is not
recognized", and uv installation aborts (the installer then appears stuck).

Add Get-PowerShellHostExe, which prefers the absolute path of the host we're
already running in (PATH-independent), then falls back to powershell/pwsh via
Get-Command, then to the bare name. Install-Uv now invokes that resolved exe.
Source-level guard (install.ps1 only runs on Windows, so there's no Linux CI
runner to execute it): the astral uv install line must be invoked via the call
operator on a resolved host variable, the bare-`powershell` literal that
produced the field-reported "The term 'powershell' is not recognized" must be
gone, and the resolver must be PATH-independent (Get-Process -Id $PID) and
pwsh-aware.
@alt-glitch alt-glitch added type/bug Something isn't working comp/cli CLI entry point, hermes_cli/, setup wizard P2 Medium — degraded but workaround exists labels Jun 18, 2026
@kshitijk4poor kshitijk4poor merged commit b39ec2f into NousResearch:main Jun 18, 2026
35 checks passed
Sign up for free to join this conversation on GitHub. Already have an account? Sign in to comment

Labels

comp/cli CLI entry point, hermes_cli/, setup wizard P2 Medium — degraded but workaround exists type/bug Something isn't working

Projects

None yet

Development

Successfully merging this pull request may close these issues.

3 participants