fix(codex): force message tool for source replies by VishalJ99 · Pull Request #76663 · openclaw/openclaw

VishalJ99 · 2026-05-03T12:04:43Z

Summary

force the Codex app-server dynamic tool build to keep message available when source reply delivery is message_tool_only
cover the tools.profile = "coding" case that otherwise filters message out while automatic source delivery is suppressed
add an unreleased changelog fix entry

Validation

pnpm test extensions/codex/src/app-server/run-attempt.test.ts
pnpm exec oxfmt --check --threads=1 extensions/codex/src/app-server/run-attempt.ts extensions/codex/src/app-server/run-attempt.test.ts
OPENCLAW_LOCAL_CHECK=1 OPENCLAW_LOCAL_CHECK_MODE=throttled pnpm check:changed

Note: the first local test invocation used an invalid Jest-only --runInBand flag and failed before tests ran; the valid command above passed.

clawsweeper · 2026-05-03T12:06:15Z

Codex review: needs maintainer review before merge.

Summary
The PR forces the Codex app-server dynamic tool build to include message for message_tool_only source replies, adds a coding-profile regression test, and records an Unreleased changelog fix with contributor credit.

Reproducibility: yes. from source inspection: dispatch can resolve a source reply to message_tool_only while current main's Codex app-server tool builder omits forceMessageTool, and the coding profile excludes message unless forced. I did not run live WhatsApp or Vitest in this read-only review.

Next step before merge
No repair lane is needed; the latest diff addressed the prior changelog-credit finding and the remaining action is normal maintainer merge/check gating.

Security
Cleared: The patch only changes an existing runtime tool-selection flag, a colocated regression test, and changelog text; it adds no dependency, workflow, secret-handling, or package execution surface.

Review details

Best possible solution:

Land the narrow app-server parity fix after normal maintainer merge and exact-head check gating so tool-only Codex source replies always expose message under restrictive profiles.

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

Yes, from source inspection: dispatch can resolve a source reply to message_tool_only while current main's Codex app-server tool builder omits forceMessageTool, and the coding profile excludes message unless forced. I did not run live WhatsApp or Vitest in this read-only review.

Is this the best way to solve the issue?

Yes. Passing the resolved source-reply delivery mode into the existing forceMessageTool seam mirrors embedded and follow-up paths and is narrower than changing global profile policy or visible-reply fallback behavior.

What I checked:

Current app-server path misses the force flag: Current main builds Codex app-server dynamic tools with disableMessageTool and heartbeat flags but does not pass forceMessageTool into createOpenClawCodingTools. (extensions/codex/src/app-server/run-attempt.ts:1431, 6aa4fb7a69b2)
Existing seam keeps message through restrictive profiles: createOpenClawCodingTools already exposes forceMessageTool and merges message into the runtime profile allowlist when the option is true. (src/agents/pi-tools.ts:354, 6aa4fb7a69b2)
Coding profile normally excludes message: The tool catalog assigns message to the messaging profile, and existing tests assert coding-profile tools omit message unless forceMessageTool is set. (src/agents/pi-tools.create-openclaw-coding-tools.test.ts:567, 6aa4fb7a69b2)
Dispatch can select tool-only source delivery: Dispatch resolves source replies to message_tool_only, adds runtime message allowance, and passes the resolved mode into reply execution. (src/auto-reply/reply/dispatch-from-config.ts:682, 6aa4fb7a69b2)
Docs define the visible-reply contract: The channel config docs say tool-only visible replies keep normal final replies private, require message(action=send), and fall back only when the message tool is unavailable under policy. Public docs: docs/gateway/config-channels.md. (docs/gateway/config-channels.md:780, 6aa4fb7a69b2)
Embedded/follow-up paths already force message: Adjacent embedded-runner and follow-up execution paths already pass forceMessageTool when the source reply mode is message_tool_only, matching the PR's app-server parity fix. (src/auto-reply/reply/agent-runner-execution.ts:1455, 6aa4fb7a69b2)

Likely related people:

steipete: Local blame points the current app-server dynamic tool builder and forceMessageTool profile seam to recent Peter Steinberger work; the PR timeline also shows steipete updating the changelog credit on this branch. (role: recent maintainer; confidence: high; commits: 68b56108f61f, 39c5bbf08e12; files: extensions/codex/src/app-server/run-attempt.ts, src/agents/pi-tools.ts, extensions/codex/src/app-server/approval-bridge.ts)
Tyler Nishida: Recent path history shows work on message-tool-only fallback behavior through dispatch-from-config and related source-reply tests. (role: adjacent source-reply maintainer; confidence: medium; commits: 796c1e67c3d9; files: src/auto-reply/reply/dispatch-from-config.ts, src/auto-reply/reply/dispatch-from-config.test.ts, src/auto-reply/reply/get-reply-run.media-only.test.ts)
Josh Lehman: Recent path history shows chat-delivery and tool-progress maintenance touching the same dispatch surface. (role: adjacent chat-delivery maintainer; confidence: medium; commits: 30018bddc611; files: src/auto-reply/reply/dispatch-from-config.ts, src/auto-reply/reply/dispatch-from-config.test.ts, src/gateway/server-chat.ts)

Codex review notes: model gpt-5.5, reasoning high; reviewed against 6aa4fb7a69b2.

steipete · 2026-05-03T14:29:45Z

Landed via squash merge onto main.

Gate: pnpm exec oxfmt --check --threads=1 CHANGELOG.md extensions/codex/src/app-server/run-attempt.ts extensions/codex/src/app-server/run-attempt.test.ts; pnpm test extensions/codex/src/app-server/run-attempt.test.ts; git diff --check; Testbox OPENCLAW_TESTBOX=1 pnpm check:changed
Source head: 6aa9763
Merge commit: 0e4d28a

Thanks @VishalJ99!

@VishalJ99