fix: prompt Codex to send visible channel replies by joshavant · Pull Request #84397 · openclaw/openclaw

joshavant · 2026-05-20T02:01:07Z

Summary

Problem: Codex app-server message-tool-only turns could end with private final assistant text instead of sending a visible channel reply through message(action="send").
Solution: Strengthen the message-tool-only runtime/developer guidance so visible output is explicitly tied to a message tool send before the turn ends.
What changed: Updated Codex app-server reply instructions, auto-reply channel context, ACP delivery hints, message tool descriptions, tests, and prompt snapshots.
What did NOT change: No default delivery-mode flip, no channel-specific workaround, and no changelog entry in the opening PR commit.

Motivation

Closes [Bug]: v2026.5.18: Telegram plain-text outbound dispatch silently fails after memory-pressure event; survives docker restart; cron and slash-command paths still work #84129. Live Telegram/Codex repro showed the visible-reply path depends on Codex choosing message(action="send"); the fix keeps the existing delivery architecture and makes that requirement explicit at the prompt/tool boundary.

Change Type (select all)

Scope (select all touched areas)

Linked Issue/PR

Closes [Bug]: v2026.5.18: Telegram plain-text outbound dispatch silently fails after memory-pressure event; survives docker restart; cron and slash-command paths still work #84129
This PR fixes a bug or regression

Real behavior proof

Behavior addressed: Telegram direct replies using Codex app-server with sourceReplyDeliveryMode=message_tool_only now instruct Codex to send visible output through message(action="send") instead of relying on private final text.
Real environment tested: AWS Crabbox, lease cbx_c3d13b859625, Telegram direct inbound, openai-codex provider, gpt-5.5 model.
Exact steps or command run after this patch: Ran the live Telegram direct repro from the patched branch in Crabbox, with heartbeat disabled and a unique inbound marker, then inspected OpenClaw gateway logs and Codex trajectory events.
Evidence after fix: Crabbox run run_a3d9d6e4da7f; marker oc84129-direct-84129-20260520T014618Z-3037; trajectory contained one tool.call for message with action="send"; gateway log showed Telegram inbound processing followed by outbound send ok with message id 269.
Observed result after fix: Codex called message(action="send"), Telegram outbound delivery succeeded, and the run completed normally.
What was not tested: Other live channels beyond Telegram direct; CI will cover the focused unit/snapshot tests.
Before evidence: Earlier live run reproduced the auth/profile failure mode seen by the reporter once provider auth was missing; after auth was fixed, the relevant failure mode was narrowed to Codex choosing private final output unless prompted to use message.

Root Cause

Root cause: Message-tool-only turns had multiple prompt layers that said normal final output was private, but the instruction to use message(action="send") for visible channel output was too weak or inconsistent for Codex app-server direct-reply turns.
Missing detection / guardrail: Prompt snapshots and tests did not lock the stronger visible-output requirement across Codex app-server, auto-reply metadata, ACP dispatch, and message-tool descriptions.
Contributing context: The Codex app-server final answer is private to OpenClaw/Codex for this delivery mode, so a model final answer alone cannot satisfy a visible channel reply.

Regression Test Plan

