[hooks] add non-streaming (non-stdin style) shell-only PostToolUse support by eternal-openai · Pull Request #15531 · openai/codex

eternal-openai · 2026-03-23T18:27:39Z

CHAINED PR - note that base is eternal/hooks-pretooluse-bash, not main -- so the following PR should be first

Matching post-tool hook to the pre-tool functionality here: #15211

So, PreToolUse calls for plain shell calls, allows blocking. This PostToolUse call runs after the command executed

example run:

› as a test, run in parallel the following commands:
  - echo 'one'
  - echo '[block-pre-tool-use]'
  - echo '[block-post-tool-use]'


⚠ MCP startup incomplete (failed: notion, linear)

• Cruising through those three commands in parallel now, and I’ll share the exact outputs right after
  they land.

• Running PreToolUse hook: checking the observatory runes

• Running PreToolUse hook: checking the observatory runes

• Running PreToolUse hook: checking the observatory runes

PreToolUse hook (blocked)
  warning: wizard-tower PreToolUse demo blocked a Bash command on purpose.
  feedback: PreToolUse demo blocked the command. Remove [block-pre-tool-use] to continue.

PreToolUse hook (completed)
  warning: wizard-tower PreToolUse demo inspected Bash: echo 'one'

PreToolUse hook (completed)
  warning: wizard-tower PreToolUse demo inspected Bash: echo '[block-post-tool-use]'

• Ran echo '[block-post-tool-use]'
  └ [block-post-tool-use]

• Ran echo 'one'
  └ one

• Running PostToolUse hook: reading the observatory aftermath

• Running PostToolUse hook: reading the observatory aftermath

PostToolUse hook (blocked)
  warning: wizard-tower PostToolUse demo blocked the Bash follow-through on purpose.
  feedback: PostToolUse demo blocked the result after execution. Remove [block-post-tool-use] to
continue.

PostToolUse hook (completed)
  warning: wizard-tower PostToolUse demo inspected Bash: echo 'one'
  hook context: PostToolUse demo saw the Bash result. Response preview: one

──────────────────────────────────────────────────────────────────────────────────────────────────────

• Ran them in parallel. Little wave report:

  - echo 'one' completed and returned one.
  - echo '[block-pre-tool-use]' was blocked before execution by the PreToolUse hook.
  - echo '[block-post-tool-use]' ran, but its result was blocked afterward by the PostToolUse hook.

  The hook messages were:

  - PreToolUse demo blocked the command. Remove [block-pre-tool-use] to continue.
  - PostToolUse demo blocked the result after execution. Remove [block-post-tool-use] to continue.


› for the blocked messages (correctly blocked in this test) did the tool output land back into
  context?


• Yeah, from this run:

  - PreToolUse block: the command itself did not execute, so no command output landed in context. Only
    the block message did.
  - PostToolUse block: the command did execute, but the actual stdout did not come back into context.
    Only the post-tool block message did.

  So the blocked notifications landed in context, but the blocked command payloads themselves did not.
  Nice clean guardrail, aloha.

Codex has been incrementally shipping hook support (PreToolUse, PostToolUse, UserPromptSubmit, SessionStart, Stop), but the Codex converter silently dropped all hooks during conversion -- the only converter that didn't even warn. This adds partial hook conversion for the 5 compatible events and specific warnings for everything unconvertible. - Add CodexHookEventName union, CodexHookCommand, CodexHookMatcher, CodexHooks types and hooks field to CodexBundle - Add CODEX_EVENTS map with toolScoped flag, isBashCompatibleMatcher() helper, and convertHooksForCodex() to the converter - Write .codex/hooks.json with backup support in the writer - Auto-enable [features] codex_hooks = true in config.toml when hooks present - Refactor renderCodexConfig() to options object for extensibility - Update Codex spec with hooks documentation - 18 new tests (12 converter + 6 writer) PostToolUse conversion depends on openai/codex#15531 merging.

