PR #84046: fix(agents): stop false-positive session-takeover on runner's own transcript appends

• Repository: openclaw/openclaw
• Author: kays0x
• State: open | merged: False
• Link: https://github.com/openclaw/openclaw/pull/84046

Description (problem / solution / changelog)

Summary

The embedded attempt session-lock fence uses a stat()-based fingerprint (dev, ino, size, mtimeNs, ctimeNs, birthtimeNs) to detect "another lane queued a new user turn against this session" while the runner releases its coarse lock for the LLM prompt window. The fingerprint is a proxy that overfires: every transcript-append the runner itself performs during the released window (appendSessionTranscriptMessageLocked writes tool calls, tool results, and assistant replies via acquireSessionWriteLock(..., allowReentrant: true)) changes the file's size/mtimeNs/ctimeNs without going through refreshSessionFileFence. Long DM turns with tool calls then trip assertSessionFileFence and throw EmbeddedAttemptSessionTakeoverError after the reply has already been delivered, surfacing a misleading "Agent failed before reply" message on top of a successful turn.

Keep the stat fingerprint as the fast path. On mismatch, only tolerate the runner's append-only assistant/tool transcript shape; treat everything else as a real takeover. The verification requires ALL of:

• dev/ino match: no atomic replacement onto a new inode.
• birthtimeNs matches: catches the unlink+recreate-same-inode case (common on tmpfs/ext4 with rapid recreation, where dev and ino are reused but the inode itself is fresh).
• size grew: file is append-only between fence-set and assert.
• stat/read consistency: both snapshotSessionFileFence and verifyAppendOnlyRunnerOwnedExtension run a post-read stat and compare every fingerprint field (size, dev, ino, mtimeNs, ctimeNs, birthtimeNs) against the pre-read fingerprint. Any mismatch fails closed: the snapshot returns prefixHashHex: null (forces the next assertion to treat the file as taken over) and the slow path rejects directly. Catches the same-size in-place rewrite race where byte length alone would not detect drift.
• bytes [0, fenceSize) hash identical to the fenced prefix hash: no in-place rewrite of earlier transcript content.
• bytes [fenceSize, currentSize) are canonical session entries: every appended line must satisfy isSessionEntry from transcript-file-state.ts (record shape, type, id, parentId, timestamp, plus the per-type message-shape contract via isAgentMessage), with role narrowed to assistant, toolResult, or bashExecution. Non-object parsed values, user-role entries, custom entries, branch_summary entries, and any entry missing the outer base fields remain a real takeover signal.

Anything else (replacement, shrink, in-place rewrite at any size, new user turn, compaction, a malformed appended entry, a non-object tail value, or a stat/read inconsistency window) remains a real takeover. The fence snapshot captures the prefix SHA-256 alongside the fingerprint at releaseForPrompt and refreshSessionFileFence so the slow path can verify rigorously without keeping a file handle open.

The slow-path tail validation delegates to the canonical isSessionEntry whole-entry validator (now export-visible from transcript-file-state.ts, signature widened to unknown with an internal isRecord guard so non-record JSON values fail closed). No local mirror of the persisted message contract is maintained: if the upstream FileEntry/SessionEntry contract changes, the fence's accept-set tracks it automatically.

The nextSnapshot returned from a successful slow-path verification hashes the full new buffer (not the pre-fence prefix). Otherwise, when the guarded operation throws between assertSessionFileFence and refreshSessionFileFence, the stored snapshot would describe the new size but hold the old prefix hash, and the next legitimate runner append would false-positive on prefix-hash mismatch.

Lock-held invariant