Coverage level that should have caught this:
- Unit test
- Seam / integration test
- End-to-end test
- Existing coverage already sufficient
Target test or file: extensions/codex/src/app-server/run-attempt.test.ts, src/auto-reply/reply/*.test.ts, src/agents/tools/message-tool.test.ts, src/gateway/tool-resolution.test.ts, and test/scripts/prompt-snapshots.test.ts.
Scenario the test should lock in: Message-tool-only delivery guidance explicitly says visible output requires message(action="send") before ending the turn, while quiet turns should avoid sending.
Why this is the smallest reliable guardrail: The bug is prompt/tool-contract behavior, so prompt unit assertions plus committed prompt snapshots catch regressions without needing a live provider for every change.
Existing test that already covers this (if any): Existing prompt snapshot infrastructure covers the model-bound prompt shape; this PR updates the expected content.
If no new test is added, why not: N/A.

User-visible / Behavior Changes

Codex-backed message-tool-only channel replies should more reliably appear in the source channel when a visible response is needed.

Diagram (if applicable)

Before:
[channel message] -> Codex final text -> private to OpenClaw/Codex -> no visible reply

After:
[channel message] -> Codex calls message(action="send") -> channel delivery -> visible reply

Security Impact (required)

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

Repro + Verification

Environment

OS: AWS Crabbox Linux for live proof; local macOS checkout for focused tests.
Runtime/container: OpenClaw current branch on Crabbox; local Node/Vitest via node scripts/run-vitest.mjs.
Model/provider: gpt-5.5 via openai-codex.
Integration/channel (if any): Telegram direct.
Relevant config (redacted): Gateway auth and Telegram credentials supplied through existing local/Crabbox credential paths; no secrets included here.

Steps

Start OpenClaw on Crabbox from the patched branch with Codex app-server and Telegram direct channel enabled.
Send a unique Telegram direct inbound marker.
Inspect Codex trajectory and gateway logs for message(action="send") and outbound Telegram delivery.

Expected

Codex sends visible output through the message tool before ending the turn.

Actual

Codex called message(action="send"), Telegram outbound send succeeded, and the run completed normally.

Evidence

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

Focused local verification after rebasing onto current origin/main:

git diff --check
node scripts/run-vitest.mjs src/gateway/tool-resolution.test.ts extensions/codex/src/app-server/run-attempt.test.ts src/auto-reply/reply/groups.test.ts src/auto-reply/reply/inbound-meta.test.ts src/auto-reply/reply/dispatch-acp.test.ts src/agents/tools/message-tool.test.ts test/scripts/prompt-snapshots.test.ts

Result: 10 test files passed, 416 tests passed.

Autoreview:

AUTOREVIEW_AUTO_TESTS=0 .agents/skills/autoreview/scripts/autoreview --mode local

Result: autoreview clean: no accepted/actionable findings reported.

Human Verification (required)

Verified scenarios: Live Telegram direct inbound with Codex app-server, focused prompt/tool tests, prompt snapshots, diff whitespace hygiene, autoreview.
Edge cases checked: Message tool unavailable in Codex developer instructions still falls back to the active Codex delivery path; quiet/no-visible-output instructions still tell Codex not to call message(action="send").
What you did not verify: Other live channels and a full repository check.

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
Config/env changes? No
Migration needed? No
If yes, exact upgrade steps: N/A

Risks and Mitigations

Risk: Stronger prompt wording could make Codex send when the right behavior is silence.
- Mitigation: The wording explicitly preserves the no-visible-output path and tests assert that quiet turns should not call message(action="send").

clawsweeper · 2026-05-20T02:03:21Z

Codex review: needs maintainer review before merge.

Workflow note: Future ClawSweeper reviews update this same comment in place.

How this review workflow works

ClawSweeper keeps one durable marker-backed review comment per issue or PR.
Re-runs edit this comment so the latest verdict, findings, and automation markers stay together instead of adding duplicate bot comments.
A fresh review can be triggered by eligible @clawsweeper re-review comments, exact-item GitHub events, scheduled/background review runs, or manual workflow dispatch.
PR/issue authors and users with repository write access can comment @clawsweeper re-review or @clawsweeper re-run on an open PR or issue to request a fresh review only.
Maintainers can also comment @clawsweeper review to request a fresh review only.
Fresh-review commands do not start repair, autofix, rebase, CI repair, or automerge.
Maintainer-only repair and merge flows require explicit commands such as @clawsweeper autofix, @clawsweeper automerge, @clawsweeper fix ci, or @clawsweeper address review.
Maintainers can comment @clawsweeper explain to ask for more context, or @clawsweeper stop to stop active automation.

Summary
The PR strengthens Codex message-tool-only visible-reply prompt guidance across app-server developer instructions, auto-reply/ACP context, message tool descriptions, prompt snapshots, tests, and the changelog.

Reproducibility: yes. with source and PR-body proof rather than a local live rerun: current main suppresses automatic delivery in message_tool_only mode, and the PR records a live Telegram/Codex run where the patched prompt produced a message(action="send") call and outbound delivery.

PR rating
Overall: 🦞 diamond lobster
Proof: 🦞 diamond lobster
Patch quality: 🦞 diamond lobster
Summary: Small focused patch with strong live proof and matching prompt/test coverage; remaining uncertainty is maintainer-owned prompt-delivery risk, not a contributor action blocker.

What the crustacean ranks mean

🦀 challenger crab: rare, exceptional readiness with strong proof, clean implementation, and convincing validation.
🦞 diamond lobster: very strong readiness with only minor maintainer review expected.
🐚 platinum hermit: good normal PR, likely mergeable with ordinary maintainer review.
🦐 gold shrimp: useful signal, but proof or patch confidence is still limited.
🦪 silver shellfish: thin signal; proof, validation, or implementation needs work.
🧂 unranked krab: not merge-ready because proof is missing/unusable or there are serious correctness or safety concerns.
🌊 off-meta tidepool: rating does not apply to this item.

Shiny media proof means a screenshot, video, or linked artifact directly shows the changed behavior. Runtime, network, CSP, and security claims still need visible diagnostics.

Real behavior proof
Sufficient (logs): The PR body includes after-fix live Crabbox Telegram/Codex proof with a run id, unique marker, message(action="send") trajectory observation, and outbound Telegram send result.

Mantis proof suggestion
A live Telegram transcript would materially help maintainers see the exact visible reply behavior that this prompt change is intended to repair. A maintainer can ask Mantis to capture proof by posting a new PR comment that starts with the OpenClaw Mantis account mention, followed by:

telegram live: verify a Codex app-server Telegram direct turn with message-tool-only delivery sends a visible reply through message(action="send").

Risk before merge

Prompt wording changes can alter live send/silence behavior for message-tool-only turns beyond the Telegram direct path proven in the PR body.
The maintainer label is protected, so this should not be automatically landed or cleanup-closed without explicit maintainer handling.

Maintainer options:

Land With Maintainer Acceptance (recommended)
Accept the prompt-driven delivery tradeoff after reviewing the focused tests, snapshots, and live Telegram proof for this exact head.
Request One More Live Transcript
Ask for an additional Mantis or Crabbox visible Telegram transcript if maintainers want stronger confidence in the exact chat-visible behavior before merge.
Pause For Prompt Policy Review
Pause the PR if maintainers are not ready to make explicit send-before-ending wording the shared contract for Codex message-tool-only turns.

Next step before merge
Protected maintainer handling and the prompt-delivery merge risk remain; there is no narrow automated repair finding for ClawSweeper to fix.

Security
Cleared: The diff changes prompt text, tests, snapshots, and changelog only; it does not add permissions, dependency sources, secret handling, network calls, or code-execution surfaces.

Review details

Best possible solution:

Land the prompt-contract tightening after maintainer acceptance of the message-delivery tradeoff, keeping the existing delivery architecture and defaults intact.

Do we have a high-confidence way to reproduce the issue?

Yes, with source and PR-body proof rather than a local live rerun: current main suppresses automatic delivery in message_tool_only mode, and the PR records a live Telegram/Codex run where the patched prompt produced a message(action="send") call and outbound delivery.

Is this the best way to solve the issue?

Yes. The PR fixes the implicated prompt/tool contract across the Codex app-server, ACP, inbound context, chat context, and message-tool description without flipping delivery defaults or adding a channel-specific workaround.

What I checked:

Protected PR state: The provided live GitHub context shows this PR is open, unmerged, contributor-authored, and labeled maintainer, so it must stay open for explicit maintainer handling rather than cleanup closure.
Current-main delivery behavior: Current main resolves message_tool_only into suppressed automatic source delivery, so a normal assistant final can remain private unless the model uses the message tool. (src/auto-reply/reply/source-reply-delivery-mode.ts:111, 5d799c2d2052)
Current-main weak Codex app-server instruction: The current Codex app-server prompt helper only says to use the message tool for a visible message, without naming action="send", final-text privacy, or the before-ending requirement. (extensions/codex/src/app-server/thread-lifecycle.ts:887, e0d1a2a9b9a8)
PR app-server fix: The branch changes the Codex developer instruction to require calling message with action="send" before ending when visible output is needed, and to avoid that call when no visible channel response is needed. (extensions/codex/src/app-server/thread-lifecycle.ts:889, 82a5f94c66df)
PR shared prompt/tool coverage: The branch applies the same visible-output wording to message-tool descriptions, ACP turn text, direct/group chat context, and inbound metadata rather than only changing the Codex app-server layer. (src/agents/tools/message-tool.ts:862, 82a5f94c66df)
Focused regression coverage: The branch updates unit assertions and prompt snapshots so message-tool-only turns require explicit visible-send wording while automatic delivery does not gain that instruction. (extensions/codex/src/app-server/run-attempt.test.ts:1391, 82a5f94c66df)

Likely related people:

yujiawei: Blame ties the current message-tool-only delivery-mode helpers, ACP guidance, group/direct context, inbound metadata, and message-tool hint surfaces to commit 9e9feb5. (role: introduced current delivery-mode scaffold; confidence: high; commits: 9e9feb52f43c; files: src/auto-reply/reply/source-reply-delivery-mode.ts, src/auto-reply/reply/groups.ts, src/auto-reply/reply/dispatch-acp.ts)
pash-openai: Commit e0d1a2a moved Codex app-server soul context into developer instructions and touched the Codex app-server prompt helper and prompt snapshots now changed by this PR. (role: recent Codex prompt-path contributor; confidence: high; commits: e0d1a2a9b9a8; files: extensions/codex/src/app-server/thread-lifecycle.ts, extensions/codex/src/app-server/run-attempt.test.ts, test/fixtures/agents/prompt-snapshots/codex-runtime-happy-path/telegram-direct-codex-message-tool.md)
Peter Steinberger: History shows the original message tool and CLI implementation in commit db22207, making this a likely adjacent owner for message-tool contract changes. (role: original message tool feature contributor; confidence: medium; commits: db222070143a; files: src/agents/tools/message-tool.ts)

Codex review notes: model gpt-5.5, reasoning high; reviewed against 5d799c2d2052.

clawsweeper · 2026-05-20T02:10:51Z

ClawSweeper PR egg

✨ Hatched: 🥚 common Brave Proofling

Hatch command

Comment @clawsweeper hatch when this PR is hatchable.

Hatchability rules:

Merged PRs are hatchable.
Open PRs are hatchable when they are status: 👀 ready for maintainer look, status: 🚀 automerge armed, or labeled clawsweeper:automerge.
Closed unmerged PRs are hatchable only when one of those hatchable labels is still present in the durable record.

Rarity: 🥚 common.
Trait: purrs at green checks.
Image traits: location green-check meadow; accessory shell-shaped keyboard; palette seafoam, black, and opal; mood watchful; pose sitting proudly on a smooth stone; shell smooth pearl shell; lighting clean product lighting; background small green status lights.
Share on X: post this hatch
Copy: My PR egg hatched a 🥚 common Brave Proofling in ClawSweeper.

What is this egg doing here?

Eggs appear after the PR passes real-behavior proof. It is here for vibes, not verdicts: it does not change labels, ratings, merge decisions, or automation.
The shell reacts to review momentum: open follow-up work warms it up, re-review makes it wobble, and a clean final review lets it hatch.
Hatchability usually comes from sufficient real-behavior proof, no blocking P0/P1/P2 findings, no security attention needed, and clean correctness. A merged PR is already final, so merge makes the egg hatchable independently.
The hatch is seeded from this repository and PR number, so the same PR keeps the same creature; the reviewed head SHA can only change safe visual details.
Rarity is just collectible sparkle: 🥚 common, 🌱 uncommon, 💎 rare, ✨ glimmer, and 🌈 legendary.

…84442) This reverts commit 47eb4ca.