Codex review: needs maintainer review before merge. Reviewed July 6, 2026, 5:38 AM ET / 09:38 UTC.

Summary
The branch tightens Codex app-server message_tool_only developer instructions and updates the focused assertion plus three Codex prompt snapshots.

PR surface: Source 0, Tests +10. Total +10 across 5 files.

Reproducibility: yes. I did not rerun the full production Telegram failure locally, but current main’s ambiguous instruction plus the terminal message-tool classifier match the reported trace in #100153.

Review metrics: 1 noteworthy metric.

• Prompt token delta: +152 to +153 rough tokens in affected message-tool-only snapshots. The added guidance runs on eligible Codex source-channel turns, so maintainers should notice the recurring prompt-cost tradeoff before merge.

Root-cause cluster
Relationship: fixed_by_candidate
Canonical: #100153
Summary: This PR is the focused implementation candidate for the open Codex message-tool-only progress-send terminality issue; related message-loss reports share surfaces but either already merged a classifier fix or track distinct remaining behavior.

Members:

• canonical: Codex message-tool-only turns can stop after progress/status message sends #100153 - The PR body uses closing syntax for this open issue and implements its requested instruction-level fix.
• same_root_cause: Codex app-server: message(action=send) tool prematurely terminates turn — agent goes silent mid-task #100175 - The closed report describes the same user-visible progress-message-then-silent symptom, though it proposed broader runtime changes.
• partial_overlap: Fix Codex message-tool-only source reply completion #95942 - The merged PR added source-reply terminal recognition that this PR now explains to Codex, but it did not address progress/status wording.
• adjacent_distinct: message_tool_only: one-shot delivery reminder loses to recency over long tool chains, turns end in withheld finals #100367 - That open issue concerns long-tool-chain reminder decay and withheld finals, not early terminal release after a progress current-source send.

Proposal only: this assessment does not dispatch repair, suppress jobs, mutate sibling items, close, or merge anything.

Merge readiness
Overall: 🦞 diamond lobster
Proof: 🦞 diamond lobster ✨ media proof bonus
Patch quality: 🦞 diamond lobster
Result: ready for maintainer review.

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

Risk before merge

• [P1] The fix is prompt steering rather than a runtime guarantee, so maintainers are still accepting model-instruction compliance as the right lever for final-only source replies; the related long-tool-chain reminder decay remains tracked separately.

Maintainer options:

1. Land the focused prompt fix (recommended)
   Merge after maintainers accept the instruction-level delivery contract; exact-head CI and Telegram proof are already positive.
2. Tighten wording before merge
   Ask for a shorter equivalent instruction if maintainers want lower recurring prompt-token cost without changing the current-source versus out-of-band distinction.
3. Pause for runtime semantics instead
   Pause only if maintainers want progress/final delivery to become a runtime API or recovery design rather than model-facing guidance.

Next step before merge

• No ClawSweeper repair is needed; this open PR is mergeable, proof-positive, and has no actionable review findings.

Security
Cleared: Cleared: the diff changes a Codex developer-instruction string, a focused assertion, and prompt snapshot fixtures, with no dependency, workflow, secret, package, or executable supply-chain surface.

@clawsweeper re-review

🦞🧹
ClawSweeper re-review requested.

I asked ClawSweeper to review this item again.
Action: item re-review queued (workflow sweep.yml, event repository_dispatch).
Result: the existing ClawSweeper review comment will be edited in place when the review finishes.

Superseding my previous proof artifact for now.

The first uploaded video is not good enough as review proof: most of the clip stays on one static tool-output frame, and the final visible section can be read as ambiguous ordering. I am rerunning a cleaner Telegram proof with the chat pinned to the bottom so the tool-output-then-final-reply ordering is visible in one continuous capture.

Focused English Telegram proof for @clawsweeper:

Video: https://raw.githubusercontent.com/ooiuuii/openclaw/proof/pr-100156-telegram-20260705/pr-100156-telegram-proof-english-focused-20s.mp4

What the video shows:

• The Telegram prompt asks the agent to use Bash to run node -v, then send exactly one final visible reply with the Node version and no progress/status reply first.
• The agent performs the Bash tool call before the visible final reply.
• The Bash output is v22.22.0.
• The current-source visible reply is a single final answer: Node version: v22.22.0.
• The capture is cropped to the Telegram conversation pane and excludes the private chat list/sidebar.

This replaces my earlier proof artifact, which was too long/static and ambiguous for review.

