Bug Description

When the gateway process is running and holding a session lock on an agent (e.g., main), CLI commands like clawdbot agent --agent main --message "..." fail with a session lock timeout error, even though conceptually the gateway and CLI should be able to coordinate or the gateway should spawn isolated subagent processes.

Reproduction Steps

1. Start the gateway (which holds lock on main agent session)
2. Attempt to send a message via CLI:

   clawdbot agent --agent main --message "test message" --deliver

3. Observe timeout error

Error Output

Error: session file locked (timeout 10000ms): pid=32572 /Users/josephmalone/.clawdbot/agents/main/sessions/4c05bec6-xxxx.jsonl.lock

Environment

• Gateway running on ports 18789, 18791, 18792
• Multiple stale .lock files accumulating in ~/.clawdbot/agents/main/sessions/
• Lock files older than 30 minutes found (16 stale locks in one observation)

Expected Behavior

Either:

1. Gateway should release session locks when idle, allowing CLI commands to acquire them
2. Gateway and CLI should coordinate via IPC to share session access
3. Subagents spawned by gateway should use isolated sessions (different session IDs) to avoid lock contention with the main gateway process

Proposed Fixes

1. Implement lock timeout/expiry: Auto-release locks after inactivity period
2. Session isolation for subagents: Ensure subagents get their own session files rather than contending for the main session
3. Lock-free message passing: Use a message queue or similar mechanism that doesn't require exclusive file locks
4. Cleanup daemon: Periodically clean stale lock files (workaround: find ~/.clawdbot/agents/main/sessions -name "*.lock" -mmin +30 -delete)

Workaround

Currently using WhatsApp message channel which bypasses the session lock:

clawdbot message send --channel whatsapp --target '+1XXXXXXXXXX' --message 'message here'

This works but loses the agent context and conversation threading.