Bug type

Behavior bug (incorrect output/state without crash)

Beta release blocker

No

Summary

When an agent run fails abnormally during tool execution (e.g., tool result lost triggering synthetic transcript repair), the session write-lock remains held in memory. The watchdog's force-release threshold inherits the full maxHoldMs (up to 17 minutes for a 15-minute agent timeout), causing all subsequent requests to the same session to fail with SessionWriteLockTimeoutError until the watchdog fires or the lock file is manually deleted.

Steps to reproduce

1. Configure an agent with timeoutSeconds >= 900 (results in maxHoldMs = 1,020,000ms)
2. Start an agent run that executes a tool (e.g., exec)
3. Trigger a tool failure that causes the run to abort without completing cleanup (e.g., command not found → tool result lost → synthetic transcript repair)
4. While the lock is still held, send a new message to the same session
5. Observe: session file locked (timeout 60000ms) error
6. Repeat step 4 — the error persists for up to 17 minutes

Expected behavior

Lock released shortly after run terminates (within 60 seconds at most). Subsequent messages to the session should be processed normally.

Actual behavior

The session remains completely unresponsive. All new messages return:

session file locked (timeout 60000ms): pid=96661 alive=true ageMs=72859

The lock file persists on disk with maxHoldMs: 1020000. The session can only recover by:

• Manually deleting the .lock file
• Waiting 17 minutes for the watchdog to fire
• Restarting the gateway process

OpenClaw version

Latest main (commit 8f29862, 2026-07-06)

Operating system

macOS 15.3 (Apple Silicon)

Install method

ClawX desktop app (pnpm dev equivalent)

Model

anthropic/claude-sonnet-4

Provider / routing chain

openclaw -> anthropic

Additional provider/model setup details

No response

Logs

session file locked (timeout 60000ms): pid=96661 alive=true ageMs=72859 /Users/user/.openclaw/agents/agent-name/sessions/5e85bf59-6039-4d86-bdd3-4332dfabf8f1.jsonl.lock

Screenshots, recordings, and evidence

Lock file contents:

{"pid":96661,"createdAt":"2026-07-06T09:32:20.160Z","maxHoldMs":1020000}

The pid (96661) is the running gateway process itself. The lock was created 7 minutes before manual intervention.

Session history shows:

• [openclaw] missing tool result in session history; inserted synthetic error result for transcript repair
• Three consecutive session file locked failures on new messages

Impact and severity

• Affected: Any user with agent timeout > 5 minutes whose run terminates abnormally
• Severity: High — completely blocks all interaction with the affected session
• Frequency: Reproducible when the trigger conditions are met (tool failure during long-timeout run)
• Consequence: Session becomes unusable; only workaround is manual .lock file deletion or 17-minute wait

Additional information

Root cause analysis:

The lock remains in SESSION_LOCKS.heldEntries() (in-memory Map) after the run terminates abnormally. Because heldByThisProcess = true, the orphan-self-pid stale detection is skipped. The only remaining cleanup path is the watchdog timer, which uses maxHoldMs directly (derived from agent timeout + 120s grace).

The existing REPORT_ONLY_STALE_LOCK_REASONS set (too-old, hold-exceeded) prevents acquirer-side cleanup when the pid is alive, which is correct for cross-process scenarios but creates a deadlock when the same process holds a stale lock.

Fix PR: #100870