Correction TLDR

Status: harness/mock fixture artifact, not a proven user-facing Codex runtime bug.

The original issue framed this as Codex replaying happy-path fs.read args on a failure-path runtime call. The stronger audit shows the evidence came from the mock provider's /debug/requests planned-args field, not from a verified Codex runtime tool execution.

What actually breaks: the QA fixture used mock provider-plan args as if they were runtime transcript tool-call args. That invalidated the fixture as proof of Codex failure-path read behavior.

Product impact if OpenClaw moved fully to Codex today: P4 until live/native proof says otherwise. This should not be treated as a user-facing read failure unless a real Codex native read-denial path reproduces it.

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 confidence proof separates provider-plan intent from runtime transcript calls and passes with zero unknowns:

{
  "tool-defaults-direct": { "total": 20, "passed": 20, "skipped": 0, "failed": 0 },
  "confidence-report": { "pass": true, "zeroUnknowns": true }
}

Correct Fix

• Replace direct __qaFailureMode tool args with valid tool-shaped args plus separate harness fault injection when this row is expanded again.
• Report provider-plan args separately from runtime tool-call args.
• Add live/native Codex proof before reopening as a product/runtime bug.

Superseded Original Report

The earlier artifact was useful for identifying report confusion, but it should not be treated as proof that Codex rewrites runtime read args.