Description

After triggering a gateway restart via config.patch (which sends SIGUSR1), subsequent messages fail with a session lock timeout error, even after waiting several minutes.

Error Message

⚠️ Agent failed before reply: session file locked (timeout 10000ms): pid=7 /home/node/.clawdbot/agents/main/sessions/733c3170-7f20-4cc7-b1ed-24a265d8e18b.jsonl.lock

Environment

• Clawdbot version: 2026.1.24-0
• Deployment: Docker container (docker compose)
• Filesystem: ext4 (local, not network storage)
• OS: Linux 6.8.0-90-generic (x64)
• Node: v22.22.0

Steps to Reproduce

1. Have an active session with the agent
2. Trigger a config change via gateway tool with action: config.patch
3. This sends SIGUSR1 to the gateway process (PID 7 in container)
4. Wait 10+ seconds (we tested with 7 minutes)
5. Send a message to the agent
6. Error: session file locked

Observed Behavior

• Lock file exists at /home/node/.clawdbot/agents/main/sessions/<session-id>.jsonl.lock
• Lock file contains {"pid": 7, "createdAt": "..."}
• Gateway process IS running as PID 7
• Lock timeout (10000ms) is hit despite the owning process being alive

Expected Behavior

After SIGUSR1 graceful restart completes, the session should be accessible without lock errors.

Workaround

Manual recovery:

docker compose stop clawdbot-gateway
rm -f /path/to/.clawdbot/agents/main/sessions/*.lock
docker compose start clawdbot-gateway

Additional Context

• The PID stays the same (7) during SIGUSR1 in-place reload
• The issue happens consistently on every config.patch restart
• Adding stop_grace_period: 30s to docker-compose.yml did not help
• This is NOT a timing issue — 7 minute wait still fails

Hypothesis

During SIGUSR1 graceful restart, the session lock is not being properly released and re-acquired. The lock file persists with the correct PID, but something in the reload sequence leaves it in a stuck state.