fix(update): skip concurrent-instance abort when only the gateway is running

[damadorPL]

Bug Description

On Windows, hermes update aborts with exit code 2 and a wall of "Another
hermes.exe is running" guidance whenever any other process whose .exe is
the venv hermes.exe or hermes-gateway.exe shim is running — including
the gateway itself, which the post-update kill+restart block at the bottom
of cmd_update is going to reap anyway.

This forces every Windows user with a running gateway into a manual
taskkill /F /IM hermes.exe dance before every hermes update, even
though the post-update sweep already handles the gateway cleanly. The
user's only escape is --force, which suppresses the message but
doesn't change the underlying redundancy.

Related: the issue #26670 the pre-update gate was added to address
(WinError 32 on the venv shim during pip install -e .) is NOT a
gateway problem — the _quarantine_running_hermes_exe retry /
MoveFileEx-reboot-deferred fallback added at the same time handles
that case for the gateway too. So skipping the abort for gateway-only
matches doesn't reintroduce the original lock failure: the quarantine
step still renames the live shim before uv writes a replacement.

Root Cause

hermes_cli/main.py:9300 calls _detect_concurrent_hermes_instances,
which lists every process whose executable is one of the venv
shims (hermes.exe, hermes-gateway.exe). It then prints the full
list and sys.exit(2) regardless of whether the matches are all
gateways (which the post-update sweep will handle) or genuinely
unrelated processes (TUI shell, Hermes Desktop backend, a separate
REPL in another terminal).

The post-update kill+restart block at lines 9994-10500 matches
gateways by command line — "hermes gateway", "hermes.exe gateway", "hermes-gateway.exe", "hermes_cli.main gateway",
"gateway/run.py" — and correctly excludes the calling process and
its ancestor chain. So the post-update path is already safe; only the
pre-update gate is over-broad.

Fix

Add a small classifier that mirrors the post-update sweep's gateway
patterns, and gate the pre-update abort on the non-gateway
subset of matches. If every concurrent match is a gateway, the
update proceeds and the post-update block reaps the gateway PID. If
anything else is in the list, the existing abort message and
--force escape hatch remain unchanged.

New helpers (in hermes_cli/main.py):

• _classify_concurrent_instance(pid) — reads the pid's cmdline via
  psutil and returns "gateway", "non-gateway", or "unknown"
  (cmdline unreadable / access denied / psutil unavailable). The
  classifier mirrors the substring markers in
  hermes_cli/gateway.py:_scan_gateway_pids so the two scans match
  the same set of PIDs.
• _filter_non_gateway_concurrent_instances(matches) — returns the
  subset of concurrent-instance matches whose pid is not a
  gateway.

The pre-update gate at line 9300 now calls the filter and aborts only
on the non-gateway subset:

if concurrent:
    non_gateway = _filter_non_gateway_concurrent_instances(concurrent)
    if non_gateway:
        print(_format_concurrent_instances_message(non_gateway, scripts_dir))
        sys.exit(2)