@clawsweeper re-review

Added inspectable proof to the PR body so review does not need ffprobe:

• Contact sheet: https://raw.githubusercontent.com/ooiuuii/openclaw/proof/pr-100156-telegram-20260705/pr-100156-telegram-proof-english-contact-sheet-strict.jpg
• Focused 20s video: https://raw.githubusercontent.com/ooiuuii/openclaw/proof/pr-100156-telegram-20260705/pr-100156-telegram-proof-english-focused-20s.mp4

The contact sheet shows the English Telegram prompt, the Bash node -v tool call/output, and the single final visible reply.

@clawsweeper re-review

Reviewed at head ddd7202c against main and the sibling Codex app-server protocol.

The change is instruction-only — it rewrites the message_tool_only visible-reply guidance in buildVisibleReplyInstruction (extensions/codex/src/app-server/thread-lifecycle.ts:1752), updates the matching assertion in run-attempt.test.ts, and regenerates the three codex-runtime prompt snapshots. No runtime path changes.

I checked the two things that decide whether this is the right lever:

1. It has to be instruction-level, not runtime enforcement. In the Codex app-server, each tool call — including OpenClaw's message dynamic tool — surfaces as a ThreadItem streamed via item/completed during the turn, and turn/completed only marks the end (codex-rs/app-server-protocol/src/protocol/common.rs:1625/1632, .../protocol/v2/item.rs:221). ItemCompleted is in the lossless-delivery tier (codex-rs/app-server-client/src/lib.rs:150-175), so a mid-turn message(action=send) to the source is delivered immediately — there's no protocol-level hold-until-turn-end to lean on. Steering the model to send only the final source reply is therefore the correct mechanism.

2. The new wording matches the real runtime classifier. isDeliveredMessageToolOnlySourceReplyResult (src/agents/embedded-agent-message-tool-source-reply.ts:546) treats an implicit-route (or explicit source-route) message.send as the source reply and an explicit out-of-band send to another conversation as ordinary tool work — exactly the distinction the new instruction draws. So the guidance is accurate, not aspirational.

Two things before it lands:

• The branch is currently CONFLICTING against main; needs a rebase.
• After rebasing, regenerate the three prompt snapshots on Linux/Node 24 (CI truth) rather than trusting a local macOS run, or the snapshot lane can drift.

Minor, non-blocking: the instruction roughly quadruples in length (~+150 rough tokens per applicable run, scoped to message_tool_only + message-tool-available Codex runs). The win — no duplicate/premature source messages — justifies it, but a tightening pass would keep the behavior at lower token cost.

Thanks @AmirF194, this was helpful.

I rebased the branch onto current main and resolved the prompt snapshot conflicts. I also refreshed the three affected Codex prompt snapshots against the rebased code and kept the fixture paths in POSIX form so they stay aligned with the Linux snapshot baseline.

Local checks I ran after the rebase:

node scripts/run-vitest.mjs extensions/codex/src/app-server/run-attempt.test.ts --testNamePattern="scopes Codex developer reply instructions to message-tool-only delivery"
# 1 passed | 114 skipped

git diff --check
# clean

GitHub now reports the PR as mergeable again; CI is running on the updated head 787d668081 for the Linux/Node truth.

Additional production evidence supports this mitigation. During an OpenClaw 2026.6.10 control window, we recorded no turn.dynamic_tool_terminal_release events caused by message; after moving to 2026.7.1-beta.2, we recorded more than 100. Affected turns follow message(send) -> tool result(ok) -> turn.dynamic_tool_terminal_release -> session ended, including acknowledgment/status messages before work completes. This independently matches #100153.

The final-only instruction is useful defense in depth, though the long-term distinction should be explicit delivery intent rather than inferred terminality. This branch appears to need only a rebase/snapshot refresh. I can prepare that focused refresh or an adversarial GPT-5.6 continuation test if the author or a maintainer wants help, without widening this PR's scope.

Closing: maintainers chose the structural completion contract over the prompt-only approach. #105365 (merged as 4dc6e18) adds an explicit final control to the projected Codex message schema with delivery-confirmed termination and progress-aware recovery, which holds up against model noncompliance in a way prompt steering alone cannot — an ignored instruction degrades to legacy behavior instead of a stranded or duplicated reply. Thanks for the proof-positive alternative; it clarified the decision. If the landed contract shows gaps in practice, a fresh issue with run telemetry would reopen the discussion.