Bug Description

The gateway scoped-lock stale detection can treat a zombie gateway process as still owning a live platform lock. In a container/manual gateway setup, this prevented a new gateway instance from reconnecting Telegram and Slack after an interrupted/restarted gateway run.

Observed effect: a replacement gateway started only partially (webhook connected), while Telegram/Slack were refused because their scoped lock metadata pointed at an old PID that was already a zombie. Since zombie processes still have /proc/<pid> entries and os.kill(pid, 0) succeeds, the existing stale-lock check considered the lock live.

Environment

• Hermes Agent v0.12.0 (2026.4.30)
• Commit observed locally: f98b5d00a
• Python: 3.11.15
• Runtime: Linux container-style install, gateway run manually/nohup rather than systemd
• Affected file/function: gateway/status.py, acquire_scoped_lock(...)

Steps to Reproduce

1. Run the gateway with Telegram/Slack enabled.
2. Interrupt/restart the gateway in a way that leaves the old gateway PID as a zombie/defunct process.
3. Start a new gateway instance.
4. The new instance sees the old scoped lock owner PID. Because os.kill(pid, 0) succeeds for zombies, the lock is treated as active instead of stale.

I also reproduced the lock behavior locally by writing a scoped-lock file owned by a real zombie PID, then calling acquire_scoped_lock(...).

Expected Behavior

Scoped locks owned by zombie/dead gateway processes should be treated as stale, allowing the replacement gateway to reclaim Telegram/Slack locks and reconnect all platforms.

Actual Behavior

The old zombie PID was treated as a live lock owner. Telegram/Slack stayed disconnected until the stale lock files were removed manually.

Local Fix Tested

I patched the /proc/<pid>/status state check in acquire_scoped_lock(...) to treat zombie/dead process states as stale, not just stopped states:

- if _state in ("T", "t"):  # stopped or tracing stop
+ if _state in ("T", "t", "Z", "X", "x"):
      stale = True

With an expanded comment:

# Check if process is not actually runnable. Stopped processes
# (Ctrl+Z / SIGTSTP) and zombies still respond to
# os.kill(pid, 0), but they cannot own a live gateway
# connection. Treat both states as stale so replacement
# gateways can reclaim Telegram/Slack scoped locks after an
# interrupted restart.

Verification

Using the Hermes venv Python, because the system Python did not have all Hermes deps:

• py_compile passed for gateway/status.py
• Simulated scoped lock owned by zombie PID was reclaimed successfully:

acquire_with_zombie_lock_ok= True
existing_seen= False

• After a controlled gateway restart, all platforms connected again:

[Telegram] Connected to Telegram (polling mode)
✓ telegram connected
[Slack] Socket Mode connected
✓ slack connected
Gateway running with 3 platform(s)

Suggested Fix

Update acquire_scoped_lock(...) to treat non-runnable Linux /proc/<pid>/status states as stale, at minimum Z (zombie) in addition to the existing T/t stopped/traced states. Including X/x seems reasonable for dead processes if encountered.