Unknown-classified pids (psutil can't read them) bucket as
non-gateway — the gate errs on the side of the existing abort, so we
never silently kill a process we couldn't positively identify.

How to Verify

1. Start a gateway: hermes gateway run (or start it via the service
   manager, on Linux/macOS).
2. Run hermes update from a different terminal.
3. Before this fix: exits with code 2, prints "Another hermes.exe is
   running" listing the gateway PIDs, user has to taskkill manually.
4. After this fix: update proceeds. The gateway is killed by the
   post-update block and respawned by the existing watcher logic
   (launch_detached_profile_gateway_restart).
5. With a TUI / Desktop / unrelated REPL also running, the gate
   still aborts and lists only the non-gateway matches.

Test Plan

• Added 8 new tests in
  tests/hermes_cli/test_update_concurrent_quarantine.py:
  • 5 unit tests for the new helpers (gateway cmdline
    recognition across launcher types, non-gateway cmdline
    recognition, psutil error → unknown, no-psutil → unknown,
    mixed-list filter splitting, gateway-only → empty filter).
  • 2 cmd_update integration tests: the user's bug
    (test_cmd_update_skips_abort_when_only_concurrent_is_gateway)
    and the unchanged behaviour for non-gateway matches
    (test_cmd_update_still_aborts_on_non_gateway_concurrent).
• Existing 18 tests in test_update_concurrent_quarantine.py
  still pass.
• Other unrelated test failures on this Windows host
  (test_update_autostash.py,
  test_update_stale_dashboard.py,
  test_cmd_update.py::test_update_on_fork_*) are pre-existing
  and confirmed against main before this change. They are
  caused by Windows-specific wmic/ps quirks, not by this fix.

Risk Assessment

Low — the change is narrowly scoped:

• The post-update kill+restart block is unchanged; the only
  difference is whether the pre-update gate fires for gateway-only
  matches.
• The classifier uses the same substring patterns as
  _scan_gateway_pids in hermes_cli/gateway.py, so a pid classified
  as "gateway" here is the same set of PIDs the post-update sweep
  will reap. Symmetry by construction.
• Unrelated concurrent instances (Desktop backend, TUI, plain REPL)
  still trigger the existing abort with no behaviour change.
• unknown (psutil can't read cmdline) defaults to non-gateway, so
  we never silently kill a process we couldn't positively identify.

[Copilot]

Pull request overview

Note

Copilot was unable to run its full agentic suite in this review.

Adds logic to relax the Windows pre-update concurrent-instance gate so hermes update can proceed when the only other running Hermes process is the gateway (which is already handled by the post-update kill+restart flow).

Changes:

• Introduces _classify_concurrent_instance and _filter_non_gateway_concurrent_instances to identify and ignore gateway-only concurrent processes.
• Updates the Windows concurrent-instance abort gate in _cmd_update_impl to consider only non-gateway processes.
• Adds unit/integration-style tests covering classification, filtering, and the updated gate behavior.

Reviewed changes

Copilot reviewed 2 out of 2 changed files in this pull request and generated 2 comments.

File	Description
hermes_cli/main.py	Adds gateway-aware classification/filtering and updates the Windows concurrent-instance abort gate accordingly.
tests/hermes_cli/test_update_concurrent_quarantine.py	Adds tests for the new helper functions and for the relaxed/update gate behavior.

---

💡 Add Copilot custom instructions for smarter, more guided reviews. Learn how to get started.

[teknium1]

Thanks for isolating the Windows update gate; the underlying issue remains on current main. hermes_cli/main.py:9481-9484 still exits on every concurrent shim before _pause_windows_gateways_for_update() runs at hermes_cli/main.py:9490.

Problems

• The PR's duplicated substring matcher in hermes_cli/main.py:8276 is not equivalent to current gateway discovery. gateway/status.py:221-297 now tokenizes and accepts only a real gateway runtime command; the PR would treat hermes.exe gateway status as a gateway.
• tests/hermes_cli/test_update_concurrent_quarantine.py:625 patches real psutil, not the constructed fake, so its AccessDenied branch is not exercised.
• The new cmd_update tests mock _filter_non_gateway_concurrent_instances, leaving the real gate-to-classifier integration untested.

Suggested changes

• Reuse the current gateway command-line predicate rather than maintaining marker substrings, and add a status-command negative case.
• Fix the psutil stub and test the real filter through the update gate.

Automated hermes-sweeper review.

[teknium1]

Merged via #95059 (rebase merge, commit 36f1423) — your commit cherry-picked onto current main with your authorship preserved in git log. The gate had moved from hermes_cli/main.py into hermes_cli/update_cmd.py in the decomposition since you opened this, so it landed as a surgical reapply of your design: gateway-only concurrent matches no longer abort hermes update; everything else still refuses exactly as before.

One change from your original: the classifier delegates to the canonical gateway.status.looks_like_gateway_command_line matcher (via _is_pausable_gateway) instead of the substring list, which fixes the hermes gateway status misclassification flagged in review and keeps the gate in lockstep with the pause machinery. Also rode along: the abort message now lists only non-gateway PIDs, so users are no longer told to taskkill a gateway the updater handles itself.

Verified live on windows-latest with real spawned processes (11/11), plus an A/B run proving the old refusal fires on merge-base. Thanks for the fix and the thorough root-cause writeup — the post-update-sweep symmetry argument was exactly right.