Bug type

Behavior bug (incorrect output/state without crash)

Beta release blocker

No

Summary

The exec-driven runtime can surface completed from process lifecycle alone, with no post-run artifact verification, wrong-tree rejection, or closure-state distinction for artifact-dependent workflow consumers.

Steps to reproduce

1. Inspect the governing exec closure path in the exact matching source tag v2026.4.15:
   src/agents/bash-tools.exec-runtime.ts
   src/agents/bash-tools.exec.ts
   src/agents/bash-process-registry.ts

2. Observe that buildExecExitOutcome(...) derives completed|failed from RunExit lifecycle fields only, and that runExecProcess(...) calls markExited(...) and returns the outcome without any artifact verification step.

3. Observe that buildExecForegroundResult(...), FinishedSession, and replay surfaces inherit that lifecycle-only verdict unchanged.

4. In the external workflow consumer used to validate this hazard, a wrong-tree probe writes the report under repo__integration/.../docs/archive/reports/... while the canonical repo/docs/archive/reports/... path remains absent; the lifecycle ended, but the patched runtime blocked closure specifically because artifact verification was added out-of-tree.

Expected behavior

For any workflow-aware exec usage that depends on required durable artifacts, the runtime should not surface successful closure until the required canonical artifact exists at the expected location; a wrong-tree artifact should not count as success. This expected behavior is grounded by the locally patched runtime, which blocked closure when the canonical report was missing or only present under the wrong tree.

Actual behavior

In the matching upstream source, exec completion is lifecycle-gated only: completed is derived from process exit status, persisted into finished-session state, and surfaced to downstream consumers without any required-artifact verification, canonical-path enforcement, wrong-tree rejection, bounded materialization recovery, or truthful lifecycle-vs-closure distinction.

OpenClaw version

2026.4.15 (exact source tag match: v2026.4.15, commit 041266a)

Operating system

Ubuntu 24.04.x on the reporting machine.

Install method

Installed package present at ~/.openclaw/lib/node_modules/openclaw.

Model

codex-gpt5.4

Provider / routing chain

OpenClaw exec runtime -> codex exec -> codex-gpt5.4

Additional provider/model setup details

Observed on an out-of-tree workflow consumer using codex-gpt5.4 through the OpenClaw exec path. The source-level bug is in exec closure semantics and is independent of model quality; codex-gpt5.4 is the effective model used during the live validation runs.

Logs, screenshots, and evidence

Key evidence:
exact source match and feature-absence matrix showing artifact verification, wrong-tree rejection, bounded recovery, prompt capture, and truthful closure reporting are absent on the governing exec path
live wrong-tree probe showing canonical report absent, wrong-tree report present, and patched runtime blocking closure with step_blocked_ambiguity_or_divergence �
run_phase4_wrong_tree_runtime_probe_result.json
source investigation showing completion is surfaced from lifecycle status alone and that the path permits successful/lifecycle completion before artifact verification

Impact and severity

Affected users/systems/channels: observed on an external workflow-driven consumer of the exec runtime; no in-tree OpenClaw consumer currently depends on artifact-gated closure.
Severity: blocks workflow correctness for artifact-dependent external consumers.
Frequency: deterministic for the missing-artifact / wrong-tree probe cases; latent for current generic in-tree exec usage.
Consequence: downstream consumers can treat a step as completed from lifecycle exit alone even when the required canonical artifact is missing or only exists under the wrong tree, which forces out-of-tree recovery or custom closure guards.

Additional information

A source-level patch was intentionally not proposed yet because no concrete in-tree caller currently needs this seam. The recommended next step from the source investigation was: upstream issue first, and only add an optional artifact-gated closure contract when a real in-tree consumer exists so the seam can be reviewed against an actual caller rather than tests alone.

openclaw-source-bug-verification-report-2026-04-20.md

openclaw-source-bug-verification-summary-2026-04-20.json

openclaw-live-packet-verification-followup-2026-04-20.md

run_phase4_wrong_tree_runtime_probe_result.json