This PR separates internal WebChat turns from external channel-origin WebChat delivery so Codex harness defaults do not accidentally suppress normal same-surface replies. Internal WebChat keeps automatic final delivery, while explicit external origins still use the message-tool-only policy where that contract is required.

Summary

This is the narrow safety fix for #81109. Codex harnesses default direct visible replies to the message tool, which is right for external direct-chat surfaces, but internal WebChat is not an outbound delivery target. This PR keeps WebChat-only turns automatic so the user sees the assistant's final reply, while preserving message_tool_only for explicit external origins that happen to be operated through WebChat.

• Problem: internal WebChat Codex turns could suppress the visible final reply and steer the model toward message(action="send"), producing Sent. or no useful visible answer.
• Why it matters: WebChat is the local interactive surface; users need the answer rendered directly unless the turn is explicitly acting on behalf of an external origin.
• What changed: harness sourceVisibleReplies: "message_tool" defaults are skipped only for internal-only WebChat source contexts.
• What did NOT change (scope boundary): external-origin WebChat routes still keep the Codex message-tool default, and external channel delivery behavior is unchanged.

Change Type (select all)

• Bug fix
• Feature
• Refactor required for the fix
• Docs
• Security hardening
• Chore/infra

Scope (select all touched areas)

• Gateway / orchestration
• Skills / tool execution
• Auth / tokens
• Memory / storage
• Integrations
• API / contracts
• UI / DX
• CI/CD / infra

Linked Issue/PR

• Fixes Codex harness default can suppress direct WebChat final replies #81109
• Alternative to fix: render WebChat message tool replies #81144
• Related Dashboard webchat turns can enter message-tool-only mode without a send target #81092
• This PR fixes a bug or regression

Real behavior proof (required for external PRs)

• Behavior or issue addressed: a direct internal WebChat Codex turn should render the assistant final reply to the WebChat thread instead of suppressing automatic delivery, while explicit external WebChat origins should still use the Codex message-tool default.
• Real environment tested: local OpenClaw checkout at /Volumes/LEXAR/repos/openclaw-codex-webchat-delivery, branch fix/codex-webchat-direct-delivery, latest patch d34e6ee76d4, including dispatch policy tests and in-process Gateway WebSocket WebChat proof.
• Exact steps or command run after this patch:

OPENCLAW_VITEST_MAX_WORKERS=1 pnpm test src/auto-reply/reply/dispatch-from-config.test.ts src/gateway/server.chat.gateway-server-chat-b.test.ts
pnpm exec oxfmt --check --threads=1 src/auto-reply/reply/dispatch-from-config.ts src/auto-reply/reply/dispatch-from-config.test.ts src/gateway/server.chat.gateway-server-chat-b.test.ts
git diff --check

• Evidence after fix (screenshot, recording, terminal capture, console output, redacted runtime log, linked artifact, or copied live output):

[test] passed 2 Vitest shards in 16.09s
Gateway shard: Test Files 1 passed, Tests 18 passed
Auto-reply shard: Test Files 1 passed, Tests 108 passed

oxfmt: All matched files use the correct format.
git diff --check: passed

• Observed result after fix: the internal WebChat regression asserts sourceReplyDeliveryMode === "automatic", queuedFinal === true, and the final payload text is visible webchat reply. The new external-origin regression asserts sourceReplyDeliveryMode === "message_tool_only", queuedFinal === false, and no automatic final WebChat send occurs for an explicit OriginatingChannel: "imessage" route.
• What was not tested: manual browser DOM rendering. The Gateway proof uses the same in-process WebSocket route that WebChat uses.
• Before evidence (optional but encouraged): ClawSweeper identified the first guard as too broad because it matched WebChat surface/provider even when an explicit external origin was present.

Root Cause (if applicable)

