fix(update): avoid cryptography self-lock on Windows

[duclucky]

What does this PR do?

Prevents hermes update from loading Bitwarden's native cryptography extension into the updater process before its uv child replaces dependencies.

On Windows, importing cryptography maps cryptography/hazmat/bindings/_rust.pyd. The parent updater then holds the exact native image that uv pip install -e . needs to rename or delete during a cryptography version change, so the update deterministically fails with os error 5 and can leave the venv partially uninstalled.

The update path still loads the selected profile's .env, managed environment, and terminal config. It skips only external secret-source fetching, which is not needed for Git/dependency maintenance. Because the full argparse construction also imports secrets_cli, Bitwarden's cryptographic cache primitives are now imported only when an encrypted cache is actually read or written.

Related Issue

Fixes #73381

Type of Change

• Bug fix (non-breaking change that fixes an issue)
• Tests (adding or improving test coverage)

Changes Made

• Add a load_external_secrets switch to load_hermes_dotenv(), defaulting to the existing behavior.
• Disable external secret-source fetching only for the update subcommand after profile arguments have been resolved.
• Lazy-load cryptography primitives in Bitwarden's encrypted-cache operations so parser construction cannot map _rust.pyd.
• Add subprocess regressions for both module startup and complete main() dispatch, plus controls for normal external-source and dotenv behavior.

How to Test

$env:TZ='UTC'
$env:LANG='C.UTF-8'
$env:HERMES_TEST_WORKERS='4'
.\.venv\Scripts\python.exe scripts\run_tests_parallel.py --paths 'tests/hermes_cli/test_update_secret_import_lock.py:tests/hermes_cli/test_env_loader.py:tests/hermes_cli/test_startup_fast_guards.py:tests/hermes_cli/test_update_check.py:tests/hermes_cli/test_update_venv_health.py:tests/hermes_cli/test_bitwarden_status.py:tests/hermes_cli/test_secrets_bitwarden_non_tty.py:tests/secret_sources/test_secret_source_registry.py' -q
.\.venv\Scripts\python.exe scripts\run_tests_parallel.py --paths tests/test_bitwarden_secrets.py -q -k encrypted_cache_falls_back_on_network_error
.\.venv\Scripts\ruff.exe check agent/secret_sources/bitwarden.py hermes_cli/main.py hermes_cli/env_loader.py tests/hermes_cli/test_update_secret_import_lock.py
.\.venv\Scripts\python.exe scripts/check-windows-footguns.py agent/secret_sources/bitwarden.py hermes_cli/main.py hermes_cli/env_loader.py tests/hermes_cli/test_update_secret_import_lock.py

Results on Windows 11 / Python 3.12.13:

• 69 targeted tests passed
• encrypted-cache fallback test passed
• Ruff passed
• Windows footgun scan passed for all 4 changed files

The full tests/test_bitwarden_secrets.py file has two existing Windows-specific failures unrelated to this patch: its install fixture archives bws while the Windows implementation correctly searches for bws.exe, and its POSIX 0o600 mode assertion observes 0o666 on NTFS. Those are not reported as passing here.

Checklist

Code

• I've read the Contributing Guide
• My commit message follows Conventional Commits
• I searched open and merged PRs/issues and found no PR for the updater's self-lock
• My PR contains only changes related to this fix
• I've run the entire pytest tests/ -q suite and all tests pass
• I've added tests for the bug
• I've tested on Windows 11

Documentation & Housekeeping

• Documentation update: N/A; behavior and public parameter are documented in code
• cli-config.yaml.example: N/A; no config key added
• CONTRIBUTING.md / AGENTS.md: N/A; no workflow change
• Cross-platform impact considered; default behavior is unchanged outside the update invocation
• Tool descriptions/schemas: N/A

[GottZ]

This was generated by AI during triage.

Summary

All 40 PRs address or reference the Windows update-lock complex, spanning shim quarantine, launcher ancestry, venv and gateway holders, installer recreation, Desktop handoff, false-positive filtering, ZIP preservation, and updater-native-module self-locks. For #73381, #77517 uniquely prevents the updater itself from loading Bitwarden's cryptography _rust.pyd, while the other PRs address adjacent lock sources or recovery paths.

Related pull requests

