with one click
activity-monitor
// Guardian service that monitors the active runtime agent's state and automatically restarts it if stopped. Use when checking agent liveness state or understanding the auto-restart mechanism.
// Guardian service that monitors the active runtime agent's state and automatically restarts it if stopped. Use when checking agent liveness state or understanding the auto-restart mechanism.
| name | activity-monitor |
| description | Guardian service that monitors the active runtime agent's state and automatically restarts it if stopped. Use when checking agent liveness state or understanding the auto-restart mechanism. |
| user-invocable | false |
PM2 guardian service that monitors the active runtime agent's (Claude or Codex) activity state and ensures it's always running.
This is a PM2 service (not directly invoked by Claude). It runs continuously in the background.
~/zylos/activity-monitor/agent-status.json with current state (busy/idle, idle_seconds, health)zylos config set daily_upgrade_enabled true){
"state": "idle",
"last_activity": 1738675200,
"last_check": 1738675210,
"last_check_human": "2026-02-04 20:30:10",
"idle_seconds": 5,
"inactive_seconds": 10,
"source": "conv_file",
"health": "ok"
}
state: "busy" | "idle" | "stopped" | "offline"idle_seconds: Time since entering idle state (0 when busy)source: "conv_file" (reliable) | "tmux_activity" (fallback)health: "ok" | "recovering" | "down" — liveness health from the heartbeat engine# Start
pm2 start ~/zylos/.claude/skills/activity-monitor/scripts/activity-monitor.js --name activity-monitor
# Restart
pm2 restart activity-monitor
# View logs
pm2 logs activity-monitor
# Check status
pm2 list
Monitor Loop (every 1s):
Guardian Logic:
Activity Detection:
The heartbeat engine runs inside the activity monitor and uses the C4 control queue to verify Claude is actually responsive (not just process-alive).
heartbeat interval elapsed
┌─────────────────────────────────────┐
│ ▼
│ ok ──[primary fails]──► ok (verify phase)
│ ▲ │
│ │ [verify fails]
│ │ ▼
│ │ recovering ──[recovery fails]──► recovering
│ │ │ │
│ │ [ack received] [max failures reached]
│ │ │ │
│ └──────────────────────────────┘ ▼
│ down
│ │
│ [ack received after manual fix]
└─────────────────────────────────────────────────────────────────┘
| Phase | Trigger | On Success | On Failure |
|---|---|---|---|
| Primary | Heartbeat interval elapsed (default 30min) | Reset timer, stay ok | Enter verify phase |
| Verify | Primary probe failed | Return to ok | Kill tmux, enter recovering |
| Recovery | In recovering state, Claude restarted | Return to ok | Kill tmux, retry (up to max) |
| Down | Max restart failures reached (default 3) | Return to ok | Stay down, wait for manual fix |
Each heartbeat probe is enqueued with an ack deadline. If Claude does not acknowledge the probe before the deadline expires, the control record transitions to timeout status and the engine treats it as a failure.
When health is not ok, C4 intake still records incoming messages as delivered. The MessageRouter returns an immediate status response for the current message when replies are enabled; --no-reply messages are accepted silently. If the router IPC is unavailable, c4-receive.js falls back to the status file and follows the same delivered/current-message behavior.
The activity monitor periodically enqueues system health checks via the C4 control queue.
~/zylos/activity-monitor/health-check-state.json (survives restarts)health === 'ok'The health check control message instructs Claude to:
pm2 jlistdf -hfree -m~/zylos/logs/health.logThe activity monitor enqueues a daily Claude Code upgrade via the C4 control queue.
zylos config set daily_upgrade_enabled trueDAILY_UPGRADE_HOUR)~/zylos/.env TZ field, falls back to process.env.TZ, then UTC~/zylos/activity-monitor/daily-upgrade-state.json (tracks last upgrade date)health === 'ok'daily_upgrade_enabled is true in configThe control message instructs Claude to use the upgrade-claude skill, which handles idle detection, /exit, upgrade, and automatic restart.
Event-driven context monitoring via Claude Code's statusLine feature, replacing the old hourly polling.
context-monitor.js runs as a statusLine command — Claude Code pipes context data to it via stdin after every turn (zero turn cost)~/zylos/activity-monitor/statusline.json with full context data (used_percentage, remaining_percentage, cost, session_id)70%, Codex default 75%, configurable via new_session_threshold / codex_new_session_threshold in config.json): Enqueues the new-session trigger. Priority 1, 5-minute cooldown./clear is gated by block-queue-until-idle in the new-session skill's final step~/zylos/activity-monitor/context-monitor.logThe early memory sync decouples memory sync from the session switch. Memory sync is also triggered by the new session's startup hook if unsummarized conversations exceed the threshold, so data is never lost.
The activity monitor runs a daily git commit of the memory/ directory.
~/zylos/.env TZ)~/zylos/activity-monitor/daily-memory-commit-state.jsonzylos-memory/scripts/daily-commit.js directly (no C4, no Claude needed)Both daily tasks (upgrade, memory commit) use the same DailySchedule class:
last_date === today) ensures exactly-once per day, even with imprecise timingWhen Claude Code shows a permission prompt (PermissionRequest event), the hook-auth-prompt.js hook automatically sends an Enter keystroke to approve it.
This is intentional by design. Zylos operates in a full-delegation model where the machine's permissions are entirely granted to the AI agent. Auto-approving permission prompts is the expected behavior, not a security gap.
hook-auth-prompt.js logs the event to hook-timing.logauto_approve_permission is true (default), it enqueues a [KEYSTROKE]Enter control at priority 0 with bypass-state and 1-second delay# Disable auto-approve (require manual confirmation)
zylos config set auto_approve_permission false
# Re-enable (default)
zylos config set auto_approve_permission true
Config key: auto_approve_permission in ~/.zylos/config.json (default: true).
Activity log: ~/zylos/activity-monitor/activity.log
[HINT] Download the complete skill directory including SKILL.md and all related files