Both snapshotSessionFileFence call sites run while the session write lock is held: releaseForPrompt (snapshot at L452 before lock.release() at L454) and refreshSessionFileFence (called inside withSessionWriteLock's runWithLock wrapped by activeWriteLock.run(lock, ...)). Canonical transcript writers (appendSessionTranscriptMessageLocked, migrateLinearTranscriptToParentLinked, ensureTranscriptHeader) all acquire that same lock. The stat/read consistency guard above is belt-and-suspenders for this invariant: it defends against multi-process scenarios (a second gateway against the same session file), an external editor, or an internal bug that bypasses the lock.

Closes #83436. Refs #83615 (this PR addresses the EmbeddedAttemptSessionTakeoverError surface; the issue also tracks unrelated kimi-k2.6 schema and DNS-fetch failures).

Real behavior proof

Behavior addressed: Embedded runner false-positive EmbeddedAttemptSessionTakeoverError fires after long Telegram DM turns whose reply was already delivered, surfacing a misleading "Agent failed before reply" message on top of a successful run.

Real environment tested: OpenClaw 2026.5.19-beta.1, Linux x86_64, Node 24.13.0. Long-running Telegram DM session against claude-opus-4-7 (~3.5 min turn with multiple exec and message tool calls), reproduced reliably before this patch. Production behavior probed via runtime-patched dist/selection-BpjGe-Y0.js carrying the same fix semantics, then long DM runs (41s to 122s) exercised through the Telegram channel post-restart.

Exact steps or command run after this patch:

node scripts/run-vitest.mjs src/agents/pi-embedded-runner/run/attempt.session-lock.test.ts src/agents/pi-embedded-runner/transcript-file-state.test.ts
CI=true pnpm check:changed --staged=false
openclaw gateway restart

Evidence after fix:

Pre-patch failure mode, redacted runtime log from gateway (/tmp/openclaw/openclaw-2026-05-19.log):

03:30:06.971  embedded run agent end: runId=bbd7d487 isError=false
03:30:07.008  embedded run prompt end: runId=bbd7d487 sessionId=<session-id> durationMs=217236
03:30:07.054  lane task error: lane=main durationMs=219867 error="EmbeddedAttemptSessionTakeoverError: session file changed while embedded prompt lock was released: /home/.../agents/main/sessions/<session-id>.jsonl"
03:30:07.071  Embedded agent failed before reply: session file changed while embedded prompt lock was released: /home/.../<session-id>.jsonl

Note isError=false at 03:30:06.971: the assistant turn and message tool delivery both succeeded, followed 47ms later by the takeover throw, surfacing as a misleading Telegram error on top of a delivered reply.

Post-patch behavior on the same gateway, four long DM runs after gateway restart at 03:46 EDT, every one delivering cleanly with zero takeover errors (redacted runtime log):

03:51:18  embedded run prompt end: runId=62395ffd  durationMs=122344  (no takeover)
03:52:39  embedded run prompt end: runId=67e21652  durationMs=41345   (no takeover)
04:05:05  embedded run prompt end: runId=a5994980  durationMs=101810  (no takeover)
04:07:34  embedded run prompt end: runId=a837440b  durationMs=94395   (no takeover)

The post-patch window contains only two "Embedded agent failed before reply" entries (at 04:05:06 and 04:07:35), both with cause LLM request timed out, unrelated to the takeover path. Zero SessionTakeoverError occurrences post-patch.

Observed result after fix: Existing acceptance test exercises all three runner-owned roles (assistant, toolResult, bashExecution) with their canonical persisted shapes. Rejection tests cover: another owner queueing a new user turn, a runner-owned role with malformed message contents, a runner-owned message entry missing its outer id, a non-message entry (e.g. custom/branch_summary/compaction), a tail line that parses to a non-object value (e.g. literal null), in-place rewrite (rejected via prefix hash mismatch), unlink+recreate-same-inode replacement (rejected via birthtimeNs mismatch), a same-size in-place rewrite landing during the snapshot's stat-to-read window (rejected via post-read re-stat), and the same race during the slow-path verification's read (rejected via the same guard). A fence-consistency test covers the post-throw path: after a guarded operation throws between assert and refresh, the next valid runner-owned append must not false-positive on prefix-hash mismatch. Targeted Vitest output:

Test Files  4 passed (4)
     Tests  82 passed (82)
  Duration  3.86s

check:changed --staged=false is clean across the full repo lane (lint, typecheck, import-cycles, dependency guards, build artifacts, security/quality lanes).

What was not tested: Multi-process write contention on the same sessionFile from a different gateway process (no test infrastructure for cross-process locks in this surface). The prefix-hash check is O(fenceSize) I/O per fence-set; in production sessions seen so far (~150 KB and below) this is sub-millisecond. Both snapshot producers do one extra fs.stat (sub-millisecond on local disk) to enforce the stat/read consistency guard.

Notes

• Adds three helpers near readSessionFileFingerprint: FenceSnapshot type, snapshotSessionFileFence (used at releaseForPrompt and refreshSessionFileFence), and verifyAppendOnlyRunnerOwnedExtension (used in the slow path of assertSessionFileFence). No new module-level dependencies beyond node:crypto's createHash.
• Replaces one piece of controller state (fenceFingerprint: SessionFileFingerprint | undefined) with fenceSnapshot: FenceSnapshot | undefined. No new long-lived resources (no held file handles).
• Exports isSessionEntry from transcript-file-state.ts so the fence's slow path can delegate the whole-entry contract to the canonical validator. The signature is widened to unknown with an internal isRecord guard; non-record JSON values fail closed at the canonical boundary instead of needing per-callsite type-shape checks. isAgentMessage is not exported (the fence reaches it transitively through isSessionEntry).

Changed files

• src/agents/pi-embedded-runner/run/attempt.session-lock.test.ts (modified, +297/-2)
• src/agents/pi-embedded-runner/run/attempt.session-lock.ts (modified, +168/-6)
• src/agents/pi-embedded-runner/transcript-file-state.ts (modified, +9/-13)

PR #84250: fix(agents): tolerate in-process session writes during prompt release

• Repository: openclaw/openclaw
• Author: tianxiaochannel-oss88
• State: open | merged: False
• Link: https://github.com/openclaw/openclaw/pull/84250

Description (problem / solution / changelog)

Summary

• Track exact same-process, lock-owned session-file fingerprints across embedded attempt controllers.
• Allow a released prompt attempt to refresh its fence when the current file fingerprint matches a later OpenClaw-owned locked write.
• Preserve fail-closed takeover detection for unowned external session-file changes.
• Require the pre-write fingerprint to already be trusted before publishing a new owned post-write fingerprint, so an external edit cannot be masked by a later locked append.
• Add regression coverage for two in-process controllers writing the same session file during a prompt-release window.

Root Cause

The embedded attempt session fence only compared the session file's filesystem fingerprint saved at releaseForPrompt() against the fingerprint observed after the prompt lock was reacquired. That correctly rejects unowned external edits, but it also rejects legitimate OpenClaw-managed writes from another same-process controller/attempt that acquired the session write lock while the first attempt was released for model I/O.

This matches the issue reports where same-session channel activity, reaction events, or queued session work can append to the transcript during the model call. The original attempt then returns, reacquires the lock, sees size/mtimeNs/ctimeNs changed, and throws EmbeddedAttemptSessionTakeoverError even though the write was owned by the same OpenClaw process and serialized by the session write lock.

The fix keeps the fingerprint fence, but makes it ownership-aware: OpenClaw records the exact post-write fingerprint for same-process locked writes only when the pre-write fingerprint is already trusted by the process. A released attempt only accepts the change when the current file fingerprint exactly equals a newer owned fingerprint; direct external edits, including external edits followed by a later locked append, still fail closed.

Fixes #84059.

Real behavior proof

• Behavior or issue addressed: A prompt-released embedded attempt no longer throws EmbeddedAttemptSessionTakeoverError when another same-process controller advances the same session file under the session write lock. External unowned file changes still throw.
• Real environment tested: Local patched OpenClaw checkout at 7008438d978c75a21e811df4e2dc041d9f9dfe71, macOS arm64, Node.js v24.15.0, real temp session files on the local filesystem, real OpenClaw acquireSessionWriteLock.
• Failing proof before fix: The new regression test was run before the implementation and failed with the reported error:

AssertionError: promise rejected "EmbeddedAttemptSessionTakeoverError: sess..." instead of resolving

Caused by: EmbeddedAttemptSessionTakeoverError: session file changed while embedded prompt lock was released: .../session.jsonl

• Exact steps or command run after this patch:

node --import tsx ../proof-embedded-session-lock-in-process.ts

• Evidence after fix:

OpenClaw proof checkout: /Users/tianxiao/Documents/Codex/2026-05-19/openclaw-message-tool-bug/openclaw-community
In-process locked write result: post-write-committed
In-process takeover detected: false
In-process session line count: 3
External direct write error: EmbeddedAttemptSessionTakeoverError: session file changed while embedded prompt lock was released: /var/folders/wv/szx379kx7r135_kzktxrrs680000gn/T/openclaw-session-lock-proof-Bfobcy/external-session.jsonl
External takeover detected: true
External session line count: 2
External plus locked write error: EmbeddedAttemptSessionTakeoverError: session file changed while embedded prompt lock was released: /var/folders/wv/szx379kx7r135_kzktxrrs680000gn/T/openclaw-session-lock-proof-Bfobcy/external-then-locked-session.jsonl
External plus locked takeover detected: true
External plus locked session line count: 3

• Observed result after fix: The in-process two-controller proof now commits the post-prompt write without setting takeover. The same proof then performs an unowned direct append on a separate session file, and that path still rejects with EmbeddedAttemptSessionTakeoverError and marks takeover. A third proof case performs an external direct append followed by a same-process locked append; the original released controller still rejects with EmbeddedAttemptSessionTakeoverError, proving the locked append does not launder the earlier external edit.
• What was not tested: I did not run a live Feishu, Slack, WebChat, or Discord channel smoke. The proof uses the embedded session-lock controller directly with real filesystem writes to reproduce the source-level race without sending live channel messages.

Tests

• node scripts/run-vitest.mjs src/agents/pi-embedded-runner/run/attempt.session-lock.test.ts
• node scripts/run-vitest.mjs src/agents/pi-embedded-runner/context-engine-maintenance.test.ts src/agents/pi-embedded-runner/transcript-rewrite.test.ts
• node scripts/run-vitest.mjs src/agents/pi-embedded-runner/google-prompt-cache.test.ts src/agents/model-fallback.test.ts src/agents/failover-error.test.ts
• node scripts/run-tsgo.mjs -p tsconfig.core.json --incremental --tsBuildInfoFile .artifacts/tsgo-cache/core.tsbuildinfo
• git diff --check

Changed files

• src/agents/pi-embedded-runner/run/attempt.session-lock.test.ts (modified, +105/-0)
• src/agents/pi-embedded-runner/run/attempt.session-lock.ts (modified, +136/-9)

PR #84288: fix(discord): avoid duplicate typing keepalive for tool replies

• Repository: openclaw/openclaw
• Author: dr00-eth
• State: open | merged: False
• Link: https://github.com/openclaw/openclaw/pull/84288

Description (problem / solution / changelog)

Summary

• Problem: message-tool-only Discord replies could refresh typing from two lifecycle owners, making Discord show stale multi-second "bot is typing" after the visible reply was already delivered.
• Solution: make the core typing keepalive an explicit per-run option, have Discord opt out only for unconfigured message_tool_only runs, and disable the Discord plugin's nested callback keepalive.
• What changed: added typingKeepalive?: boolean to reply options, kept shared reply typing periodic by default, pass typingKeepalive: false from Discord only when sourceReplyDeliveryMode === "message_tool_only" and no explicit typingMode is configured, and set the Discord channel callback keepalive interval to 0.
• What did NOT change (scope boundary): explicit agents.defaults.typingMode / session.typingMode continues to win, non-Discord channels keep the existing shared keepalive default unless they opt out, typing is not disabled by default, ack reactions are unchanged, and this does not add a Discord "stop typing" call because Discord does not expose one.

Motivation

• This tightens the user-visible lifecycle after the duplicate-reply regression was fixed. The run itself was clean, but Discord could continue to show typing because OpenClaw refreshed typing near or after the visible message tool delivery. That made it look as if a second response was still being generated even when the transcript showed no fallback or second assistant run.

Change Type (select all)

• Bug fix
• Feature
• Refactor required for the fix
• Docs
• Security hardening
• Chore/infra

Scope (select all touched areas)

• Gateway / orchestration
• Skills / tool execution
• Auth / tokens
• Memory / storage
• Integrations
• API / contracts
• UI / DX
• CI/CD / infra

Linked Issue/PR

• Related #84059
• Related #84250
• Related #76091
• This PR fixes a bug or regression

Real behavior proof (required for external PRs)

• Behavior or issue addressed: stale Discord typing after a successful message-tool-only visible reply.
• Real environment tested: macOS local OpenClaw v2026.5.18 gateway, Node v25.6.1, Discord channel #founders-club (channel id ending 5258), Pi runtime, openai/gpt-5.5, messages.groupChat.visibleReplies: "message_tool".
• Exact steps or command run after this patch:
  1. Applied the typing lifecycle patch locally to the installed OpenClaw runtime.
  2. Restarted the gateway.
  3. Sent Discord test messages in #founders-club.
  4. Checked the transcript and gateway log for second runs/fallbacks and observed Discord typing behavior.
• Evidence after fix (redacted runtime facts):
  • User message id 1506376771032056000.
  • One gpt-5.5 tool call at 2026-05-19T19:23:44.803Z.
  • One delivery mirror at 2026-05-19T19:23:45.823Z.
  • One successful message tool result at 2026-05-19T19:23:45.982Z with primary Discord message id 1506376839398952981.
  • Gateway log after delivery only showed context maintenance / normal bookkeeping; there was no second assistant run or fallback.
• Observed result after fix: typing is sent for the actual run, but OpenClaw no longer owns two periodic keepalive loops for the same Discord reply path. Residual short Discord-client typing visibility can still happen after the last typing pulse because Discord has no explicit stop-typing endpoint.
• What was not tested: full pnpm build && pnpm check && pnpm test; I ran focused validation for the touched auto-reply and Discord extension surfaces.
• Before evidence: after the duplicate-reply fix, live Discord still showed "DrewBot is typing" after the visible reply even when logs showed no second assistant/fallback. That pointed at typing lifecycle refresh, not duplicate generation.

Root Cause (if applicable)

• Root cause: default message-tool-only group replies start typing immediately, and Discord typing was being refreshed by both core reply typing and a Discord channel callback keepalive. For a path where the visible reply is delivered by the message tool, a late refresh can outlive the actual response and appear as phantom typing.
• Missing detection / guardrail: tests covered typing start/cleanup behavior generally, but not "send the first typing signal without a periodic keepalive" or "Discord channel callbacks should not start a nested typing keepalive."
• Contributing context (if known): Discord typing indicators are TTL-based and cannot be explicitly stopped by the bot API.

Regression Test Plan (if applicable)

• Coverage level that should have caught this:
  • Unit test
  • Seam / integration test
  • End-to-end test
  • Existing coverage already sufficient
• Target test or file:
  • src/auto-reply/reply/reply-utils.test.ts
  • extensions/discord/src/monitor/message-handler.process.test.ts
• Scenario the test should lock in: a typing controller can emit the first typing signal without periodic keepalive ticks; Discord processing does not start a nested callback keepalive; configured Discord typingMode preserves the core keepalive path.
• Why this is the smallest reliable guardrail: it verifies the exact lifecycle knobs that caused stale typing without relying on Discord client TTL timing.
• Existing test that already covers this (if any): none.
• If no new test is added, why not: N/A.

User-visible / Behavior Changes

• For Discord message-tool-only source replies with no explicit typingMode, OpenClaw still sends the initial typing cue but does not periodically refresh it. Explicitly configured typing behavior and non-Discord shared defaults are preserved.

Diagram (if applicable)

Before:
Discord source reply run -> core typing keepalive
                         -> Discord callback keepalive
                         -> visible message delivered -> typing may still be refreshed

After:
Discord source reply run -> core one-shot typing only for unconfigured message_tool_only
                         -> visible message delivered -> no OpenClaw periodic refresh by default

Security Impact (required)

• New permissions/capabilities? (Yes/No): No
• Secrets/tokens handling changed? (Yes/No): No
• New/changed network calls? (Yes/No): No
• Command/tool execution surface changed? (Yes/No): No
• Data access scope changed? (Yes/No): No
• If any Yes, explain risk + mitigation: N/A

Repro + Verification

Environment

• OS: macOS
• Runtime/container: local OpenClaw gateway, Node v25.6.1
• Model/provider: openai/gpt-5.5, Pi runtime
• Integration/channel (if any): Discord group/channel, message-tool-only visible replies
• Relevant config (redacted): messages.groupChat.visibleReplies: "message_tool", no explicit typingMode

Steps

1. Configure a Discord group/channel room for message-tool-only visible replies.
2. Trigger the agent in a group channel.
3. Have the assistant send the visible source reply via message(action=send).
4. Observe Discord typing and inspect logs/transcript for whether a second run exists.

Expected

• Typing starts for the real run.
• Visible reply sends once.
• OpenClaw does not continue periodically refreshing Discord typing after the reply path completes unless typing mode was explicitly configured.

Actual

• Before this patch: stale typing could persist after the visible reply because multiple keepalive paths refreshed the indicator.
• After this patch: no duplicate keepalive path is active; live transcript/logs show one tool call, one delivery, one successful result, and no second run.

Evidence

• Failing test/log before + passing after
• Trace/log snippets
• Screenshot/recording
• Perf numbers (if relevant)

Focused validation run on this branch:

git diff --check origin/main...HEAD
node scripts/run-vitest.mjs run --config test/vitest/vitest.auto-reply-reply.config.ts src/auto-reply/reply/reply-utils.test.ts src/auto-reply/reply/typing-persistence.test.ts
  Test Files  2 passed (2)
  Tests       73 passed (73)

node scripts/run-vitest.mjs run --config test/vitest/vitest.extension-discord.config.ts extensions/discord/src/monitor/message-handler.process.test.ts
  Test Files  1 passed (1)
  Tests       71 passed (71)

Human Verification (required)

• Verified scenarios: live Discord message-tool-only reply after local runtime patch; transcript/logs showed one assistant tool call, one delivery mirror, one successful tool result, and no second assistant/fallback.
• Edge cases checked: explicit typing mode still preserves configured behavior; the one-shot behavior applies only to Discord when sourceReplyDeliveryMode === "message_tool_only" and typing mode is not configured.
• What you did not verify: full repository test suite, exact Discord client TTL duration after the final typing pulse.

Review Conversations

• I replied to or resolved every bot review conversation I addressed in this PR.
• I left unresolved only the conversations that still need reviewer or maintainer judgment.

Compatibility / Migration

• Backward compatible? (Yes/No): Yes
• Config/env changes? (Yes/No): No
• Migration needed? (Yes/No): No
• If yes, exact upgrade steps: N/A

Risks and Mitigations

• Risk: Discord users who relied on unconfigured message-tool-only typing refreshing throughout very long runs may see fewer typing refreshes.
  • Mitigation: explicit agents.defaults.typingMode or session.typingMode continues to opt into configured behavior; non-Discord channels keep their existing shared keepalive default unless they explicitly opt out.

Changed files

• extensions/discord/src/monitor/message-handler.process.test.ts (modified, +55/-0)
• extensions/discord/src/monitor/message-handler.process.ts (modified, +6/-1)
• src/auto-reply/get-reply-options.types.ts (modified, +2/-0)
• src/auto-reply/reply/get-reply.ts (modified, +1/-0)
• src/auto-reply/reply/reply-utils.test.ts (modified, +32/-0)
• src/auto-reply/reply/typing.ts (modified, +6/-0)

PR #84289: fix(pi): keep message-tool delivery in session lock

• Repository: openclaw/openclaw
• Author: dr00-eth
• State: open | merged: False
• Link: https://github.com/openclaw/openclaw/pull/84289

Description (problem / solution / changelog)

Summary

• Problem: message-tool-only Discord replies could be delivered visibly, then the active Pi attempt treated the delivery-mirror transcript append as an external session takeover and aborted the tool result.
• Solution: route owned transcript appends through the active attempt's session write lock and mark only successful, actually delivered, in-channel message sends as terminal for message_tool_only source delivery.
• What changed: added an AsyncLocalStorage-owned transcript write context, wrapped Pi prompt execution in that context, locked delivery-mirror transcript appends when they match the active session, and added a narrow terminal hook for successful un-routed message(action=send) calls.
• What did NOT change (scope boundary): automatic source delivery, explicit cross-channel message sends, sessions_send, failed tool calls, dry-run or non-delivered sends, reactions, attachments, and non-send message actions are not made terminal.

Motivation

• This addresses the duplicate Discord reply / fallback failure observed after upgrading to v2026.5.18 in message-tool-only group rooms. The first gpt-5.5 attempt successfully sent the visible Discord message, but the local transcript mutation was later observed as an external takeover, causing the tool result to be recorded as aborted and the same input to be retried by fallback (gpt-5.4), which produced a second visible reply.

Change Type (select all)

• Bug fix
• Feature
• Refactor required for the fix
• Docs
• Security hardening
• Chore/infra

Scope (select all touched areas)

• Gateway / orchestration
• Skills / tool execution
• Auth / tokens
• Memory / storage
• Integrations
• API / contracts
• UI / DX
• CI/CD / infra

Linked Issue/PR

• Related #84059
• Related #84250
• Related #84288
• This PR fixes a bug or regression

Real behavior proof (required for external PRs)

• Behavior or issue addressed: duplicate Discord replies and model fallback after a successful message tool delivery in messages.groupChat.visibleReplies: "message_tool" mode.
• Real environment tested: macOS local OpenClaw v2026.5.18 gateway, Node v25.6.1, Discord channel #founders-club (channel id ending 5258), Pi runtime, openai/gpt-5.5 primary with openai/gpt-5.4 fallback.
• Exact steps or command run after this patch:
  1. Applied the patch locally to the installed OpenClaw runtime.
  2. Restarted the gateway.
  3. Sent a Discord reply that triggered DrewBot in #founders-club.
  4. Checked the session transcript and gateway log for tool delivery, delivery mirror, tool result, and fallback behavior.
• Evidence after fix (redacted runtime log / transcript facts):
  • User message id 1506371869035462806.
  • One gpt-5.5 assistant tool call at 2026-05-19T19:04:15.810Z.
  • One delivery mirror at 2026-05-19T19:04:16.479Z.
  • Successful message tool result at 2026-05-19T19:04:16.640Z with primary Discord message id 1506371935221715144.
  • No subsequent model snapshot, fallback attempt, second assistant message, or second visible Discord reply for that input.
  • Redacted runtime log excerpt from the patched local gateway:

    2026-05-19T19:04:15.810Z discord #founders-club userMessageId=1506371869035462806 model=openai/gpt-5.5 tool_call=message action=send sourceReplyDeliveryMode=message_tool_only
    2026-05-19T19:04:16.479Z transcript delivery_mirror appended session=agent:main:discord:channel:...5258 delivery=message_tool
    2026-05-19T19:04:16.640Z tool_result name=message status=ok deliveryStatus=sent discordMessageId=1506371935221715144
    2026-05-19T19:04:16.640Z followup_check userMessageId=1506371869035462806 fallbackReplay=false secondAssistantMessage=false secondDiscordReply=false

• Observed result after fix: the Discord reply was delivered once, the tool result stayed successful, and the fallback chain did not replay the same user message.
• What was not tested: full pnpm build && pnpm check && pnpm test; I ran focused validation for the touched runtime surfaces instead.
• Before evidence:
  • Earlier transcript for the same channel showed gpt-5.5 delivering a visible message tool reply, a delivery mirror, then a repaired toolResult with text aborted.
  • The next model snapshot switched to fallback gpt-5.4 and replayed the same user message, producing a second visible Discord reply.

Root Cause (if applicable)

• Root cause: Pi releases the coarse attempt/session lock while the model prompt is running. During a successful message tool send, OpenClaw appends a delivery-mirror assistant message to the same session transcript. That append did not run under the active attempt's session lock, so the attempt's post-prompt fence saw the transcript advance and classified its own delivery mirror as an external takeover.
• Missing detection / guardrail: no regression test covered transcript appends made by owned delivery hooks while an embedded prompt was still active, and message-tool-only source replies did not terminate the attempt after a successful visible in-channel send.
• Contributing context (if known): message-tool-only group delivery suppresses automatic final-text posting, so the message tool send is the source reply. Retrying the prompt after a false aborted tool result can visibly send the same turn twice.

Regression Test Plan (if applicable)

• Coverage level that should have caught this:
  • Unit test
  • Seam / integration test
  • End-to-end test
  • Existing coverage already sufficient
• Target test or file:
  • src/agents/pi-embedded-runner/run/attempt.session-lock.test.ts
  • src/agents/pi-embedded-runner/run/message-tool-terminal.test.ts
  • src/config/sessions/transcript.test.ts
• Scenario the test should lock in: an owned delivery-mirror append during prompt execution refreshes the active prompt fence instead of causing takeover; successful in-channel message sends are terminal only for message-tool-only source delivery; dry-run, suppressed, and no-result sends remain non-terminal unless a result envelope includes positive delivery evidence.
• Why this is the smallest reliable guardrail: it exercises the lock ownership, transcript append, and terminal-send predicates directly without needing a live Discord transport in unit tests.
• Existing test that already covers this (if any): none.
• If no new test is added, why not: N/A.

User-visible / Behavior Changes

• In message-tool-only source replies, a successful in-channel message(action=send) is treated as the visible reply and ends the source turn instead of allowing fallback/finalization to replay the same input.
• Dry-run, suppressed, and no-result message tool sends do not end the turn unless the result envelope includes positive delivery evidence, so they cannot suppress the only visible source reply.

Diagram (if applicable)

Before:
Discord mention -> gpt-5.5 message tool sends -> delivery mirror appends outside prompt lock
  -> prompt fence sees takeover -> tool result repaired as aborted -> fallback retries -> duplicate reply

After:
Discord mention -> gpt-5.5 message tool sends -> delivery mirror appends under owned prompt lock
  -> delivered-evidence message tool terminates message-tool-only source turn -> one visible reply

Security Impact (required)

• New permissions/capabilities? (Yes/No): No
• Secrets/tokens handling changed? (Yes/No): No
• New/changed network calls? (Yes/No): No
• Command/tool execution surface changed? (Yes/No): No
• Data access scope changed? (Yes/No): No
• If any Yes, explain risk + mitigation: N/A

Repro + Verification

Environment

• OS: macOS
• Runtime/container: local OpenClaw gateway, Node v25.6.1
• Model/provider: openai/gpt-5.5 primary, openai/gpt-5.4 fallback, Pi runtime
• Integration/channel (if any): Discord group/channel, message-tool-only visible replies
• Relevant config (redacted): messages.groupChat.visibleReplies: "message_tool"

Steps

1. Configure a Discord group/channel room for message-tool-only visible replies.
2. Trigger the agent with openai/gpt-5.5 primary and openai/gpt-5.4 fallback.
3. Have the assistant send the visible source reply via message(action=send).
4. Inspect the session transcript and gateway log for delivery mirror, tool result status, and fallback attempt.

Expected

• One visible Discord reply.
• Successful message tool result.
• No fallback replay for the same input.
• Dry-run, suppressed, and no-result message sends do not terminate the source turn without positive delivery evidence.

Actual

• Before this patch: a successful visible reply could be followed by an aborted repaired tool result and fallback replay, causing a duplicate reply.
• After this patch: local runtime test produced one visible reply, a successful tool result, and no fallback replay.

Evidence

• Failing test/log before + passing after
• Trace/log snippets
• Screenshot/recording
• Perf numbers (if relevant)

Focused validation run on this branch:

git diff --check origin/main...HEAD
node scripts/run-vitest.mjs run --config test/vitest/vitest.agents-pi-embedded.config.ts src/agents/pi-embedded-runner/run/message-tool-terminal.test.ts src/agents/pi-embedded-runner/run/attempt.session-lock.test.ts
  Test Files  2 passed (2)
  Tests       21 passed (21)

node scripts/run-vitest.mjs run src/config/sessions/transcript.test.ts
  Test Files  1 passed (1)
  Tests       22 passed (22)

Human Verification (required)

• Verified scenarios: live Discord message-tool-only source reply delivered once after local runtime patch; transcript recorded successful tool result; fallback replay did not occur.
• Edge cases checked: automatic delivery is not terminal; failed sends are not terminal; dry-run/non-delivered sends are not terminal; suppressed/no-result sends are not terminal; explicit-route sends are not terminal; sessions_send is not terminal; owned transcript writes only take over the active session lock when session file/key matches.
• What you did not verify: full repository test suite, non-Discord channels, live explicit cross-channel message sends.

Review Conversations

• I replied to or resolved every bot review conversation I addressed in this PR.
• I left unresolved only the conversations that still need reviewer or maintainer judgment.

Compatibility / Migration

• Backward compatible? (Yes/No): Yes
• Config/env changes? (Yes/No): No
• Migration needed? (Yes/No): No
• If yes, exact upgrade steps: N/A

Risks and Mitigations

• Risk: treating a message tool send as terminal could suppress intended additional source-turn output.
  • Mitigation: terminal behavior is limited to sourceReplyDeliveryMode === "message_tool_only", successful message tool send-like actions, no explicit route keys, and positive delivered evidence such as deliveryStatus: "sent" or a delivered messageId. Cross-channel sends, sessions_send, failed sends, dry-run sends, suppressed/no-result sends, reactions, and non-message-tool-only turns continue normally.

Changed files

• src/agents/pi-embedded-runner/run/attempt.session-lock.test.ts (modified, +35/-0)
• src/agents/pi-embedded-runner/run/attempt.ts (modified, +15/-1)
• src/agents/pi-embedded-runner/run/message-tool-terminal.test.ts (added, +312/-0)
• src/agents/pi-embedded-runner/run/message-tool-terminal.ts (added, +211/-0)
• src/config/sessions/transcript-write-context.ts (added, +52/-0)
• src/config/sessions/transcript.test.ts (modified, +27/-0)
• src/config/sessions/transcript.ts (modified, +53/-41)