Codex review: needs maintainer review before merge. Reviewed June 29, 2026, 8:00 AM ET / 12:00 UTC.

Summary
The PR adds allowReentrant: true to direct embedded compaction's session write-lock acquisition and adds a small guard test for that lock call.

PR surface: Source +5, Tests +16. Total +21 across 2 files.

Reproducibility: yes. at source level. Current main routes overflow recovery into direct compaction, direct compaction acquires the session lock without allowReentrant, and the lock helper only re-enters when the option is explicitly true; I did not run the long live overflow scenario in this read-only review.

Review metrics: 1 noteworthy metric.

• Session lock opt-ins: 1 added, 0 removed. The runtime change deliberately adds one reentrant transcript lock acquisition, which is the semantic boundary maintainers need to review before merge.

Stored data model
Persistent data-model change detected: serialized state: src/agents/embedded-agent-runner/compact-lock.test.ts. Confirm migration or upgrade compatibility proof before merge.

Merge readiness
Overall: 🐚 platinum hermit
Proof: 🦞 diamond lobster
Patch quality: 🐚 platinum hermit
Result: ready for maintainer review.

Overall follows the weaker of proof and patch quality, so missing proof can cap an otherwise strong patch.

Rank-up moves:

• [P2] Have a maintainer explicitly accept the direct compaction same-logical-writer boundary before merge.
• Consider replacing the source-string guard with behavior-level nested-lock coverage if maintainers want stronger regression proof.

Risk before merge

• [P1] Merging changes one direct compaction transcript lock acquisition to re-enter a same-process held lock; if this path is not always the same logical writer, it could hide a real session mutation boundary.
• [P1] The added regression guard is source-string based rather than behavior-level nested-lock coverage, so maintainer confidence still depends on the live proof and the boundary rationale.
• [P1] Broader same-pid inner-writer lock sites remain tracked separately, especially fix(session-lock): allow reentrant acquire from inner transcript writers #96000 and [P0] Feishu connector: sequential queue deadlock + self-talk feedback loop under slow LLM #90559, so this PR should not be treated as the whole cluster fix.

Maintainer options:

1. Accept Direct Compaction Reentry (recommended)
   Land the narrow opt-in if maintainers agree direct preflight and overflow compaction are part of the same logical session writer.
2. Strengthen Lock Behavior Coverage
   Before merge, add a focused behavior test proving nested same-process direct compaction lock acquisition succeeds only for the intended same-writer path.
3. Pause For Broader Lock Policy
   Hold this PR if maintainers want one owner-led decision covering direct compaction plus the other inner transcript writer sites.

Next step before merge

• Maintainer review should decide the same-logical-writer boundary and whether to land this narrow PR versus waiting for broader inner-writer work.

Security
Cleared: No security or supply-chain concern was found; the diff only changes a TypeScript session-lock option and adds a focused test.

👍 Confirming + widening the scope (Feishu channel, 6.5.0)

Hi @plexustech2006 — I hit the same root cause on 2026-06-11 in the Feishu channel (not just Telegram), so I want to confirm this is a broader issue and offer a slightly wider surface for the fix.

Repro context

• Version: OpenClaw 2026.6.5 (commit 5181e4f), installed via npm install -g openclaw
• Channel: Feishu DM (default), one long-lived session agent:main:feishu:direct:<open_id>
• Workload: long-running sub-agent orchestration — main agent frequently spawns child agents that write to the same parent session file
• Symptom: ~33 occurrences of SessionWriteLockTimeoutError ... session file locked (timeout=60000ms): pid=<gateway> alive=true in 24h, correlated with eventLoopDelayP99Ms=14000+ and gateway CPU at 100% spinning on the lock wait

Wider surface than just preflight compaction

While digging, I found the bug is not isolated to preflight compaction — proper-lockfile is invoked in 11 places in the bundled dist, all without allowReentrant: true:

dist/selection-But6hGR0.js        (3 self-calls in createEmbeddedAttemptSessionLockController!)
dist/attempt-execution-CgTGShuY.js
dist/run-attempt-DXkrH0fF.js
dist/transcript-hciCrqol.js
dist/transcript-rewrite-BCPGHqBo.js
dist/docker-Dxn37PTc.js
dist/tool-result-truncation-CSLN3t54.js
dist/compact-Dn5LqRdR.js
+ 3 more

selection-But6hGR0.js:6091-6097 is the most interesting one — createEmbeddedAttemptSessionLockController calls acquireLock() 3 times in the same function (heldLock = await acquireLock() on L6097, then acquireLock() again on L6141/L6310/L6359) before releasing the first lock. This is the textbook non-reentrant self-deadlock.

Suggestion

The fix may be better expressed as one of:

1. Default the wrapper to allowReentrant: true for in-process same-file acquisitions (matches the "logical writer" pattern), and only force false at the cross-process / IPC boundary
2. Or add an opt-in allowReentrant on all 11 call sites that match the same-process-writer pattern, plus a regression test asserting no site silently drops it

I just restarted the gateway (launchctl kickstart -k) to clear the immediate symptoms and will watch 6.5.0 closely. Happy to test this PR on a Feishu DM session if it helps unblock maintainer review — I can repro the deadlock reliably in under 30 min by triggering a slow sub-agent dispatch.

— 🛠️ Self-hosted on macOS 26.5.1, gateway pid 32929, fresh after restart

Behavioral proof from live production trajectory (embedded-agent-runner path, Claude Sonnet 4.6)

Adding observed evidence that supports the fix here, plus a priority note for maintainers.

What the trajectory shows:
During a session that drifted to overflow (June 17, trajectory 91f28c2c), the gateway log recorded 5 overflow compaction attempts. Cross-referencing the trajectory file against the gateway log confirms the alternating lock-contention pattern:

• Overflow #1 (15:20:09 EDT): no session.started in trajectory — lock held by the prior threshold compaction model call (still running). Gave up at 19:21:09.583Z, within 33ms of the threshold call's session.ended at 19:21:09.626Z.
• Overflow #2 (15:21:42): session.started + prompt.submitted → model.completed at 143s, aborted=False ✅ acquired lock, ran.
• Overflow #3 (15:23:05): no session.started — lock held by #2's still-running model call. Gave up within ~33ms of #2's session.ended.
• Overflow #4 (15:25:01): session.started + prompt.submitted → model.completed at 187s, aborted=False ✅ acquired lock, ran.
• Overflow #5 (15:27:08): no session.started — lock held by #4's still-running model call.

This is live behavioral confirmation of the same-process lock contention the PR addresses. The alternating pattern (every odd attempt hits contention, every even attempt gets through) directly results from the retry interval (~60s) being shorter than the model call duration (~143–187s). ClawSweeper noted "a behavior-level regression test would be stronger than the added source-string guard" — this is that behavioral data from production.

Priority note for maintainers:
The allowReentrant: true fix here is correct and worth landing. However, it's downstream of a separate primary bug: COMPACTION_RETRY_AGGREGATE_TIMEOUT_MS = 6e4 in selection-Cy8dzQeR.js — the embedded session's outer wait — gives up after 60s regardless of call status. When that fires, the abandoned-but-still-running model call holds (or re-acquires) the lock for another 80–130s, and the next retry starts into contention. Fix the aggregate wait and the retry storm stops; the contention becomes rare rather than structural. The two fixes are independent but this one is secondary.

This pull request has been automatically marked as stale due to inactivity.
Please add updates or it will be closed.

Merged via squash.

• Prepared head SHA: 300d40902b16690eeca7d7e633e6b40a91069d8b
• Landed commit: a434ee7d3033f1f2d8cd84bcb93b567be3e8d8a1