openclaw - 💡(How to fix) Fix ACP/Codex child tasks can be marked succeeded with progress-only output and no final deliverable

Summary

Codex ACP child sessions can terminate with only interim/progress text (for example "I'll inspect...", "I'm checking...", "I'm verifying now...") and OpenClaw records the durable task as succeeded / outcome.status=ok even though no final deliverable was captured and the completion announcement later fails.

This makes the parent agent correctly distrust the child ("Codex returned only progress, not delivery"), but the task ledger and UI still present the child run as successful. Operationally this looks like Codex/OpenClaw silently succeeded while no PR/diff/final report was delivered.

Evidence from live incident

Host: Digithag, OpenClaw 2026.5.18. Requester session:

agent:digithag:telegram:group:-1003873045224:topic:29613

Observed runs:

• 43a5db1b-a436-4917-98e1-d48fce0724de

  • child: agent:codex:acp:ffd2f5d3-40e7-4c21-a046-5f20e103eccb
  • transcript had only user + assistant progress text beginning I'll inspect the repository shape...
  • subagents/runs.json: outcome.status=ok, endedReason=subagent-complete, frozenResultText=<progress only>
  • delivery later failed with completion agent did not deliver through the message tool
  • durable task rows still showed status=succeeded

• ab5af93b-861e-4898-a56b-4ea4bb0a3e24

  • child: agent:codex:acp:84f49a5d-37ec-400d-8605-5255ef7ffbbb
  • transcript had only progress text beginning I'll make the operational scaffold...
  • durable task rows showed status=succeeded

• f073fc5e-79db-450d-821f-856b2c6b0973

  • child: agent:codex:acp:5d65a5d7-f552-4b01-942f-01c59e221bf9
  • transcript had only progress/checking text ending around I'm checking whether...
  • deliveryStatus=failed, but status=succeeded

• d147c500-2144-4644-bbfd-7c47396d9cf4

  • child: agent:codex:acp:6ffa707d-34a4-4b24-be38-0d01820df0df
  • transcript had progress text ending I'm verifying main directly now and checking the post-merge Actions runs.
  • deliveryStatus=failed, but status=succeeded

Local command evidence:

openclaw tasks list --json | jq -r '.tasks[] | select(.runId=="d147c500-2144-4644-bbfd-7c47396d9cf4" or .sourceId=="d147c500-2144-4644-bbfd-7c47396d9cf4") | [.taskId,.runtime,.status,.deliveryStatus,.runId,.sourceId,.childSessionKey,(.progressSummary//"")] | @tsv'

Output showed ACP/subagent/CLI rows as succeeded, while the subagent row had deliveryStatus=failed and only progress text.

Journal also logged:

Subagent announce give up (retry-limit) run=d147c500-2144-4644-bbfd-7c47396d9cf4 child=agent:codex:acp:6ffa707d-34a4-4b24-be38-0d01820df0df requester=agent:digithag:telegram:group:-1003873045224:topic:29613 retries=3

Expected

For child sessions that explicitly expect a completion message/final deliverable:

• progress-only output should not be treated as a clean successful deliverable;
• durable task status should surface blocked/failed/needs final deliverable, not plain succeeded;
• parent flow and UI should make it obvious the child did not complete the contract;
• if completion delivery fails after retries, the task should not appear as success without an error surface.

Actual

• ACP manager treats terminal done event as status=succeeded using interim progressSummary.
• Subagent registry freezes latest assistant text as frozenResultText even when it is progress-only.
• Delivery failure is visible in deliveryStatus=failed, but top-level status=succeeded remains, so UI and task ledger look successful.

Local hotfix applied on Digithag

A temporary installed-build hotfix was applied to make this fail less dangerously:

• /usr/lib/node_modules/openclaw/dist/manager-B2E9sBWi.js

  • classify likely progress-only ACP summaries as terminalOutcome=blocked with summary ACP turn ended after progress-only output; no final deliverable was captured.

• /usr/lib/node_modules/openclaw/dist/subagent-registry-Bu5qGLSl.js

  • classify likely progress-only frozenResultText as blocked for subagent task completion.

Validation:

node --check /usr/lib/node_modules/openclaw/dist/manager-B2E9sBWi.js
node --check /usr/lib/node_modules/openclaw/dist/subagent-registry-Bu5qGLSl.js
systemctl restart openclaw-gateway.service
openclaw status --deep

Post-restart health was reachable and channels were OK.

Suggested durable fix

1. Track final vs interim assistant output in the ACP/Codex bridge instead of relying on the last assistant text blob.
2. When expectsCompletionMessage=true, require either an explicit final answer, final tool result, or completion artifact before marking the task as successful.
3. Make delivery failure participate in terminal task state or flow status, not only deliveryStatus, so UI cannot display success while completion delivery failed.
4. Add regression tests for:
   • assistant emits only "I'll do X" and ACP ends;
   • assistant emits "I'm verifying now" and ACP ends;
   • delivery fails after retry-limit;
   • real final report remains succeeded.

Related

This is distinct from issue #83836 (invalid_encrypted_content replay failure). Both affected the same Telegram topic, but this issue is the progress-only / false-success completion contract.