Skip to content

fix(desktop): resolve agent CLIs via Windows registry PATH when process env is stale - #4464

Open
andrexibiza wants to merge 1 commit into
block:mainfrom
andrexibiza:fix/windows-registry-path-fallback
Open

fix(desktop): resolve agent CLIs via Windows registry PATH when process env is stale#4464
andrexibiza wants to merge 1 commit into
block:mainfrom
andrexibiza:fix/windows-registry-path-fallback

Conversation

@andrexibiza

Copy link
Copy Markdown

What

The managed-agent resolver (resolve_command_uncached) probes for CLI binaries only against the inherited process PATH. On Windows, apps relaunched by an updater, service, or long-lived parent keep the environment they were launched with, so PATH entries written to the registry later stay invisible and installed runtimes report NotInstalled — even though a freshly spawned process resolves them fine.

Concrete case: Hermes Agent on Windows. Its hermes-acp launcher lives in the install's venv Scripts dir. After Buzz 0.5.3 auto-updated and relaunched, the new process's environment no longer carried that PATH entry (the registry Environment\Path still had it), so the Hermes preset flipped from Ready to NotInstalled overnight with no change to the Hermes install itself.

Fix

When the process-PATH scan misses, fall back to the machine and per-user registry Environment\Path values — the authoritative post-login PATH:

  • Read HKLM\SYSTEM\CurrentControlSet\Control\Session Manager\Environment then HKCU\Environment (matches the effective merge order).
  • Expand %VAR% references (registry values are REG_EXPAND_SZ) via ExpandEnvironmentStringsW.
  • Scan those dirs for the target basenames (including .cmd/.bat shims).

New module discovery/registry_path.rs mirrors the existing git_bash_from_registry pattern. discovery.rs stays under its file-size ratchet (it actually shrinks: the .cmd/.bat shim scan moved into the module).

Verification

  • cargo check --lib clean (only pre-existing warnings).
  • cargo test --lib managed_agents::discovery: 86 passed, 0 failed — including a new test resolve_in_dirs_finds_binary_from_registry_style_dir_list that resolves a binary present only in a registry-style dir list.
  • cargo fmt --check and the desktop file-size ratchet both pass.
  • Reproduced end-to-end on a real Windows install: the stale process env reported NotInstalled; relaunching with the registry PATH present makes the harness Ready.

Related

Complementary to #3334 (which switches the Hermes preset to hermes acp for the macOS/Linux login-shell case). This change fixes the Windows updater-relaunch case regardless of which command name the preset uses.

…ss env is stale

The managed-agent resolver probes for CLI binaries only against the
inherited process PATH. On Windows, apps relaunched by an updater,
service, or long-lived parent keep the environment they were launched
with, so PATH entries written to the registry later are invisible and
installed runtimes report as NotInstalled even though a freshly spawned
process resolves them.

Hermes Agent is the concrete case: its hermes-acp launcher lives in the
install's venv Scripts dir, which the 0.5.3 auto-updater relaunch no
longer carried. The registry Environment\Path (HKLM + HKCU) still has
the entry.

Fall back to the machine and per-user registry Path values when the
process PATH scan misses: read both hives, expand %VAR% references, and
scan those dirs for the target basenames. Mirrors the existing
git_bash_from_registry pattern. discovery.rs stays under its file-size
ratchet by moving the shim scan into the new registry_path module.

Signed-off-by: andrexibiza <84248988+andrexibiza@users.noreply.github.com>
@andrexibiza
andrexibiza requested a review from a team as a code owner August 3, 2026 03:15
@chatgpt-codex-connector

Copy link
Copy Markdown

You have reached your Codex usage limits for code reviews. You can see your limits in the Codex usage dashboard.

Sign up for free to join this conversation on GitHub. Already have an account? Sign in to comment

Labels

None yet

Projects

None yet

Development

Successfully merging this pull request may close these issues.

1 participant