…h-fix # Conflicts: # codex-rs/core/tests/suite/shell_snapshot.rs # codex-rs/exec/src/event_processor_with_human_output.rs # codex-rs/tui/tests/suite/model_availability_nux.rs # codex-rs/tui_app_server/tests/suite/model_availability_nux.rs

pakrym-oai · 2026-03-25T22:00:40Z

codex-rs/core/src/tools/registry.rs

+        } else {
+            None
+        };
        let hook_abort_error = dispatch_after_tool_use_hook(AfterToolUseHookDispatch {


Are post tool use and after tool use different hooks?

Yeah, this was introduced by @gt-oai in the old version. I'm maintaining support for now, but it'll get deprecated/removed later

pakrym-oai · 2026-03-25T22:02:02Z

codex-rs/core/src/tools/registry.rs

+            .await;
+
+            if outcome.should_stop {
+                let replacement_text = outcome


both branches of this if look very similar

pakrym-oai · 2026-03-25T22:03:04Z

codex-rs/core/src/tools/registry.rs

+                    .unwrap_or_else(|| "PostToolUse hook stopped execution".to_string());
+                let mut guard = response_cell.lock().await;
+                if let Some(result) = guard.as_mut() {
+                    result.result = Box::new(FunctionToolOutput::from_text(


what if the tool is CustomTool and needs custom response.

Why are we highjacking the tool result?

Shouldn't the model still get the real tool result?

CustomTool support out of scope for this PR, I'm trying to just handle "Bash" (i.e. the name for shell-like stuff in the spec)

Killing the tool result is intentional, if the hook "blocks" the output, it basically has the opportunity to rewrite it with its own context

pakrym-oai · 2026-03-25T22:04:26Z

codex-rs/core/src/tools/context.rs


    fn to_response_item(&self, call_id: &str, payload: &ToolPayload) -> ResponseInputItem;

+    fn post_tool_use_response(&self, _call_id: &str, _payload: &ToolPayload) -> Option<JsonValue> {


what should this property contain for a notmal tool output?

By default it should be None. A tool only populates post_tool_use_response if it intentionally supports a stable PostToolUse payload shape

pakrym-oai · 2026-03-25T22:06:41Z

codex-rs/core/src/tools/handlers/unified_exec.rs

+        exec_command_pre_tool_use_payload(&invocation.tool_name, &invocation.payload)
+    }
+
+    fn post_tool_use_payload(&self, result: &AnyToolResult) -> Option<PostToolUsePayload> {


AnyToolResult is what ToolResult is wrapped into at higher levels of execution to arase the concrete handler output type, it's a bit circular to pass it back in.

Agreed. I cleaned this up so handlers no longer receive the AnyToolResult just to shape the hook payload. They now get call_id, payload, and &dyn ToolOutput, which keeps the boundary better

Small note, the spec is pretty bad around tool_response (and tool_input): "...The exact schema for both depends on the tool." ... with no further elaboration :)

So basically we have to handle "any" and I've been reading how this works in the wild as the source of truth ¯_(ツ)_/¯

pakrym-oai · 2026-03-25T22:07:09Z

codex-rs/core/src/tools/handlers/unified_exec.rs

+    tool_name: &str,
+    payload: &ToolPayload,
+) -> Option<PreToolUsePayload> {
+    if tool_name != "exec_command" {


can this be shared with normal arg parsing?

Yep, agreed, fixed

pakrym-oai · 2026-03-25T22:08:51Z

codex-rs/core/src/tools/handlers/shell.rs

+        return None;
+    };
+
+    serde_json::from_str::<ShellCommandToolCallParams>(arguments)


is parse_arguments appropriate here?

I think so, yes, fixed

pakrym-oai · 2026-03-25T22:16:15Z

codex-rs/core/src/tools/handlers/shell.rs

+            Ok(output) => {
+                let post_tool_use_response =
+                    crate::tools::format_exec_output_str(&output, turn.truncation_policy);
+                let content = emitter.finish(event_ctx, Ok(output)).await?;


can let content = emitter.finish(event_ctx, Err(error)).await?;
line be pulled out of the if and only post_tool_use_response calculated separately?

why don't we use content directly?

Agree, simplified. emitter.finish now sits outside the branch, and only the post_tool_use_response calculation stays conditional

I kept that separate on purpose. content seems like more model-facing rendered shell text, which is more transcript/UI-oriented. tool_response for PostToolUse is meant to be the stable tool-specific result payload, so I didn’t want to couple the hook input to the transcript formatting

pakrym-oai · 2026-03-26T00:39:37Z

codex-rs/core/src/tools/registry.rs

            Err(err) => (err.to_string(), false),
        };
        emit_metric_for_tool_read(&invocation, success).await;
+        let post_tool_use_payload = if success {


for the future it would be nice to offload hook processing into it's own routine. non blocking

Ok, noted for a future followup

pakrym-oai · 2026-03-26T00:40:05Z

codex-rs/core/src/tools/registry.rs

-        }
-        _ => None,
-    }
+fn replace_result_with_feedback(result: &mut AnyToolResult, text: String) {


not worth a helper.

pakrym-oai · 2026-03-26T00:40:42Z

codex-rs/core/src/tools/handlers/shell.rs

    }

+    fn pre_tool_use_payload(&self, invocation: &ToolInvocation) -> Option<PreToolUsePayload> {
+        shell_pre_tool_use_payload(&invocation.payload)


why don't we inline these methods?

goes for all of them

pakrym-oai · 2026-03-26T00:42:13Z

codex-rs/core/src/tools/handlers/unified_exec.rs

+
+    let args = parse_arguments::<ExecCommandArgs>(arguments).ok()?;
+    if args.tty {
+        return None;


Was just playing it safe for now, I didn't handle streaming/interactive shell usage in this PR, and that mirrors the PreToolUse one. Definitely needs a followup, but it doesn't fit cleanly into the spec, so I've been thinking about what to do about it (maybe a spec extension)

pakrym-oai · 2026-03-26T00:43:14Z

codex-rs/core/src/tools/handlers/unified_exec.rs

+        .map(|args| PreToolUsePayload { command: args.cmd })
+}
+
+fn exec_command_post_tool_use_payload(


eternal-openai changed the base branch from main to eternal/hooks-pretooluse-bash March 23, 2026 18:31

eternal-openai force-pushed the eternal/hooks-posttooluse-bash branch 2 times, most recently from 21c16e1 to 266ecb6 Compare March 23, 2026 19:16

eternal-openai added a commit that referenced this pull request Mar 23, 2026

codex: use raw bash output for post-tool-use hooks (#15531)

f2b1367

Base automatically changed from eternal/hooks-pretooluse-bash to main March 23, 2026 21:33

eternal-openai added 4 commits March 23, 2026 14:34

PostToolUse for Bash-style tools only

bf04633

Align PostToolUse feedback semantics

b731065

Ignore current aws-lc cargo-deny advisories

a9375f0

codex: use raw bash output for post-tool-use hooks (#15531)

285b9f8

eternal-openai force-pushed the eternal/hooks-posttooluse-bash branch from f2b1367 to 285b9f8 Compare March 23, 2026 22:02

eternal-openai added 4 commits March 23, 2026 15:43

Stabilize shell snapshot apply_patch test

ecb586c

Relax macOS resume interrupt assertion

5a4c417

Align PostToolUse block feedback semantics

8958492

codex: fix argument comment lint on PR #15531

d10f912

tmchow mentioned this pull request Mar 23, 2026

feat(codex): add hook conversion support for 5 Codex lifecycle events EveryInc/compound-engineering-plugin#354

Draft

5 tasks

StrayDragon mentioned this pull request Mar 24, 2026

How use in codex and qwen rtk-ai/rtk#649

Open

eternal-openai added 4 commits March 24, 2026 14:38

pretooluse pr fixes, general hardening

9baf815

Simplify bash post-tool-use scope

a10ebab

Restore post-tool-use for one-shot exec commands

0ea0d64

eternal-openai marked this pull request as ready for review March 24, 2026 23:48

pakrym-oai reviewed Mar 25, 2026

View reviewed changes

eternal-openai added 2 commits March 25, 2026 16:47

review cleanups

c0274bc

codex: fix CI failure on PR #15531

bc85657

pakrym-oai reviewed Mar 26, 2026

View reviewed changes

pakrym-oai approved these changes Mar 26, 2026

View reviewed changes

pakrym-oai reviewed Mar 26, 2026

View reviewed changes

codex: inline post tool use payload helpers

2e3dca3

github-actions bot mentioned this pull request Mar 26, 2026

📊 AI CLI 工具社区动态日报 2026-03-26 gsscsd/big_model_radar#96

Open

eternal-openai merged commit c4d9887 into main Mar 26, 2026
63 of 66 checks passed

eternal-openai deleted the eternal/hooks-posttooluse-bash branch March 26, 2026 02:18

github-actions bot locked and limited conversation to collaborators Mar 26, 2026

Provide feedback

Saved searches

Use saved searches to filter your results more quickly

[hooks] add non-streaming (non-stdin style) shell-only PostToolUse support#15531

[hooks] add non-streaming (non-stdin style) shell-only PostToolUse support#15531
eternal-openai merged 15 commits intomainfrom
eternal/hooks-posttooluse-bash

eternal-openai commented Mar 23, 2026 •

edited

Loading

pakrym-oai Mar 25, 2026

eternal-openai Mar 25, 2026

pakrym-oai Mar 25, 2026

eternal-openai Mar 25, 2026

pakrym-oai Mar 25, 2026

eternal-openai Mar 25, 2026

pakrym-oai Mar 25, 2026

eternal-openai Mar 25, 2026 •

edited

Loading

pakrym-oai Mar 25, 2026

eternal-openai Mar 25, 2026

pakrym-oai Mar 25, 2026

eternal-openai Mar 25, 2026

pakrym-oai Mar 25, 2026

eternal-openai Mar 25, 2026

pakrym-oai Mar 25, 2026

pakrym-oai Mar 25, 2026

eternal-openai Mar 25, 2026

pakrym-oai Mar 26, 2026

eternal-openai Mar 26, 2026

pakrym-oai Mar 26, 2026

pakrym-oai Mar 26, 2026

pakrym-oai Mar 26, 2026

pakrym-oai Mar 26, 2026

eternal-openai Mar 26, 2026

pakrym-oai Mar 26, 2026

Uh oh!

Labels

2 participants


		fn to_response_item(&self, call_id: &str, payload: &ToolPayload) -> ResponseInputItem;

		fn post_tool_use_response(&self, _call_id: &str, _payload: &ToolPayload) -> Option<JsonValue> {

Conversation

eternal-openai commented Mar 23, 2026 • edited Loading Uh oh! There was an error while loading. Please reload this page.

Uh oh!

Choose a reason for hiding this comment

Choose a reason for hiding this comment

Choose a reason for hiding this comment

Choose a reason for hiding this comment

Choose a reason for hiding this comment

Choose a reason for hiding this comment

Choose a reason for hiding this comment

eternal-openai Mar 25, 2026 • edited Loading Uh oh! There was an error while loading. Please reload this page.

Uh oh!

Choose a reason for hiding this comment

Choose a reason for hiding this comment

Choose a reason for hiding this comment

Choose a reason for hiding this comment

Choose a reason for hiding this comment

Choose a reason for hiding this comment

Choose a reason for hiding this comment

Choose a reason for hiding this comment

Choose a reason for hiding this comment

Choose a reason for hiding this comment

Choose a reason for hiding this comment

Choose a reason for hiding this comment

Choose a reason for hiding this comment

Choose a reason for hiding this comment

Choose a reason for hiding this comment

Choose a reason for hiding this comment

Choose a reason for hiding this comment

Choose a reason for hiding this comment

Uh oh!

Labels

2 participants

eternal-openai commented Mar 23, 2026 •

edited

Loading

eternal-openai Mar 25, 2026 •

edited

Loading