PR #16423: fix(gateway): detect stale scoped locks via cmdline when start_time is absent

• Repository: NousResearch/hermes-agent
• Author: vominh1919
• State: open | merged: False
• Link: https://github.com/NousResearch/hermes-agent/pull/16423

Description (problem / solution / changelog)

Problem

On macOS, _get_process_start_time() always returns None because /proc doesn't exist. When a scoped lock record also has start_time=None (legacy locks or locks written on macOS), the staleness check in acquire_scoped_lock() is inconclusive — it cannot determine whether the PID was reused by an unrelated process.

From #16376: The recorded PID in the Telegram scoped lock had been reused by an unrelated macOS application (UURemote.app). Since the PID was alive and the start_time check was inconclusive, Hermes refused to start the Telegram adapter.

Fix

After the start_time comparison, add a fallback that checks whether the live PID still looks like a Hermes gateway via _looks_like_gateway_process(). Two cases:

1. Lock record has gateway metadata (kind == "gateway") but the live process is NOT a gateway → stale (PID reused)
2. Lock record lacks metadata (legacy) AND the live process is NOT a gateway → stale (safe assumption — if it were a gateway, cmdline would match)

If the live process IS a gateway (cmdline matches), the lock is valid regardless of metadata presence — this handles legacy locks from older versions.

Fixes #16376

Changed files

• gateway/status.py (modified, +14/-0)

PR #16432: fix(gateway): detect stale scoped lock when PID is reused on macOS (#16376)

• Repository: NousResearch/hermes-agent
• Author: Bartok9
• State: open | merged: False
• Link: https://github.com/NousResearch/hermes-agent/pull/16432

Description (problem / solution / changelog)

What does this PR do?

Fixes #16376 — stale Telegram bot token lock blocks gateway startup on macOS when the recorded PID is reused by an unrelated process.

Problem

On macOS, the scoped lock system could not verify process identity because:

1. _get_process_start_time() only reads /proc/<pid>/stat — unavailable on macOS → returns None
2. _read_process_cmdline() only reads /proc/<pid>/cmdline — unavailable on macOS → returns None
3. The stopped-process check (/proc/<pid>/status for State: T) also fails on macOS

This means:

• Lock files written on macOS have start_time: null
• When checking a lock, _get_process_start_time(existing_pid) returns None
• The start_time comparison existing["start_time"] != current_start is skipped when both are None
• If macOS reuses the PID for an unrelated app (e.g. UURemote.app), os.kill(pid, 0) succeeds
• Gateway treats the lock as active and refuses to start

Fix (three parts)

1. _get_process_start_time() — falls back to ps -o lstart= -p <pid> on macOS/BSD, parsing the human-readable timestamp to epoch seconds. Makes start_time available on all platforms.

2. _read_process_cmdline() — falls back to ps -o command= -p <pid> on macOS/BSD. Makes command-line inspection available on all platforms.

3. Stale lock detection for null start_time — when both the stored and live start_time are None (edge case where ps also fails), the code now checks the live process command line. If it does not contain "hermes", the lock is treated as stale. This prevents unrelated macOS processes from blocking the Telegram adapter.

Tests

All 35 existing tests pass without modification.

2 new tests added in TestScopedLocks:

• test_acquire_scoped_lock_stale_when_pid_reused_null_start_time — simulates the exact macOS scenario from the issue: PID 574 reused by UURemote.app, both start times None, cmdline is not hermes → lock stale, acquisition succeeds
• test_acquire_scoped_lock_keeps_lock_when_pid_reused_is_hermes — when the reused PID IS a hermes process (rare), the lock is correctly preserved

Labels: type/bug, comp/gateway, platform/telegram, P2

Changed files

• gateway/status.py (modified, +62/-8)
• tests/gateway/test_status.py (modified, +62/-0)