False-positive 'Unsupported install method' banner for install.ps1/uv-based installs

[nachopenclaw-svg]

Bug Description

Hermes Desktop shows the warning banner "Unsupported install method: pip installs are no longer an officially supported platform and will not receive further updates" even when the installation was performed entirely through the official, Tier-1-supported install.ps1 bootstrap flow (not a raw pip install hermes-agent).

Root Cause (suspected)

The bootstrap installer uses uv to create the venv and install dependencies (uv.lock-based, hash-verified). uv implements pip-compatible install metadata under the hood. It appears the platform-support detection logic that decides whether to show this banner reads that pip-style package metadata and concludes the install method is "pip", rather than checking how the installer/bootstrap was actually invoked.

Steps to Reproduce

1. Install Hermes on Windows via the official install.ps1 (Tier 1 supported method, as documented at https://hermes-agent.nousresearch.com/docs/getting-started/platform-support).
2. Let the installer create the venv via uv and install dependencies from uv.lock.
3. Update Hermes normally over time via the built-in updater (also uv-based).
4. Open Hermes Desktop — the "Unsupported install method" banner appears, incorrectly flagging the install as an unsupported pip install.

Evidence

• ~/AppData/Local/hermes/logs/bootstrap-installer.log shows the original install (2026-06-05) went through the full install.ps1 bootstrap manifest (uv, python, git, node, system-packages, repository, venv, dependencies, node-deps, desktop, path, config-templates, platform-sdks, bootstrap-marker, configure, gateway stages), and every subsequent update since has gone through the same bootstrap's update stage — never a bare pip install hermes-agent.
• However, ~/AppData/Local/hermes/.install_method contains the literal string pip, apparently written once during initial setup and used to drive today's banner logic.
• pip show hermes-agent inside the venv also reports the package as installed via a location consistent with a pip-manageable venv, which is expected for any uv-created venv (uv installs pip-compatible metadata).

Expected Behavior

The Tier-1-detection logic should recognize installs that went through install.ps1/uv as supported, rather than keying off pip-compatible package metadata that uv also produces. Alternatively, if .install_method is the source of truth, the bootstrap should be writing the correct value (e.g. installer/ps1/uv) instead of pip when the official installer is used.

Impact

Cosmetic/confusing today, but risks scaring supported users into unnecessary reinstalls, and could cause false negatives if this same detection is later used to gate real support/update behavior.

Environment

• OS: Windows 10/11 (x86_64)
• Install method: install.ps1 (Tier 1 documented method), venv managed by uv
• hermes-agent version: 0.18.2
• .install_method file content: pip

[alt-glitch]

This was generated by AI during triage.

Related to #53714 (adds a step-0 is_uv_tool_install() check to suppress this banner for uv-tool installs). This report is a distinct facet: the install.ps1/uv bootstrap flow stamps .install_method = pip (uv uses pip-compatible metadata under the hood), and detect_install_method() reads that stamp before any uv check, so bootstrap-installed users get the false 'unsupported pip install' banner. Not a duplicate — keeping open as the bootstrap-stamp facet of the same banner false-positive family.

[GottZ]

This was generated by AI during triage.

Summary

One PR addresses #61827 by overwriting the erroneous pip install-method stamp after the PowerShell bootstrap completes. However, its current placement covers only the monolithic installer path, not the staged path used by the official Desktop bootstrap.

Related pull requests

• fix(installer): write code-scoped .install_method stamp in install.ps1 to fix false-positive unsupported install method banner #61851 best fix — (+14/-0) — needs revision: The diff writes installer after Invoke-AllStages, which targets the reported stale pip stamp, but the official Desktop bootstrap invokes install.ps1 -Stage and exits before this code runs. Consistent with the keep_open review on fix(installer): write code-scoped .install_method stamp in install.ps1 to fix false-positive unsupported install method banner #61851, the stamp must move to the shared staged-completion path and use the existing BOM-free UTF-8 mechanism before this fixes the reported cause.

Suggested consolidation

Consolidate on #61851 as the sole candidate, but do not merge it as-is: address the contributor's keep_open review by moving the stamp to Write-BootstrapMarker/Stage-BootstrapMarker, writing it without a PowerShell 5.1 UTF-8 BOM, and adding staged-completion regression coverage. Once those changes are verified, merge #61851; there are no duplicate PRs to close.

Complex graph

flowchart LR
    classDef open fill:#dbeafe,stroke:#1d4ed8,color:#1e3a8a
    classDef merged fill:#dcfce7,stroke:#15803d,color:#14532d
    classDef closed fill:#e5e7eb,stroke:#6b7280,color:#1f2937
    classDef unverified fill:#f3f4f6,stroke:#9ca3af,color:#374151
    classDef best stroke-width:3px,stroke:#b45309
    classDef target stroke-width:3px,stroke:#4338ca
    I61827(["issue #61827 (open)"])
    I67161(["issue #67161 (closed)"])
    P61851["PR #61851 (open)"]
    P61851 -->|best fix| I61827
    class I61827 open
    class I67161 closed
    class I61827 target
    class P61851 open
    class P61851 best
    click I61827 "https://github.com/NousResearch/hermes-agent/issues/61827"
    click I67161 "https://github.com/NousResearch/hermes-agent/issues/67161"
    click P61851 "https://github.com/NousResearch/hermes-agent/pull/61851"

Loading

Graph: solid arrow = fixes / best fix, dashed arrow = partial or unverified (see edge label); boxed group = PRs duplicating each other; amber border = best fix; indigo border = target; gray node = closed or no verify verdict yet (state tag in the node label).

Cross-PR triage: Reviewed 1 pull request and 2 issues in this complex. Each diff was read against this issue; Assessment working set: <1 kB of PR diffs, 12 kB of issue/PR text, 3 kB of discussion (3 comments), 4 verify verdicts. verdicts reflect diff content, not PR titles. Part of an automated triage batch.