hermes - 💡(How to fix) Fix [Bug, Windows] hermes gateway restart loses session context — planned_stop_marker not written before SIGTERM

Bug: Windows hermes gateway restart loses all session context — planned_stop_marker not written

Hermes Agent version: v0.13.0 (May 2026) Environment: Windows 10/11 + git-bash/MSYS2 (local install) Python version: 3.x Platform: Windows native, no WSL

Description

On Windows, running hermes gateway restart causes the agent to lose all conversation context permanently. After restart, the agent starts with a blank state — no memory of prior sessions, even though sessions.json exists on disk.

Root cause: gateway_windows.py calls stop() directly without writing the planned_stop_marker first. When schtasks /End sends a termination signal to the gateway process, it interprets the shutdown as unplanned (crash), skips the graceful drain, and does NOT set resume_pending=True in sessions.json. The next boot sees a clean session state.

Root Cause Analysis

In hermes_cli/gateway_windows.py, the restart() method:

python def restart(): stop() # ← sends SIGTERM without planned_stop_marker time.sleep(1.0) start()

Compare with the Unix implementation which uses SIGUSR1 to trigger drain. Windows has no equivalent signal, so schtasks /End sends a standard termination signal — which the gateway's shutdown handler sees as a crash, not a planned stop.

The gateway's run.py shutdown handler explicitly checks for the marker:

python consume_planned_stop_marker_for_self() # must return True for graceful drain if should_save: write_state(save_type='drain', ...) # sets resume_pending=True

Without the marker, should_save is False → no drain → context lost.

Reproduction Steps

1. Start Hermes gateway and have a multi-turn conversation
2. Run hermes gateway restart on Windows
3. After restart, ask the agent about something discussed before restart
4. Agent responds with no context of prior conversation

Expected Behavior

After hermes gateway restart, sessions with resume_pending=True in sessions.json should be restored. Agent context should survive restart.

Proposed Fix

In hermes_cli/gateway_windows.py, the restart() method must write the planned_stop_marker before sending the termination signal:

python def restart(self): pid = self._read_current_pid() if pid: write_marker = self._status_dir / f'{pid}.planned_stop.json' write_marker.write_text(json.dumps({...})) self._send_term_signal() # schtasks /End

# Wait for graceful drain (up to 35s)
for attempt in range(70):
    if not self._is_gateway_running():
        break
    time.sleep(0.5)
else:
    self._force_kill()     # fallback if drain exceeds timeout

self.start()

Full diff attached.

Impact

• Severity: High — breaks the "Sessions survive restarts" feature advertised in v0.13.0 changelog
• Affected users: Windows local installs (likely the majority of non-technical users on Windows)
• Workaround: Never use hermes gateway restart on Windows; restart the machine instead (which preserves sessions if gateway auto-starts)

Additional Context

• hermes gateway stop followed by hermes gateway start has the same issue
• Linux installs are NOT affected (SIGUSR1 works natively)
• The bug has existed since the planned_stop_marker feature was introduced
• No error is logged — the gateway simply "forgets" silently