hermes - 💡(How to fix) Fix [Bug]: gateway_state.json reports stale argv after upstream binary path changes

Official PRs (…)
ON THIS PAGE

Recommended Tools

×6

Utilities matched from this issue’s tags and category — try them while you read without losing context.

GitHub issue graph ai analysis

Paste a GitHub issue URL. We fetch that issue, discover linked issues from bodies/comments/timeline, collect linked pull requests, and produce a structured English report.

The report is written in English Markdown for sharing and archival.

Helpful · Quick feedback

Loading…

Error Message

Additional Logs / Traceback (optional)

Root Cause

Root Cause Analysis (optional)

Fix Action

Fix / Workaround

Workaround: ignore the argv field; use ps aux | grep hermes_cli.main for real invocation.

Code Example

Skipping `hermes debug share` (automatic upload to public paste service) for privacy reasons. Manual environment info provided in the Operating System / Python Version / Hermes Version fields below.

The bug is fully reproducible from the JSON snippet in Actual Behavior; runtime state and logs are not required for diagnosis. Happy to provide specific files privately if needed for fix verification.

---
RAW_BUFFERClick to expand / collapse

Bug Description

When hermes-agent is installed via pip into a Python venv (not via the brew formula), and the launchd service is configured to run it via python -m hermes_cli.main gateway run, the file ~/.hermes/gateway_state.json reports an argv array that doesn't match the actual process command line.

After uninstalling the brew package while keeping the venv install, gateway_state.json still references the now non-existent brew binary path.

Expected: gateway_state.json["argv"] reflects the actual process invocation — the venv-Python module form (python -m hermes_cli.main gateway run --replace).

Actual: the reported argv points at /opt/homebrew/bin/hermes, which no longer exists.

Hypothesis: the gateway uses shutil.which("hermes") or a hardcoded entry-point lookup when serializing its self-state, rather than reading sys.argv / actual /proc/<pid>/cmdline.

Impact: purely cosmetic / diagnostic — service runs correctly, E2EE works. But anyone debugging path issues sees stale information.

Workaround: ignore the argv field; use ps aux | grep hermes_cli.main for real invocation.

{ "pid": 498, "kind": "hermes-gateway", "argv": ["/opt/homebrew/bin/hermes", "gateway", "run"], "start_time": null } agent 498 ... /opt/homebrew/Cellar/[email protected]/.../Python -m hermes_cli.main gateway run --replace

Steps to Reproduce

  1. brew install hermes-agent (creates /opt/homebrew/bin/hermes)
  2. Build hermes-agent from source into a separate venv: python3.12 -m venv ~/hermes-venv && pip install <source>
  3. Configure a service to run via ~/hermes-venv/bin/python -m hermes_cli.main gateway run
  4. brew uninstall hermes-agent (removes the brew binary)
  5. Restart the service via launchd
  6. Inspect ~/.hermes/gateway_state.jsonargv still points to the deleted brew path

Expected Behavior

gateway_state.json["argv"] should reflect the actual process invocation matching the launchd plist's ProgramArguments — i.e. the venv-Python module form:

python -m hermes_cli.main gateway run --replace

(or equivalent absolute paths). Whatever sys.argv would return for the running process.

Actual Behavior

gateway_state.json["argv"] reports a stale binary path that no longer exists on the system:

"argv": ["/opt/homebrew/bin/hermes", "gateway", "run"]

The brew binary at /opt/homebrew/bin/hermes was uninstalled. The actual running process is identified by ps aux as:

agent 498 ... /opt/homebrew/Cellar/[email protected]/.../Python -m hermes_cli.main gateway run --replace

The gateway has correct knowledge of its real process arguments (via the launchd plist) but writes incorrect ones to gateway_state.json.

Full gateway_state.json content:

{ "pid": 498, "kind": "hermes-gateway", "argv": ["/opt/homebrew/bin/hermes", "gateway", "run"], "start_time": null, "gateway_state": "running", "exit_reason": null, "restart_requested": false, "active_agents": 0, "platforms": { "matrix": { "state": "connected", "error_code": null, "error_message": null, "updated_at": "2026-05-09T10:13:39+00:00" } } }

Affected Component

Gateway (Telegram/Discord/Slack/WhatsApp)

Messaging Platform (if gateway-related)

N/A (CLI only)

Debug Report

Skipping `hermes debug share` (automatic upload to public paste service) for privacy reasons. Manual environment info provided in the Operating System / Python Version / Hermes Version fields below.

The bug is fully reproducible from the JSON snippet in Actual Behavior; runtime state and logs are not required for diagnosis. Happy to provide specific files privately if needed for fix verification.

Operating System

macOS 26 (Tahoe) / Apple Silicon (M2 Max)

Python Version

Python 3.12.13 (Homebrew formula [email protected], 3.12.13_2)

Hermes Version

v2026.4.30 (built from source via pip install)

Additional Logs / Traceback (optional)

Root Cause Analysis (optional)

No response

Proposed Fix (optional)

No response

Are you willing to submit a PR for this?

  • I'd like to fix this myself and submit a PR

Vote matrix · Quick signals

Works
Did the solution work? Tap to confirm.
Easy Fix
Was it a quick fix?
Time Saver
Did it save you time?
Blocking
Was it severely blocking?
Common Issue
Are others likely hitting this too?
Flaky / Intermittent
Is it intermittent?
Verified / Reproducible
Can you reproduce it reliably?
Loading…

Still need to ship something?

×6

Another batch ranked right after the header list — different links, same matching logic.

Back to top recommendations

TRENDING