Problem Statement

Autonomous reminder sessions that encounter blocking errors (e.g., file access denied, shell trust zone violation) degrade gracefully and stop calling tools — but never send an explicit "session complete" signal. The daemon marks them as permanently "active," which blocks all subsequent reminder executions via the duplicate-execution guard.

The daemon has no session timeout mechanism. Once stuck, the reminder is blocked indefinitely.

Root Cause

The daemon's SessionManager tracks active sessions per reminder ID. When a reminder fires, it checks if a session with the same reminder ID is already running. If yes, it skips execution and logs reminder_skipped_duplicate_execution.

The stuck session cannot be cleaned up through normal reminder management — it requires either force-terminating the session or redesigning the duplicate guard logic.

When the agent hits blocking errors (trust zone violations, file access denied, API errors), it degrades gracefully and stops calling tools, but the daemon never receives the explicit "I'm done" signal. The session stays marked as "active" forever, blocking every subsequent reminder fire.

Reproduction

Configuration

Session runs under Personal audience with GlobalReadRoots including {workspaces_dir}:

{
  "Tools": {
    "GlobalReadRoots": ["{skills_dir}", "{identity_dir}", "{workspaces_dir}"]
  },
  "Workspaces": {
    "Directory": "/home/netclaw/.netclaw/workspaces"
  }
}

Steps

1. Create a reminder with an autonomous session that needs to read/write files outside its session directory (e.g., a dedup state file in /workspaces/).
2. The autonomous session cannot access {workspaces_dir} due to the trust zone bug (tracked separately).
3. Agent hits errors like:
   • Error: autonomous session may only access files inside its session directory, project directory, or configured autonomous roots.
   • Tool access denied: shell_path_outside_trust_zone
4. Agent degrades gracefully — stops calling tools, uses MCP tools as fallback — but never sends a completion signal.
5. Daemon marks session as "active" and never clears it.
6. Every subsequent reminder fire produces: reminder_skipped_duplicate_execution reminder_id=<id>

Evidence from live execution (June 25, 2026)

• 49 duplicate skip events logged on a single day
• Only ONE session directory existed for the reminder
• Even recreating the reminder with a fresh ID reproduced the exact same hang-and-block pattern, proving this is a systematic daemon lifecycle bug, not a one-off session glitch

Impact

1. Permanent blocking: Once a session is stuck, the reminder is blocked indefinitely. The only workaround is to cancel and recreate the reminder — and even that doesn't help.
2. No automatic recovery: The daemon has no mechanism to detect and clean up stale sessions.
3. Silent failure: The reminder fires but does nothing. There is no error reported to operators — only a warning in daemon logs.
4. Affects ALL autonomous reminders: Any reminder that needs to read/write files outside the session directory will fail or degrade gracefully.

Session Directory Structure

Only one session directory exists per reminder ID:

reminder_<reminder_id>_<timestamp>

The daemon keeps this directory and marks it "active" until it receives a clean termination signal.

Recommended Fixes

Short-term

• Add automatic session timeout (e.g., kill sessions older than 30 minutes)
• Add a force-terminate command or API endpoint to cancel stuck sessions
• Create a daily check that detects and alerts on stuck sessions

Long-term

• Redesign the duplicate guard to use per-reminder timestamps instead of session IDs
• Add heartbeat/keep-alive mechanism so sessions that stall are automatically detected and terminated
• Implement a "stale session" detector that cleans up sessions that haven't sent heartbeats in >X minutes
• Add proper session lifecycle management (create → active → complete → cleanup) with error handling at each stage

Related

• Duplicate guard implementation: SessionManager / ReminderExecutionActor
• See related: Bug: Session-scoped reminders hang 1h when Discord reply fails #1372, Bug: Session-scoped reminders hang 1h when Mattermost reply fails #1373 (session-scoped reminders hang on delivery failure — same class of problem: session never properly terminates)