Summary

ACP/Codex 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 Pattern

Observed on a real background ACP workflow. Operational identifiers and deployment details are intentionally redacted.

The affected child sessions had transcripts shaped like:

user: <task requiring concrete deliverables>
assistant: I'll inspect/check/verify/merge now... <progress-only text>

The durable task state then showed rows equivalent to:

runtime=acp       status=succeeded  deliveryStatus=session_queued  progressSummary=<progress-only text>
runtime=subagent  status=succeeded  deliveryStatus=failed          progressSummary=<progress-only text>
runtime=cli       status=succeeded  deliveryStatus=not_applicable

A completion retry path also logged retry exhaustion with completion agent did not deliver through the message tool, but the top-level task status still stayed succeeded.

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 Operational Mitigation

A temporary installed-build mitigation was applied on the affected deployment to classify likely progress-only ACP/subagent summaries as a blocked terminal outcome instead of a clean success. This is an operational mitigation only; upstream should replace it with a structured completion contract.

Validation used syntax checks on the modified runtime files plus a gateway restart and health/channel checks. Deployment-specific paths, session ids, channel ids, and host details are intentionally omitted.

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 affect completion reliability, but this issue is specifically the progress-only / false-success completion contract.