Correction TLDR

Status: harness/profile fixture issue only, not a Codex runtime bug.

The fixture targeted a direct message tool while the QA runtime parity profile is coding. In that profile, session messaging is represented by sessions_send; the direct message tool belongs to messaging/channel-oriented surfaces.

What actually breaks: the fixture was misleading as required-default coverage. It should be report-only for the coding profile or covered by a separate messaging-profile/channel scenario.

Product impact if OpenClaw moved fully to Codex today: P4. No user-facing Codex break is proven by this issue.

Latest Beta.5 Evidence

OpenClaw baseline: v2026.5.10-beta.5
PR: #80323
PR head: 3336dec6419c9cc9a87dc7cfa6f48118ca2d838e
Remote proof run: https://github.com/electricsheephq/openclaw-local-test/actions/runs/25719383976
Confidence tracker: #80936

The corrected default-tool gate now passes as a hard gate:

{
  "tool-defaults-direct": { "total": 20, "passed": 20, "skipped": 0, "failed": 0 },
  "openclaw-dynamic-tools-direct": { "total": 8, "passed": 8, "skipped": 0, "failed": 0 }
}

Correct Fix

• Keep direct message as optional/profile-specific in the coding-profile tool-defaults suite.
• Add a separate messaging-profile fixture if maintainers want direct message coverage.
• Do not retarget this exact row to sessions_send; that tool has inter-session run/announce side effects and should have its own fixture.

Superseded Original Report

The earlier wording was unclear because it sounded like OpenClaw users lacked messaging. The actual issue was that a coding-profile fixture targeted a messaging-profile tool.