openclaw - 💡(How to fix) Fix Session write lock stale warning leaks to tool stderr during parallel tool calls [1 pull requests]

Official PRs (…)
ON THIS PAGE

Recommended Tools

×6

Utilities matched from this issue’s tags and category — try them while you read without losing context.

GitHub issue graph ai analysis

Paste a GitHub issue URL. We fetch that issue, discover linked issues from bodies/comments/timeline, collect linked pull requests, and produce a structured English report.

The report is written in English Markdown for sharing and archival.

Helpful · Quick feedback

Loading…

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.

Error Message

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. 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. Appears in tool call stderr, causing confusion (looks like a real error). 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. 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.

Root Cause

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.

Fix Action

Fixed

Code Example

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

---

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

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

Vote matrix · Quick signals

Works
Did the solution work? Tap to confirm.
Easy Fix
Was it a quick fix?
Time Saver
Did it save you time?
Blocking
Was it severely blocking?
Common Issue
Are others likely hitting this too?
Flaky / Intermittent
Is it intermittent?
Verified / Reproducible
Can you reproduce it reliably?
Loading…

Still need to ship something?

×6

Another batch ranked right after the header list — different links, same matching logic.

Back to top recommendations

TRENDING

openclaw - 💡(How to fix) Fix Session write lock stale warning leaks to tool stderr during parallel tool calls [1 pull requests]