• fix(update): rename hermes.exe before uv/pip install on Windows #23353 [closed] best fix — (+104/-273) — superseded partial fix: renames the active shim before install but bundles unrelated reversions; the focused quarantine approach later landed through fix(update): quarantine hermes.exe vs concurrent Windows instance (#26670) #26677, so this closed PR remains historical evidence.
• fix(update): rename hermes.exe before uv/pip install on Windows #23408 [closed] best fix — (+91/-41) — duplicate of fix(update): rename hermes.exe before uv/pip install on Windows #23353 and superseded by fix(update): quarantine hermes.exe vs concurrent Windows instance (#26670) #26677: uses one fixed .exe.old rename, while the merged implementation adds timestamped quarantine, retries, and deferred handling; closed.
• [codex] Fix Windows update locked shims #26365 [closed] partial — (+253/-5) — close as already implemented on main: its WMIC/taskkill retry targets locked shims, while merged fix(update): quarantine hermes.exe vs concurrent Windows instance (#26670) #26677 implemented the same cause more broadly in 2a7308b7c4c4e76648211d5953395bd8ecd0ad64, as cited by the automated close verdict.
• fix(update): quarantine hermes.exe vs concurrent Windows instance (#26670) #26677 [merged] best fix — (+688/-108) — merged reference implementation for foreign hermes.exe locks: adds preflight detection, retrying quarantine, deferred replacement, tests, and remediation, but not the later _rust.pyd self-lock fixed by fix(update): avoid cryptography self-lock on Windows #77517.
• fix(cli-update): exclude launcher-shim ancestor PIDs from concurrent check on Windows (#29341) #29358 [closed] fixes — (+309/-5) — superseded by fix(windows): exclude parent hermes.exe shim from concurrent-instance check #31808/fix(update/windows): robustly exclude launcher-shim ancestors from concurrent check #35257: excludes launcher ancestors via a per-hop walk, while the successor uses proc.parents() with shim-only filtering; closed.
• fix: exclude parent process chain from concurrent instance detection on Windows #31712 [closed] partial — (+32/-5) — salvaged through merged fix(cli/windows): exclude parent process chain from concurrent-instance detection (salvage of #31712) #31806 and later hardened by fix(update/windows): robustly exclude launcher-shim ancestors from concurrent check #35257; it fixes launcher self-detection but excludes the full ancestor chain more broadly than the final shim-only rule.
• fix(cli/windows): exclude parent process chain from concurrent-instance detection (salvage of #31712) #31806 [merged] partial — (+215/-5) — merged historical launcher-parent fix preserving fix: exclude parent process chain from concurrent instance detection on Windows #31712 authorship, relevant as the predecessor to fix(update/windows): robustly exclude launcher-shim ancestors from concurrent check #35257's narrower and more robust implementation.
• fix(windows): exclude parent hermes.exe shim from concurrent-instance check #31808 [closed] best fix — (+126/-4) — best existing diff for [Bug]: Windows: \hermes update always reports "Another hermes.exe is running" — launcher shim PID not excluded from concurrent-instance detection #29341/Windows: hermes update always aborts — concurrent-instance guard detects its own venv launcher shim #60239 but superseded by merged fix(update/windows): robustly exclude launcher-shim ancestors from concurrent check #35257: it already uses parents() and shim-only ancestor exclusion; closed.
• fix(run_agent): gate concurrent checkpoint preflight on block_result (fixes #34827) #35255 [merged] related — (+143/-22) — merged but unrelated to this cause: despite its Windows-update title/body, the actual diff only gates concurrent checkpoint creation on block_result.
• fix(cli): detect venv python workers before update to prevent .pyd lock failures (#38789) #39037 [closed] best fix — (+104/-6) — close as already implemented on main: detects venv python.exe/pythonw.exe .pyd holders, while b14d75f8afdb624be03cbefd19494ccc850bf367 adds broader trampoline detection and recovery, as the automated close verdict records.
• fix(update): pause Windows gateway before venv refresh #39487 [closed] best fix — (+209/-0) — close as already implemented on main: pauses one installed gateway, while 78c11d99e35b111dd6198d8bc6aa1f7f6f168232 covers mapped and unmapped gateway lifecycle more broadly.
• fix(desktop): kill untracked hermes processes before update (#43268) #43381 [closed] best fix — (+28/-0) — obsolete partial workaround: kills extra hermes.exe processes before Desktop handoff but misses dominant python.exe/pythonw.exe and trampoline holders; closed.
• fix(install): kill venv-resident gateway before recreating venv on Windows #46726 [closed] fixes — (+26/-3) — superseded by merged fix(install): kill venv-resident gateway before recreating venv on Windows #52044: introduced venv-path-scoped process termination before Remove-Item, later salvaged with normalized matching, retry behavior, and tests; closed.
• fix(install): clear venv python locks on Windows #47569 [closed] partial — (+53/-2) — duplicate of fix(install): kill venv-resident gateway before recreating venv on Windows #46726/fix(install): kill venv-resident gateway before recreating venv on Windows #52044: stops selected venv Python processes and adds ordering coverage, while fix(install): kill venv-resident gateway before recreating venv on Windows #52044 sweeps every executable under the normalized venv prefix; closed.
• fix(installer): kill venv processes before removing venv dir (#47557) #47610 [closed] partial — (+27/-1) — duplicate of fix(install): kill venv-resident gateway before recreating venv on Windows #46726/fix(install): kill venv-resident gateway before recreating venv on Windows #52044: kills selected venv executables and retries deletion, with the useful retry behavior retained by the broader merged implementation; closed.
• fix(cli): kill venv python processes before venv recreation on Windows #47621 [closed] fixes — (+11/-0) — close as already implemented on main by merged fix(install): kill venv-resident gateway before recreating venv on Windows #52044 commit 6638199c53f64f995ac02253456f719960ec7673, which provides the stronger case-insensitive process sweep and tests.
• fix(update): authoritative venv-lock probe — refuse to mutate a locked Windows venv and defer to finish-hermes-update.cmd #51359 [closed] best fix — (+336/-0) — close as already implemented on main: despite its approving review, the shim rename probe is superseded by the broader venv/trampoline guard in 87ae4ae94bc13e302be2a37b30226f2b19909227.
• fix(install): kill venv-resident gateway before recreating venv on Windows #52044 [merged] best fix — (+77/-4) — merged installer reference implementation: stops venv-resident processes by normalized path and retries deletion, preventing gateway-held native files from breaking venv recreation.
• fix(desktop/windows): stop the uv-launched gateway before recreating the venv #53124 [closed] best fix — (+32/-0) — close as already implemented on main: its uv-trampoline gateway handling is covered more broadly by repeated sweeps and rename-parking in b14d75f8afdb624be03cbefd19494ccc850bf367.
• fix(update): ignore Windows system venv holder noise #57852 best fix — (+75/-0) — keep open with a salvage path, consistent with its keep_open verdict: retain the focused Registry/Memory Compression false-positive regression while preserving user-space Python trampoline detection.
• fix(windows): exclude system processes from venv holder detection (#57829) #58343 [closed] partial — (+12/-0) — duplicate of fix(update): ignore Windows system venv holder noise #57852, closed; its similar system-process filter also bundles an unrelated dashboard-auth redirect that should remain separate.
• fix(update): reap gateway venv children so the Windows venv guard self-clears #61515 [closed] best fix — (+605/-30) — closed despite the earlier keep_open review: token-aware MCP/perfmon child reaping remains potentially salvageable, but the later contributor decision attributed the observed path to updater orchestration fixed elsewhere, so this large diff should not be revived wholesale.
• fix(tests): stop cmd_update tests leaking real detached Windows gateways #61752 related — (+43/-1) — keep open with a salvage path: retain the autouse fixture preventing updater tests from leaking detached Windows gateways, a test-isolation fix distinct from Windows Desktop update fails — venv missing cryptography + Windows file locking causes uv pip install exit code 2 #73381's production lock.
• fix(cli): detect hermes update running inside active session on Windows #65726 best fix — (+358/-1) — keep open with a salvage path, matching its keep_open verdict: preserve the native-verified guard distinguishing a normal immediate launcher from a farther-up active Hermes session.
• fix(update): terminate stray venv holder processes on unattended Windows update #67229 [closed] partial — (+153/-17) — correctly closed after the blocking contributor review: making --yes terminate every holder can kill supervised processes, and one immediate rescan does not prove stable quiescence.
• fix(update): add venv_holder_allowlist + pre_update_command (#66933) #67398 [closed] best fix — (+833/-7) — closed pending maintainer policy: its hook and holder allowlist address externally supervised deployments, and review defects were corrected, but operator-attested bypass semantics remain a separate design decision.
• fix(update): hard-stop when Windows hermes.exe shim stays locked #68821 best fix — (+258/-30) — keep open with a salvage path, consistent with its keep_open review: hard-stop when shim quarantine remains locked or reboot-deferred and retain the added no-uv regression, but treat it as complementary to fix(update): avoid cryptography self-lock on Windows #77517's _rust.pyd prevention.
• fix(windows): stop pythonw backends during desktop update #70033 best fix — (+35/-12) — keep open only with rework, matching its keep_open review: the venv-scoped sweep is safer than global taskkill, but its current lock probes do not trigger for Python-only or loaded-.pyd holders.
• fix(desktop): stop gateway before update + preserve release dir in ZIP fallback (#70337) #70477 best fix — (+45/-2) — author action: split out and rebase the ZIP-release preservation, staging outside apps/ in hermes_cli/update_cmd.py with a survival test; its gateway work is superseded by merged fix(update): let Windows desktop updates pause gateway processes instead of aborting #75881.
• fix(constants): swallow OSError in managed-node file probes (#70708) #70725 best fix — (+159/-7) — keep open with a salvage path, but address the keep_open review explicitly: preserve the non-crashing file probe while making a locked managed npm shim produce repair or visible failure rather than silently skipping refresh.
• fix(desktop): gate backend respawns on updateInFlight, not just the update marker (#73822) #73928 [merged] best fix — (+296/-15) — merged reference fix for Desktop's self-respawn race: gates primary and pool backend starts on updateInFlight plus the marker, while external gateway holders remain covered by fix(update): let Windows desktop updates pause gateway processes instead of aborting #75881.
• Fix Desktop updates blocked by Gateway processes #74165 [closed] partial — (+507/-42) — closed in favor of fix(update): one updater at a time, and never roll an install backwards #74436 after classifying verified gateway trees for handoff; relevant as an abandoned orchestration approach rather than current implementation.
• fix(update): coordinate Windows gateway pause across three layers during desktop update (#74386) #74419 [closed] best fix — (+486/-14) — superseded by fix(update): unbrick desktop updates on gateway-enabled Windows installs #74618/fix(update): let Windows desktop updates pause gateway processes instead of aborting #75881 and closed: its Electron pre-pause had a typecheck failure and unsafe free-text gateway matcher, while the successor centralizes classification in Python.
• fix(update): unbrick desktop updates on gateway-enabled Windows installs #74618 [closed] best fix — (+574/-4) — superseded by merged salvage fix(update): let Windows desktop updates pause gateway processes instead of aborting #75881, which preserves its canonical gateway matcher, pre-drain launcher snapshot, guard recheck, fixes, and authorship; closed.
• fix(update): match gateways using full command lines #74707 best fix — (+128/-474) — close as duplicate of fix(update): let Windows desktop updates pause gateway processes instead of aborting #75881: despite its keep_open review finding no source blocker, merged fix(update): let Windows desktop updates pause gateway processes instead of aborting #75881 already coordinates gateway-only preflight, launcher cleanup, and fail-closed non-gateway handling without deleting the Desktop scanner.
• fix(desktop): allow updater handoff for gateway-only venv locks #75380 best fix — (+304/-0) — author action: rebase onto main or split any remaining value; despite its keep_open review, its original gateway-only timeout bypass still met a second blocker gate, while merged fix(update): let Windows desktop updates pause gateway processes instead of aborting #75881 carries the complete classification-through-guard path.
• fix(update): let Windows desktop updates pause gateway processes instead of aborting #75881 [merged] best fix — (+574/-4) — merged reference implementation for gateway-enabled Desktop updates: uses one canonical matcher, snapshots launcher ancestry before drain, stops gateway-only leftovers, rescans, and keeps non-gateway holders fail-closed.
• fix(desktop): stop messaging gateway before venv lock check during update #76057 partial — (+187/-0) — author action: rebase onto main or split out a demonstrably missing Desktop-side cut; merged fix(update): let Windows desktop updates pause gateway processes instead of aborting #75881 already handles all-profile gateway discovery, launcher ancestry, pause/resume, and guard recheck more completely.
• fix(updater): release self-held lock during Windows desktop update #76071 [closed] best fix — (+36/-2) — close as already implemented on main: ed77a347307e2e9c7f967ae146c4d3148a63433d already walks updater ancestry and accepts the legacy hermes-setup.exe → hermes.exe → python.exe handoff.
• fix(update): avoid cryptography self-lock on Windows #77517 best fix — (+147/-6) — keep open with a salvage path: uniquely prevents Windows Desktop update fails — venv missing cryptography + Windows file locking causes uv pip install exit code 2 #73381's deterministic self-lock by skipping external secret fetching for update, lazy-loading Bitwarden cryptography, and testing complete main() dispatch without importing cryptography.

Duplicates

#23353/#23408, #29358/#31712/#31806/#31808, #46726/#47569/#47610/#47621/#52044, #57852/#58343, and #74419/#74618/#74707/#75380/#75881/#76057 are overlapping families; the canonical landed implementations are #26677, #35257, #52044, and #75881 respectively. #68821 and #77517 are complementary rather than duplicates: the former hard-stops a still-locked shim, while the latter prevents the updater from mapping cryptography _rust.pyd itself.

Suggested consolidation

Keep #77517 open with the concrete salvage path already present—update-only external-secret suppression, lazy Bitwarden cryptography imports, and full-dispatch regression coverage—because no other diff addresses the updater's own _rust.pyd mapping. Close overlapping open work as duplicate of the cited merged implementations where applicable, retain #57852, #61752, #65726, #68821, and #70725 only for their distinct salvage cuts, and require author rebase/splitting for #70477, #75380, and #76057.

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
    I73381(["issue #73381 (open)"])
    P77517["PR #77517 (open)"]
    P77517 -->|best fix| I73381
    class I73381 open
    class P77517 open
    class P77517 best
    class P77517 target
    click I73381 "https://github.com/NousResearch/hermes-agent/issues/73381"
    click P77517 "https://github.com/NousResearch/hermes-agent/pull/77517"

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 (state tag in the node label).

Cross-PR triage: Reviewed 40 pull requests and 34 issues in this complex. Each diff was read against this issue; Assessment working set: 555 kB of PR diffs, 250 kB of issue/PR text, 146 kB of discussion (144 comments), 212 verify verdicts. verdicts reflect diff content, not PR titles. Part of an automated triage batch.

[tneemo]

Independent verification — reproduced and confirmed on Windows 11

Verified the diff on a real Windows 11 host (the exact platform where the bug bites). Applied the head files + ran the new regression test.

Result: 5/5 tests pass in tests/hermes_cli/test_update_secret_import_lock.py:

• test_update_startup_does_not_import_bitwarden_or_cryptography ✅
• test_complete_update_dispatch_does_not_import_cryptography ✅
• test_normal_startup_still_loads_enabled_external_secret_source ✅
• test_dotenv_loading_is_preserved_when_external_secrets_are_skipped[True] ✅
• test_dotenv_loading_is_preserved_when_external_secrets_are_skipped[False] ✅

Before/after check on the actual mechanism:

State	cryptography in sys.modules after startup
current main	✅ loaded → maps _rust.pyd into the process (the self-lock)
with this diff	❌ not loaded for the hermes update path; still loaded for normal startup

Confirmed the root-cause mechanism exactly as described: on current main, importing agent.secret_sources.bitwarden pulls cryptography.hazmat.bindings._rust into the interpreter; with the lazy imports + load_external_secrets=False for the update subcommand, the updater process no longer holds the native image that uv needs to replace.

Design observations:

• The sys.argv[1:2] != ["update"] gate in main.py is correctly placed after profile-flag stripping, so hermes -p profile update still routes correctly.
• Moving AESGCM/HKDF/hashes imports inside the cache read/write/derive functions keeps the lazy-load semantic tight — only encrypted-cache ops pay the import.
• The new flag default (load_external_secrets=True) preserves normal startup behavior — no regression for users who rely on Bitwarden env injection.

This is a clean, surgical fix for a nasty Windows-only self-lock. MERGEABLE, CI-ready tests included. Approving the diff as-is.

[duclucky]

Rebased this PR onto current main (4a99ba195); the new head is a5b5928d5. git range-diff shows the patch itself is unchanged, and the branch is now 1 commit ahead / 0 behind.

Windows validation through the repository-mandated scripts/run_tests.sh wrapper:

• tests/hermes_cli/test_update_secret_import_lock.py: 5 passed
• env-loader/external-secret coverage (test_env_loader.py, test_env_loader_secret_sources.py, test_env_loader_applied_homes.py, test_env_loader_op_bootstrap.py): 44 passed
• secret-source registry + non-TTY Bitwarden CLI coverage: 33 passed
• tests/test_bitwarden_secrets.py: 16 passed, 2 unrelated Windows portability assertions failed (bws fixture name vs bws.exe, and POSIX 0o600 mode on Windows reporting 0o666). That test file is unchanged by this PR, and neither failing behavior is in the patch.
• Ruff on all four changed files: passed

I also attempted tests/hermes_cli/test_cmd_update.py separately; it did not complete after more than five minutes on this Windows host, so I terminated that isolated test process tree and am not claiming it as passed.

The behavior boundary remains the same after rebase: normal startup still loads configured external secrets, while only the update dispatch skips external-secret fetching; Bitwarden's cryptography imports remain lazy and are loaded when encrypted-cache operations actually run.

[aare]

Hitting this exact bug on a clean system -- no gateway running, no other Hermes processes, just the updater locking its own _rust.pyd. The self-repair loop on every launch is painful. tneemo already verified and approved -- would love a second review to get this merged. Thanks!

[teknium1]

Merged via PR #87241 with your commit cherry-picked onto current main — your authorship is preserved in git history. Thanks for the fix and the thorough regression tests! This was the root-cause fix for the Windows update self-lock loop (#86735).