• Root cause: the first guard treated any WebChat provider/surface/origin as internal WebChat, but chat.send can carry WebChat surface metadata while explicitly operating on behalf of another channel.
• Missing detection / guardrail: coverage proved internal WebChat stayed automatic but did not assert the external-origin WebChat route kept message_tool_only.
• Contributing context (if known): Dashboard webchat turns can enter message-tool-only mode without a send target #81092 explicitly calls out preserving message-tool delivery when WebChat is acting as an external-origin operator surface.

Regression Test Plan (if applicable)

• Coverage level that should have caught this:
  • Unit test
  • Seam / integration test
  • End-to-end test
  • Existing coverage already sufficient
• Target test or file: src/auto-reply/reply/dispatch-from-config.test.ts, src/gateway/server.chat.gateway-server-chat-b.test.ts
• Scenario the test should lock in: internal-only WebChat stays automatic; explicit external WebChat origins keep Codex message-tool delivery.
• Why this is the smallest reliable guardrail: dispatch policy is deterministic and the Gateway test exercises the WebChat chat.send route without needing a browser.
• Existing test that already covers this (if any): none for the explicit external-origin harness default before this patch.
• If no new test is added, why not: N/A, a new regression is included.

User-visible / Behavior Changes

Internal WebChat Codex replies render automatically again. WebChat sessions that explicitly deliver on behalf of an external channel still preserve message-tool-only behavior.

Diagram (if applicable)

flowchart LR
  turn["Incoming WebChat turn"] --> origin{"External origin?"}
  origin -->|no| internal["Internal WebChat"]
  internal --> auto["Automatic final reply"]
  origin -->|yes| external["Explicit external-origin route"]
  external --> messageOnly["message_tool_only contract"]
  messageOnly --> channel["Channel-specific delivery"]

Internal WebChat:
[WebChat source only] -> [Codex harness default skipped] -> [automatic final reply]

Explicit external origin through WebChat:
[WebChat surface + OriginatingChannel=imessage]
  -> [Codex harness default preserved]
  -> [message_tool_only, no accidental automatic external final]

Security Impact (required)

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

Repro + Verification

Environment

• OS: macOS local development host
• Runtime/container: local Lexar-backed OpenClaw checkout
• Model/provider: Codex harness delivery-default policy, not model-provider dependent
• Integration/channel (if any): WebChat dispatch and in-process Gateway WebSocket route
• Relevant config (redacted): harness deliveryDefaults.sourceVisibleReplies: "message_tool"

Steps

1. Run the dispatch and Gateway WebChat proof command.
2. Confirm internal WebChat uses automatic source reply delivery.
3. Confirm explicit external-origin WebChat keeps message_tool_only.

Expected

• Internal WebChat final text is queued and visible.
• Explicit external-origin WebChat does not bypass the Codex message-tool default.

Actual

• 126 focused tests passed across dispatch and Gateway shards.
• Formatter and whitespace checks passed.

Evidence

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

Human Verification (required)

• Verified scenarios: internal WebChat automatic delivery, external-origin WebChat message-tool preservation, Gateway WebSocket WebChat final reply path.
• Edge cases checked: OriginatingChannel: "webchat" vs OriginatingChannel: "imessage", explicit deliver route, Codex harness message_tool default.
• What you did not verify: manual browser DOM rendering and full GitHub CI matrix.

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.

ClawSweeper P2 addressed by d34e6ee76d4: limit the WebChat bypass to internal-only sources.

Compatibility / Migration

• Backward compatible? (Yes/No): Yes
• Config/env changes? (Yes/No): No
• Migration needed? (Yes/No): No
• If yes, exact upgrade steps: N/A

Risks and Mitigations

• Risk: maintainers may prefer fix: render WebChat message tool replies #81144's personality-preserving message-tool renderer instead of this automatic-delivery carveout.
  • Mitigation: this PR stays narrow and is explicitly framed as the conservative option; fix: render WebChat message tool replies #81144 remains available as the product-shape alternative.