[Bug]: Weixin gateway death loop after upgrade — open policy without ALLOW_ALL_USERS opt-in

[mlc622]

Bug Description

After upgrading Hermes Agent from a previous version to v0.18.0, the gateway enters an infinite crash-restart loop when the Weixin platform has dm_policy or group_policy set to open but neither WEIXIN_ALLOW_ALL_USERS nor GATEWAY_ALLOW_ALL_USERS is enabled. Each cycle: gateway starts → fails the safety check → exits → systemd restarts → repeat. The restart counter reached 1705 before the issue was manually diagnosed.

Steps to Reproduce

1. Configure weixin platform with WEIXIN_DM_POLICY=open in .env (no WEIXIN_ALLOW_ALL_USERS)
2. Start gateway via hermes gateway start or systemd service
3. Gateway exits immediately and systemd restarts it in a loop

Expected Behavior

One of:

• Gateway should start successfully (config was valid in the previous version), or
• Gateway should exit with an actionable error message telling the user how to fix it, and not restart in a loop

Actual Behavior

Gateway enters an infinite crash-restart loop. systemd counter exceeded 1700. The error message states the problem but does not suggest the fix:

ERROR gateway.run: Refusing to start: weixin has dm_policy/group_policy set to "open" but neither GATEWAY_ALLOW_ALL_USERS nor WEIXIN_ALLOW_ALL_USERS is enabled.
ERROR gateway.run: Gateway exiting cleanly: weixin: open policy without allow-all opt-in

Systemd journal:

hermes-gateway.service: Scheduled restart job, restart counter is at 1702.
hermes-gateway.service: Scheduled restart job, restart counter is at 1703.

Affected Component

Gateway (WeChat/Weixin platform adapter)

Environment

• OS: Linux (Ubuntu)
• Python: 3.11.15
• Hermes Version: v0.18.0 (2026.7.1, commit 63354ed)

Root Cause Analysis

The gateway startup validation in gateway/run.py enforces that open DM/group policies must be paired with an explicit ALLOW_ALL_USERS opt-in. This is a sensible safety check, but:

1. No backward compatibility — configs valid in the previous version break silently after upgrade
2. The error message does not tell the user how to resolve it (e.g. "set WEIXIN_ALLOW_ALL_USERS=true or change dm_policy to pairing")
3. Immediate exit on this check triggers a systemd restart loop (exponential backoff notwithstanding, still 1700+ cycles overnight)

Suggested Fix

1. Add an upgrade migration or startup warning that detects the incompatible config before the hard exit
2. Improve the error message to include resolution steps
3. Consider whether exiting on a config validation error is the right behavior (vs. skipping the platform with a warning log)

[GottZ]

This was generated by AI during triage.

Summary

Two PRs are associated with #57474: #57487 directly improves the fatal open-policy path and its diagnostic but does not yet stop the generated systemd units from restarting, while #60329 extends the gate to Feishu and does not address the reported Weixin restart loop.

Related pull requests

• fix(gateway): set fatal exit code on open-policy violation to prevent death loop #57487 best fix — (+42/-2) — partial fix / best consolidation target: The diff sets exit code 78 for the Weixin open-policy violation, adds actionable remediation text, and tests that contract, but it does not modify the generated systemd units using Restart=always. Consistent with the keep_open review on fix(gateway): set fatal exit code on open-policy violation to prevent death loop #57487, add RestartPreventExitStatus=78 to both unit templates with regression coverage before merging.
• fix(gateway): add Feishu to the own-policy open-startup fail-closed gate #60329 [closed] unrelated — (+100/-0) — unrelated, closed but relevant as a rejected alternative scope: The diff adds Feishu policy detection rather than fixing Weixin's service restart behavior. Despite the COMMENTED keep_open review on fix(gateway): add Feishu to the own-policy open-startup fail-closed gate #60329, the subsequent contributor re-verification explains why closure is appropriate: Feishu does not own access policy, so central authorization still applies and the proposed startup gate rests on a false equivalence.

Suggested consolidation

Consolidate and, after completing the systemd-unit fix identified by the keep_open review, merge #57487 as the direct fix for #57474; keep #60329 closed because its Feishu-specific change neither fixes the Weixin death loop nor models Feishu's authorization boundary correctly.

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

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 or no verify verdict yet (state tag in the node label).

Cross-PR triage: Reviewed 2 pull requests and 1 issue in this complex. Each diff was read against this issue; Assessment working set: 9 kB of PR diffs, 6 kB of issue/PR text, 4 kB of discussion (3 comments), 3 verify verdicts. verdicts reflect diff content, not PR titles. Part of an automated triage batch.

[luccapinto]

Confirming this on WhatsApp, not just Weixin/iLink — the gate is transport-agnostic, so the trigger is too.

Two details from my case that I think sharpen the diagnosis:

1. The offending platform did not need to be functional. My WhatsApp channel had been logged out since 2026-07-04 — device_removed, stream error 401, no creds.json on disk. It could not have accepted a message under any policy. But WHATSAPP_ENABLED=true plus a stale dm_policy: open from an earlier setup was enough to trip the gate, because _own_policy_open_startup_violation() only inspects platform_config.enabled and never asks whether the platform can connect. A dead transport held the whole gateway hostage for 25 days' worth of config drift.

2. The collateral damage is total, not partial. The gate calls _request_clean_exit(), so my Telegram bot — correctly configured with TELEGRAM_ALLOWED_USERS, nothing to do with the violated policy — never connected. Combined with the shipped systemd unit (Restart=always, StartLimitIntervalSec=0) this became an indefinite crash loop:

ERROR gateway.run: Refusing to start: whatsapp has dm_policy/group_policy set to 'open'
                   but neither GATEWAY_ALLOW_ALL_USERS nor WHATSAPP_ALLOW_ALL_USERS is enabled.
ERROR gateway.run: Gateway exiting cleanly: whatsapp: open policy without allow-all opt-in
systemd[1714]: hermes-gateway.service: Scheduled restart job, restart counter is at 188.

188 restarts in one hour, ~2s CPU and ~115 MB peak per attempt. From the user's side the only symptom was "the agent stopped replying on Telegram" — the actual cause was one line about a different platform.

Worth noting the guard itself is right; I would not want an open-policy platform silently accepting traffic. It is the scope of the consequence that seems off: disabling the offending platform is still fail-closed for that platform, without taking down transports that were configured correctly.

I opened #74440 taking that approach transport-agnostically, so it covers weixin/iLink/wecom/qqbot/whatsapp in one path rather than exempting platforms one at a time. It keeps _own_policy_open_startup_violation() unchanged for the per-profile multiplex path, where aborting just that profile is already the right scope, and still refuses to start when every enabled platform fails the gate. Note #62641 already addresses this by exempting Weixin specifically — happy to defer to whichever direction maintainers prefer.

Environment: Ubuntu 26.04, systemd 259, Hermes v2026.7.20-2615-g41a07f5b84.