OpenClaw Bug Report: Session Isolation Leak in Cron Jobs

Severity: HIGH (Security/Isolation Failure)
Component: Cron System / Session Management
Version: Affects versions with sessionTarget: "isolated" support (v2026.1.x+)

Summary

The sessionTarget: "isolated" configuration for cron jobs fails after extended runtime (~24+ hours), causing isolated session messages to leak into the main session. When combined with payload.kind: "agentTurn", this results in prompt injection payloads being delivered to the wrong agent.

Reproduction Steps

1. Create a cron job with sessionTarget: "isolated" and payload.kind: "agentTurn":

{
  "name": "test-isolated",
  "schedule": { "kind": "every", "everyMs": 1800000 },
  "sessionTarget": "isolated",
  "payload": {
    "kind": "agentTurn",
    "message": "REAPER_SESSION: You are Reaper, a market analysis agent...",
    "model": "anthropic/claude-haiku-4-5"
  },
  "delivery": { "mode": "announce" }
}

2. Let the job run for ~24+ hours (observed: ~165 successful isolated runs)

3. Observe that messages begin leaking to the main session instead of isolated sessions

Expected Behavior

• All cron runs with sessionTarget: "isolated" should execute in isolated sessions
• Messages should NEVER leak to the main session
• Agent identity prompts should remain contained within their isolated sessions

Actual Behavior

• After ~24 hours of operation, isolated session messages began leaking to main session
• ~5 injection payloads were delivered to the main agent (Oksana) over 4+ hours
• Payloads contained explicit identity override instructions ("You are Reaper...", "You are Sentinel...", etc.)
• This could allow privilege escalation if the main agent accepted the identity override

Timeline of Events (UTC)

Impact Analysis

Security Risk

• Prompt Injection: Identity override payloads could trick the main agent into assuming different personas
• Privilege Escalation: If accepted, agent could execute actions with different permissions/context
• Data Leakage: Isolated session data exposed to main session

Operational Risk

• Multi-agent systems relying on session isolation for security boundaries are compromised
• Cron-based agent coordination becomes unreliable
• User trust in isolation guarantees is undermined

Environment

• OS: Linux (Ubuntu 22.04)
• Node: v25.6.0
• OpenClaw: Latest stable (v2026.1.x)
• Deployment: Remote Gateway on VPS
• Configuration: 9 agent-specific cron jobs with isolated sessions

Root Cause Hypothesis

The session isolation mechanism appears to have a resource leak or state corruption that manifests after extended runtime:

1. Session pool exhaustion
2. Session ID collision after rollover
3. Isolation context being dropped/corrupted
4. WebSocket routing table degradation

The consistent ~24-hour timeframe suggests a garbage collection, connection pool reset, or similar periodic cleanup that breaks isolation context.

Mitigation Applied

• All 9 affected cron jobs deleted
• Migration to systemEvent payloads only (no agentTurn with identity)
• Manual agent coordination via sessions_spawn instead of cron-based identity switching

Suggested Fixes

1. Immediate: Add session isolation validation - verify target session before message delivery
2. Short-term: Implement session isolation health checks with automatic recovery
3. Long-term: Audit session lifecycle management for resource leaks

Related Documentation

• Cron Jobs - OpenClaw Docs
• Multi-Agent Routing
• Session Management

Reporter

JPP via Telegram @Perr00000
Agent: Oksana (Multi-agent squad lead)
Date: 2026-02-09

Attachments

• Cron job configuration examples (see Reproduction Steps)
• Session history showing leaked messages (available on request)