Bug Description

On macOS, hermes cron list always prints a false-positive warning:

⚠  Gateway is not running — jobs won't fire automatically.
   Start it with: hermes gateway install

even when the gateway is actively running under launchd and the cron jobs themselves continue to fire correctly.

The warning is purely a display bug in find_gateway_pids(). It has no effect on cron firing (a separate code path under gateway/run.py drives job execution), but it is misleading and may cause users to run hermes gateway install unnecessarily (which is a no-op when the plist is already current).

This issue is related to but not a duplicate of #9069 (same function, FreeBSD, different failure mode) and #9723 (same function, Docker, closed via commit c483b4c). The macOS case fails in a different way because both detection stages — launchctl and the ps fallback — fail for distinct reasons on Darwin.

Steps to Reproduce

1. Install hermes-agent on macOS and configure a cron job (e.g. github-release-watch via the gateway).

2. Start the gateway service: hermes gateway install (the plist at ~/Library/LaunchAgents/ai.hermes.gateway.plist is created and loaded; RunAtLoad=true so it starts automatically).

3. Verify the gateway is actually running:

   $ launchctl list | grep hermes 855 0 ai.hermes.gateway $ hermes gateway status ✓ Service definition matches the current Hermes install ✓ Gateway service is loaded ... "PID" = 855;

4. Run hermes cron list.

5. Observe the warning appended to the job list:

   ⚠ Gateway is not running — jobs won't fire automatically.

Expected Behavior

No warning should appear when the gateway is actually running under launchd. hermes gateway status already correctly reports the service as loaded; hermes cron list's detector should agree.

Actual Behavior

The warning appears on every invocation of hermes cron list (and in other sites that call find_gateway_pids()), despite the gateway being confirmed running via launchctl list, ps -p <pid>, and a healthy gateway_state.json showing "gateway_state": "running" with a connected Telegram platform.

Cron firing itself is unaffected — jobs continue to fire on schedule and deliveries arrive via Telegram. Only the display is wrong.

Affected Component

CLI (interactive chat), Gateway (Telegram/Discord/Slack/WhatsApp)

Messaging Platform (if gateway-related)

N/A (CLI only)

Debug Report

Not attached in this report. I can share `hermes debug share` output on request. The reproduction above and the root-cause analysis below should be sufficient to identify the bug from source.

Operating System

macOS 15.2 (Darwin 25.4.0, Apple Silicon)

Python Version

3.11.15

Hermes Version

v0.10.0 (2026.4.16)

Additional Logs / Traceback (optional)

Root Cause Analysis (optional)

Two independent bugs cause find_gateway_pids() to return an empty list on macOS. Either bug alone would cause the macOS detection to fall through to the other stage, but because both stages are broken, the overall result is an empty list and the warning fires.

Bug 1: _get_service_pids() parses launchctl list <label> as tab-separated format

hermes_cli/gateway.py (around lines 82–102, in the is_macos() branch):

if is_macos():
    try:
        label = get_launchd_label()
        result = subprocess.run(
            ["launchctl", "list", label],
            capture_output=True, text=True, timeout=5,
        )
        if result.returncode == 0:
            # Output: "PID\tStatus\tLabel" header, then one data line
            for line in result.stdout.strip().splitlines():
                parts = line.split()
                if len(parts) >= 3 and parts[2] == label:
                    try:
                        pid = int(parts[0])
                        if pid > 0:
                            pids.add(pid)
                    except ValueError:
                        pass
    except (FileNotFoundError, subprocess.TimeoutExpired):
        pass

The inline comment says the expected format is "PID\tStatus\tLabel". That format is what launchctl list (with no label argument) produces. When called with a label argument, macOS launchctl instead returns a plist-dict:

$ launchctl list ai.hermes.gateway
{
    "StandardOutPath" = "/Users/<user>/.hermes/logs/gateway.log";
    "LimitLoadToSessionType" = "Aqua";
    "StandardErrorPath" = "/Users/<user>/.hermes/logs/gateway.error.log";
    "Label" = "ai.hermes.gateway";
    "OnDemand" = true;
    "LastExitStatus" = 0;
    "PID" = 855;
    "Program" = "/Users/<user>/.hermes/hermes-agent/venv/bin/python";
    ...
};
$ echo "exit=$?"
exit=0

line.split() on the "Label" = "ai.hermes.gateway"; line yields ['"Label"', '=', '"ai.hermes.gateway";']. parts[2] is '"ai.hermes.gateway";' (with quotes and trailing semicolon), which never equals the bare label string. No PID is ever extracted and _get_service_pids() returns an empty set.

Bug 2: ps -A eww -o pid=,command= is an illegal argument on macOS

hermes_cli/gateway.py (around lines 224–229, in the find_gateway_pids() non-Windows fallback):

result = subprocess.run(
    ["ps", "-A", "eww", "-o", "pid=,command="],
    capture_output=True, text=True, timeout=10,
)

Darwin's ps rejects eww as a positional argument:

$ ps -A eww -o pid=,command=
ps: illegal argument: eww
usage: ps [-AaCcEefhjlMmrSTvwXx] ...

$ echo "exit=$?"
exit=1

stdout is empty, the parse loop iterates nothing, and no PID is extracted.

This is related to but distinct from #9069 (FreeBSD: the command runs but the output contains an environment-variable prefix that breaks split(None, 1)) and #9723 (Docker with procps-ng: already addressed by c483b4c, but that fix does not touch the macOS code path).

Combined effect

The same empty list propagates to other call sites of find_gateway_pids() (the cron list warning, the gateway status secondary check, and anywhere else that uses the helper to decide whether to skip further work).

Proposed Fix (optional)

I'm reporting this as an issue only — I don't plan to submit a PR for this one. Suggestions for whoever does:

For Bug 1 (_get_service_pids() launchctl parsing):

• Either drop the label argument and run launchctl list (no args), which returns the documented PID\tStatus\tLabel tab-separated format that the current code already expects; then filter by parts[2] == label.
• Or keep passing label but parse the plist-dict output properly — look for "PID" = NNN; lines with a simple regex, e.g. re.search(r'"PID"\s*=\s*(\d+)\s*;', result.stdout).
• The first option is smaller and keeps the existing loop structure; the second is more robust if launchctl behavior diverges further.

For Bug 2 (ps fallback arguments):

• ["ps", "-A", "-ww", "-o", "pid=,command="] works on macOS and still produces the wide, unabridged command column. Dropping the e (which attaches env vars) is arguably desirable anyway — see #9069 where the env-var prefix breaks FreeBSD parsing even when the command runs.
• Alternatively, special-case macOS the same way the Windows branch is special-cased, using launchctl more aggressively (it already has the PID from Bug 1's fix).

Fixing only one of the two bugs would already resolve the macOS warning (either path alone is enough to detect the PID). Fixing both makes the detector resilient to a regression in either route.

Are you willing to submit a PR for this?

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