fix(gateway): drop _HERMES_GATEWAY blanket guard for legit internal restarts

[drzeast-png]

Problem

PR #35679 added a blanket guard that refuses all stop/restart commands from inside the gateway process (via the _HERMES_GATEWAY env var). The intent was to prevent the cron+KeepAlive respawn loop from #30719 — but it has the side effect of blocking legitimate manual restarts from WeChat/Telegram/etc., forcing users to SSH in or use an external terminal.

Additionally, the guard does not actually prevent the original #30719 loop: cron jobs run as subprocesses that inherit _HERMES_GATEWAY=1, but the guard triggers on the first attempt, not on the loop pattern itself.

Solution

Drop the guard entirely. Trust launchd KeepAlive (or systemd Restart=always / container restart policy) as the only respawn policy. With #35668 (KeepAlive unconditional) merged, the supervisor handles respawn correctly — no agent-side guard needed.

Behavior comparison

Scenario	Old guard	No guard (this PR)
Manual restart from WeChat/Telegram	❌ Blocked	✅ Allowed
cron fires restart once an hour	❌ Blocked (if inside gateway)	✅ Allowed
cron fires restart every 10s + KeepAlive (original #30719 loop)	❌ Blocks 1st attempt (breaks the loop but also breaks valid use)	✅ KeepAlive ensures stable respawn; the macOS race is fixed in companion PR

Companion PRs

• fix(gateway): keep launchd KeepAlive unconditional for macOS resilience #35668 — KeepAlive unconditional (lands first, this PR depends on it being in)
• macOS via_service race fix (companion PR, incoming) — prevents SIGTERM ping-pong at the source

Supersedes

• fix(gateway): replace blanket internal-restart guard with loop detector #35815 (loop-detector variant) — closed in favor of this simpler approach

Test plan

• From inside the gateway (WeChat DM): hermes gateway restart now succeeds
• launchd plist shows KeepAlive unconditional after fix(gateway): keep launchd KeepAlive unconditional for macOS resilience #35668
• Manual restart from terminal still works (was always OK)
• No infinite-loop regression observed

[liuhao1024]

One concern worth noting before merge.

Companion PR #35668 is still OPEN (not merged).

The PR body states the fix depends on #35668 ("With #35668 (KeepAlive unconditional) merged, the supervisor handles respawn correctly — no agent-side guard needed"), but #35668 has not landed yet. If this PR merges first, there's a window where:

1. The _HERMES_GATEWAY guard is removed (this PR)
2. KeepAlive is not yet unconditional (fix(gateway): keep launchd KeepAlive unconditional for macOS resilience #35668 still open)
3. The original Agent can schedule gateway-restart cron job that kills its own runtime, creating respawn loop with launchctl/systemd KeepAlive #30719 cron+KeepAlive respawn loop could re-occur

The PR body also references a companion "macOS via_service race fix" that is "incoming" — another dependency that isn't merged yet.

Suggestion: ensure #35668 (and the macOS race fix companion) merge before this PR, or add a runtime check that raises an error if the guard is removed but KeepAlive is still conditional. The simpler path is just ordering the merges correctly.

[austinpickett]

Review notes — companion PR context

This PR removes the _HERMES_GATEWAY blanket guard for stop and restart — the guard from #30719 that prevents agent-initiated kill loops. The removal is correct in principle: the guard inadvertently blocked legitimate in-chat restart commands (WeChat, Telegram, etc.), forcing users to SSH in.

However: this PR is a strict subset of #37063 (same author). That PR does both:

1. Removes the same blanket guard (this PR's change)
2. Adds via_service=True routing on macOS/Darwin in gateway/run.py — which is the actual fix for the launchd KeepAlive race that the guard was protecting against
3. Improves WeChat _is_stale_session_ret for ret=-3 edge cases

Recommendation: Close this PR in favor of #37063. The guard removal without the via_service fix still leaves macOS launchd users exposed to the KeepAlive respawn race. #37063 is the complete fix.

Tagging needs-decision is appropriate — maintainer should confirm which PR to proceed with.

[austinpickett]

Closing in favor of #37063 (same author), which includes this change plus the macOS fix and WeChat stale-session improvements — the complete fix.