Summary

During parallel tool calls within a single agent turn, concurrent session journal writes cause file_lock_stale errors to leak into tool stderr output. The error is caught and recovered internally by acquireSessionWriteLock (it removes the stale lock and retries via continue), but the throw from the sidecar-lock layer produces visible stderr noise that appears in tool call results.

Reproduction

1. Run an agent with parallel tool calls enabled (default behavior)
2. Have 2+ tool calls execute simultaneously that both write to the session journal
3. Observe file lock stale for /path/to/session.jsonl in stderr of tool results

Expected Behavior

The caught-and-recovered stale lock detection should not leak error messages to tool output. The retry succeeds silently, so the warning provides no actionable information to the user or agent.

Actual Behavior

file lock stale for /home/user/.openclaw/agents/agent-name/sessions/uuid.jsonl

Appears in tool call stderr, causing confusion (looks like a real error).

Analysis

In session-write-lock-DSJ9Py-M.js, acquireSessionWriteLock catches file_lock_stale errors from the sidecar-lock layer and handles them:

} catch (err) {
    if (isFileLockError(err, "file_lock_stale")) {
        if (await removeReportedStaleLockIfStillStale({...})) continue; // retry
    }
}

The issue is that sidecar-lock-Bv7C32CP.js throws the error with new Error(\file lock stale for ${normalizedTargetPath}`)`, and this throw gets captured by the process stderr before the catch handler runs.

Suggested Fix

Either suppress the error message in the sidecar-lock layer when it's an expected concurrent-access case, or filter file_lock_stale messages from tool output at the exec/tool-result layer.

Environment

• OpenClaw version: 2026.5.20
• OS: Ubuntu 26.04 LTS
• Node: v24.15.0