Bug type

Behavior bug (incorrect output/state without crash)

Summary

OpenClaw can treat failed codex exec --json runs as successful because Codex may emit sandbox/write-denied failure information in JSONL agent output while still exiting with status code 0.

Steps to reproduce

1. Use OpenClaw 2026.3.2 with the built-in codex-cli backend.
2. Trigger a Codex-backed subagent write task in an effective read-only Codex sandbox, or reproduce directly with Codex:

   codex exec "Write a new file named TEST_RO.md with the content 'hello'." --json --color never --sandbox read-only --skip-git-repo-check

3. Observe that no file is created.
4. Observe that Codex emits JSONL events describing the write failure as agent output.
5. Observe that the Codex process still exits with EXIT_CODE=0.
6. In OpenClaw, the run can then be interpreted as completed/successful even though the requested mutation never happened.

Expected behavior

OpenClaw should inspect Codex JSONL output for failed action/tool signals and propagate the run as failed when the underlying file mutation or command execution was denied or rejected.

Actual behavior

A Codex run can fail semantically while still looking successful to OpenClaw because:

• the process exit code is 0
• the failure is surfaced only in JSONL event content
• no file is actually created or modified

This can cause subagent orchestration to record a run as completed even though the requested write never happened.

OpenClaw version

2026.3.2 (52a583035f)

Operating system

Debian GNU/Linux 13 (trixie)

Install method

Local source checkout / dev run

Logs, screenshots, and evidence

Direct Codex repro:

codex exec "Write a new file named TEST_RO.md with the content 'hello'." --json --color never --sandbox read-only --skip-git-repo-check

Observed:
- No file created
- Codex JSONL includes an agent message explaining the write was blocked by a read-only filesystem / write approval policy
- Process exit code is still 0

Control repro:
- Same command with --sandbox workspace-write creates the file successfully

Impact and severity

Affected: Users relying on Codex-backed subagents or Codex fallback runs for coding/file tasks
Severity: High, because failed work can be misreported as successful
Frequency: Reproducible whenever Codex surfaces the failure only through JSONL content while exiting 0
Consequence: Silent false positives in subagent execution, misleading summaries, and harder debugging of failed automation

Additional information

A robust fix is to parse Codex JSONL for failed command_execution / shell_command / file_change items and known sandbox-denied agent messages instead of relying only on process exit status.