Reject blocked PostToolUse results in code mode #391

Objective

Make blocking PostToolUse outcomes fail closed for code-mode JavaScript while preserving established direct-mode and pre-tool hook behavior.

Finish Line

After a tool side effect completes, an explicit blocking result or hook exit code 2 suppresses the successful result and rejects the code-mode tool promise; feedback-only continue:false, direct-mode replacement behavior, and existing PreToolUse semantics do not regress.

Current Status

Update 2026-07-22 UTC — implemented in PR #402 from code/post-tool-use-code-mode-391 at 2d94aa08b9.

The missing local behavior was isolated to codex-core tool-result handling. The codex-hooks parser and exit-code normalization from upstream commit d7f298fe20a560fc5bfab78ef19e0c76b4d201bb were already present, so the production change now rejects blocked completed results before they can reach code-mode JavaScript while preserving the completed side effect.

Coverage now proves:

• explicit PostToolUse block and exit code 2 reject the nested promise after execution
• the original successful result is hidden from JavaScript
• continue:false remains feedback-only and resolves with the original typed result
• PreToolUse block still prevents execution and input rewrite still returns the rewritten result
• caught nested errors leave the outer code cell successful
• direct-mode replacement tests continue to pass

Validation completed:

• regression failed before the production fix and passed after it
• focused final code-mode hook set passed 5/5
• codex-hooks passed 128/128
• broad codex-core completed 2,988 tests with 2,920 passing, 68 unrelated baseline/environment failures, and 16 skipped; all new tests passed
• scoped no-deps Clippy passed after allowing only documented pre-existing deny-level lints
• just fmt, git diff --check, and final specialist reviews passed
• JetBrains reported zero problems but could not prove semantic Rust coverage for the two changed files

Next action: watch PR #402 through CI and review, merge when green, then close #391 and update parent #307.

Blocked by: none.

Waiting for: PR #402 CI and review.

Scope

• In: codex-core tool registry/code-mode result conversion, codex-hooks post-tool outcomes, and focused core/hooks integration coverage.
• Out: managed-policy fallback, unified-exec escalation, TUI warning presentation, hook API redesign, and rollback of completed tool side effects.

Acceptance Criteria

• Explicit blocking and hook exit code 2 run after the tool side effect and reject the code-mode JavaScript promise.
• The original successful tool output is not exposed to code mode after blocking.
• A side-effect marker proves the tool already ran; the implementation does not imply rollback.
• PostToolUse continue:false remains feedback-only rather than blocking.
• Direct-mode replacement behavior remains unchanged.
• Existing PreToolUse block and input-rewrite behavior does not regress.
• Focused integration coverage under codex-rs/core/tests/suite uses test_codex and covers explicit blocking, exit code 2, feedback-only behavior, direct mode, and pre-tool regression boundaries.
• just test -p codex-core and just test -p codex-hooks pass; because codex-core changes, the complete just test gate is run per repository workflow before final handoff.
• The implementation stays below 500 changed lines of complex logic and 800 total changed lines.

Relationships

• Parent: Sync exec, tools, sandbox, and external-agent substrate #307 execution, tools, sandbox, and external-agent substrate.
• Source ledger: Verify upstream coverage through checkpoint and classify pending delta #387 upstream coverage audit.
• Grandparent through Sync exec, tools, sandbox, and external-agent substrate #307: Sync Codex Lab with current openai/codex substrate #230.
• Related: managed-policy fallback and unified-exec authorization preservation; none blocks the others.
• related: Verify upstream coverage through checkpoint and classify pending delta #387 - Verify upstream coverage through checkpoint and classify pending delta #387

Decisions

• Blocking hooks may suppress the model-visible result but cannot roll back an already-completed tool side effect.
• Preserve existing direct-mode and pre-tool semantics unless separately planned.