Summary

Subagent completion delivery appears to have two related failure modes in OpenClaw 2026.5.4:

1. stale subagent completion announcements are delivered into the requester session later and converted into user-visible replies, even when they are no longer part of the live conversation; and
2. new subagent sessions can contain unrelated prior transcript turns, so a debugging subagent can answer/correct an older task instead of only the task it was just spawned to perform.

This is not just noisy output. It produced an unexpected Telegram message to the user around 03:23 BKK with stale Operations-account verification text that was not part of the current conversation.

Environment

• OpenClaw: 2026.5.4 (325df3e)
• Runtime package: /opt/homebrew/lib/node_modules/openclaw
• Channel: Telegram direct
• Main session: agent:main:telegram:default:direct:8455538490
• Model: openai-codex/gpt-5.5 with fallbacks gpt-5.4, gpt-5.4-mini
• Context engine: lossless-claw enabled

User-visible symptom

The user received this stale message around 03:23 BKK, 1–2 hours after the relevant Operations setup thread:

- Gateway health: ✅ live
- Operations Telegram account: ✅ configured
- Operations allowlist includes `6814512991`: ❌ no

It was not part of the live conversation at that time.

Evidence 1: subagent announce delivered stale output to main session

Main session file:

/Users/lume/.openclaw/agents/main/sessions/ce453bcd-1055-4dab-be1c-237056fdb504.jsonl

At line 630 / 2026-05-05T20:23:02.686Z (03:23 BKK), OpenClaw injected an inter-session message:

[Inter-session message]
sourceSession=agent:main:subagent:8a21843e-95c7-4952-a521-6b09b5c45ed1
sourceChannel=webchat
sourceTool=subagent_announce
isUser=false
...
[Internal task completion event]
source: subagent
session_key: agent:main:subagent:8a21843e-95c7-4952-a521-6b09b5c45ed1
session_id: 7e982b1a-244f-4642-823d-2c543b4e8c8e
type: subagent task
task: runtime-replay-source-trace
status: completed successfully
...
Result:
Correcting my earlier answer: the direct live-config check now shows the subagents were right.

- Gateway health: ✅ live
- Operations Telegram account: ✅ configured
- Operations allowlist includes `6814512991`: ❌ no

At line 631 / 2026-05-05T20:23:06.123Z, the main session sent a normal user-facing answer:

Confirmed.

- Gateway health: ✅ live
- Operations Telegram account: ✅ configured
- Operations allowlist includes `6814512991`: ❌ no

`allowFrom` exists but is currently empty...

That confirms a stale subagent announce was converted into an outbound reply.

Evidence 2: source subagent session had unrelated prior history

Inspecting agent:main:subagent:8a21843e-95c7-4952-a521-6b09b5c45ed1 showed the session did not begin cleanly with the assigned runtime-replay-source-trace task.

It contained older unrelated turns first:

User: Verify health and confirm Operations Telegram account allowlist includes 6814512991 without exposing secrets.
Assistant: Verified. ... Does it include `6814512991`? ✅ yes

Only later did the subagent receive:

[Subagent Context] You are running as a subagent (depth 1/1)...
Begin. Your assigned task is in the system prompt under Your Role...

Then it answered the old Operations verification thread:

Correcting my earlier answer: the direct live-config check now shows the subagents were right.
...
Operations allowlist includes `6814512991`: ❌ no

This response is unrelated to the assigned debugging task. A second investigator subagent (agent:main:subagent:88edc2fb-6cc1-472c-8919-1bc1f094e5ca) showed the same contamination pattern.

Evidence 3: LCM recorded the bad state, but likely did not originate delivery

LCM search finds the stale phrase after the event, but as recorded messages:

• msg#536690 assistant at 03:22 BKK
• msg#536691 inter-session/user at 03:23 BKK
• msg#536692 assistant at 03:23 BKK

LCM-specific investigation found duplicated heartbeat text stored as separate assistant messages in LCM conversation 1872, but no synthetic LCM repair rows (message_parts.is_synthetic=1 was 0). Recent compaction summaries did not cover the duplicate window.

Current read: LCM is recording already-corrupted/replayed transcript state; the primary bug appears to be upstream session/subagent delivery/history stitching.

Existing related issues

This is related to but not fully covered by:

• Subagent completion output leaks internal tool-failure reasoning to requester session #39032 — subagent completion output leaks internal tool-failure reasoning
• [Bug]: Subagent completion delivery can be lost on direct-announce timeout, drain, or orphan prune #67777 — subagent completion delivery can be lost on timeout/drain/orphan prune
• [Bug] Gateway duplicates inbound messages — same message injected multiple times into session #58443 — gateway duplicates inbound messages
• [Bug]: Heartbeat / async system events can interrupt and effectively swallow in-progress replies in Telegram topic sessions #64810 — async system events can interrupt/swallow in-progress replies

The distinct piece here is: completion is delivered stale, and the subagent session itself appears to have inherited or reused unrelated prior transcript turns.

Expected behavior

• A newly spawned subagent should start with only its assigned task/context, not unrelated earlier user/assistant turns.
• subagent_announce should not be injected into the requester session as a user-like message if stale or no longer contextually valid.
• Internal task completion events should not be auto-converted into user-visible replies without freshness/session validation.
• If a completion is stale, it should be suppressible, spooled for explicit review, or at least clearly marked as non-current.

Suggested investigation surfaces

• sessions_spawn session allocation/reuse/session key generation
• subagent transcript initialization and restored session lookup
• subagent_announce delivery freshness checks
• inter-session message injection into main as role=user
• requester conversation advancement after sessions_yield
• lossless-claw ingestion of inter-session events (secondary)

Local evidence artifact

Full local evidence note:

/Users/lume/.openclaw/workspace-eva/docs/reports/openclaw-subagent-announce-replay-bug-2026-05-06.md