[Feature request] Extend PreToolUse hooks beyond Bash + implement updatedInput rewrite

Summary

The PreToolUse hook in ~/.codex/hooks.json currently fires for Bash/shell tool calls only. Two related requests that together unlock full-parity middleware integrations:

Expand PreToolUse to all tool calls — specifically read_file and grep, which are the other high-volume tools with the highest potential to overflow context when left unconstrained (apply_patch is now fixed — see progress below)
Implement updatedInput in the hook response — the runtime currently rejects it with "PreToolUse hook returned unsupported updatedInput". Implementing this would let hooks enforce programmatic budgets (e.g. cap limit on a file read, cap head_limit on a grep) rather than relying on model compliance

Motivation

I'm the author of squeez, an external compression middleware that integrates with Claude Code, Copilot CLI, OpenCode, Gemini CLI, and Codex CLI via their respective hook systems.

For Codex specifically, I can compress Bash output via the existing PreToolUse + PostToolUse hooks — that part works today. But read_file / grep results routinely push sessions past the context budget, and without a hook surface on those tools the only fallback is a prose hint in AGENTS.md, which the model may or may not honour.

If the hook surface expanded, middleware could uniformly enforce output-size budgets across every tool call, the same way Claude Code's PreToolUse + tool-input rewrite does today.

Progress

✅ Fixed in 0.123.0 (PR #18391, 2026-04-23)

apply_patch now emits PreToolUse and PostToolUse hook events
tool_name in hook stdin is now handler-supplied (no longer always "Bash")

❌ Still blocked

read_file and grep have no ToolHandler with pre_tool_use_payload/post_tool_use_payload — only test files exist, no hook dispatch

updatedInput is explicitly rejected by output_parser.rs:

if output.updated_input.is_some() {
    Some("PreToolUse hook returned unsupported updatedInput".to_string())
}

Suggested acceptance criteria

PreToolUse fires for read_file and grep in addition to Bash/shell and apply_patch
A hook emitting {"decision":"allow","updatedInput":{...}} has the rewritten input passed to the tool
Documentation updated to reflect both

Downstream tracker

squeez CodexCliAdapter stays at BUDGET_SOFT (prose hints in AGENTS.md) until both remaining items land. Will flip to BUDGET_HARD once confirmed. Happy to test a dev branch.

Additional context

Related discussion: #2150

Potential duplicates detected. Please review them and close your issue if it is a duplicate.

Powered by Codex Action

fix(hosts): back Copilot CLI BUDGET_HARD with real Read/Grep/Glob hoo…

fix: back Copilot BUDGET_HARD with Read/Grep hook + update upstream r…

feat(cli): CLI-first surface; drop MCP; one-line install / uninstall

feat: risk policy actions - flag/block secrets and PII (#2444)

@fcoury-oai

Status update — 2026-05-05

Following up with findings from a detailed audit of the upstream source and release history.

What shipped

#18391 (merged 2026-04-22, released in 0.123.0 on 2026-04-23) fixed apply_patch:

ApplyPatchHandler now implements pre_tool_use_payload() and post_tool_use_payload()
tool_name in hook stdin is now handler-supplied instead of always hardcoded as "Bash"
Hooks registered with ".*" or "apply_patch" matchers will now fire for apply_patch calls

This is a real, meaningful improvement — thank you to @fcoury-oai and the reviewers.

What is still blocked

Two of the three asks in the original issue remain unresolved:

read_file and grep hook surface — these tools still have no ToolHandler implementation with pre_tool_use_payload/post_tool_use_payload. Only test files exist (read_file_tests.rs, grep_files_tests.rs); no hook dispatch for these tools.
updatedInput rewrite — output_parser.rs explicitly rejects this today:
```
if output.updated_input.is_some() {
    Some("PreToolUse hook returned unsupported updatedInput".to_string())
}
```
So a hook emitting {"decision":"allow","updatedInput":{...}} will produce an error, not a rewrite. This is the critical gate for hard budget enforcement on input parameters (e.g. capping limit on a file read).

Downstream impact

The squeez CodexCliAdapter remains at BUDGET_SOFT — prose hints in AGENTS.md — because updatedInput + read_file/grep hooks are still needed to flip to BUDGET_HARD. The adapter comments have been updated to reflect the current upstream state accurately (including the 0.123.0 apply_patch win).

Leaving this issue open until both remaining items land. Happy to test a dev branch when available.

docs(codex): update adapter comments and README for 0.123.0 hook surface

Indexed this hook ticket in the umbrella tracker: #21753

Goal: collect the scattered Codex hook requests and bugs into one parity matrix for Full Claude Code Hook Parity (29+), while preserving this issue as the detailed thread for its specific behavior.

feat(codex): add native PreToolUse hook integration (closes edouard-c…

agent-eval: add gemini-yolofs adapter; bump Codex and Gemini pins

feat: universal PATH shim — automatic shell filtering on every agent …

feat: automatic filtering on every agent (shim + universal read-guard…

feat(codex): enable PreToolUse rewrite hook (codex>=0.134) + AiTool i…

fix: back Copilot BUDGET_HARD with Read/Grep hook + update upstream r…

docs(codex): update adapter comments and README for 0.123.0 hook surface

feat(activity): codex adapter with $skill and subagent signals

Please we need this asap

@danzaio

Status update — 2026-07-09

Re-audited against current main (Codex v0.144.0, released today) by reading the shipped source directly, since I don't have a working local Codex install to test live right now (unrelated broken npm vendor binary on my end).

Both blockers from the original issue appear resolved upstream

1. updatedInput rewrite — no longer rejected for PreToolUse.

Support PreToolUse updatedInput rewrites #20527 ("Support PreToolUse updatedInput rewrites", merged 2026-05-12) generalizes updatedInput beyond Bash: Bash-like tools, apply_patch, and MCP tools now all accept the rewrite.
Default function tools into tool hooks #23757 ("Default function tools into tool hooks", merged 2026-05-23) goes further — CoreToolRuntime now provides a default pre_tool_use_payload / post_tool_use_payload / with_updated_hook_input implementation for every ordinary local function tool, not just the ones with bespoke wiring. Explicit exceptions are hosted tools and code-mode wait/write_stdin.
Confirmed in current codex-rs/hooks/src/engine/output_parser.rs: the validation for PreToolUse only rejects updatedInput when it's not paired with hookSpecificOutput.permissionDecision: "allow" — the exact combination the issue originally needed now round-trips cleanly. The literal error string quoted in this issue's original report ("PreToolUse hook returned unsupported updatedInput") no longer exists for PreToolUse in current source (a similarly-worded rejection still exists for the separate PermissionRequest hook type, which is a different code path).

2. read_file / grep hook surface — the premise may be moot rather than fixed.

I went looking for the read_file/grep tool handlers this issue originally referenced (read_file_tests.rs, grep_files_tests.rs) in codex-rs/core/src/tools/ on current main and couldn't find them — there's no dedicated read_file or grep model-facing tool in the current tree. File access appears to route through the shell/exec tool (hooked since day one) or through MCP servers (hooked since #20527/#23757). If those handlers existed back in April and were since removed/consolidated, or if I'm missing something, please correct me — but as far as I can tell reading main today, this specific gap doesn't reproduce.

What I haven't done

I have not runtime-tested this — only static-read the source. If someone can confirm live that a PreToolUse hook with hookSpecificOutput.permissionDecision: "allow" + updatedInput actually rewrites a non-Bash/non-apply_patch/non-MCP local tool call end-to-end on a current build, that would close the loop.

Downstream

@danzaio — the fix you're waiting on has very likely already shipped (0.131.0–0.133.0 range, currently at 0.144.0). Worth updating and retesting on your end.

For squeez: I'm holding off flipping CodexCliAdapter from BUDGET_SOFT to BUDGET_HARD until I get a live confirmation (my local Codex install is broken and unrelated to this issue). Will close this out once that's confirmed, either by me or by anyone else who can verify on a working install.

docs(codex): update hook-surface notes per openai/codex#18491 audit

fix(codex): 深审四个 BLOCKER 全部证实并修正——含"hook 从未真正运行"

scope: a row keeps the project it was born in (plugin 1.7.4)

feat(live): codex adapter surface + shell-rung hardening

fix(wrap): stop registering the Codex shrink hook the README says it …

daily triage 2026-09-08→09-14: Codex api-key route missing /v1 (and t…

feat(mcp): Codex plugin hooks for tool guardrails (#1620)

Navigation Menu

Repository navigation

[Feature request] Extend PreToolUse hooks beyond Bash + implement updatedInput rewrite #18491

Summary

Motivation

Progress

✅ Fixed in 0.123.0 (PR #18391, 2026-04-23)

❌ Still blocked

Suggested acceptance criteria

Downstream tracker

Additional context

Status update — 2026-05-05

What shipped

What is still blocked

Downstream impact

3 remaining items

Status update — 2026-07-09

Both blockers from the original issue appear resolved upstream

What I haven't done

Downstream

Metadata

Assignees

Labels

Type

Projects

Milestone

Relationships

Development

[Feature request] Extend PreToolUse hooks beyond Bash + implement updatedInput rewrite #18491

Description

Summary

Motivation

Progress

✅ Fixed in 0.123.0 (PR #18391, 2026-04-23)

❌ Still blocked

Suggested acceptance criteria

Downstream tracker

Additional context

Activity

github-actions commented on Apr 18, 2026

claudioemmanuel commented on May 5, 2026

Status update — 2026-05-05

What shipped

What is still blocked

Downstream impact

oxysoft commented on May 8, 2026

3 remaining items

danzaio commented on Jul 9, 2026

claudioemmanuel commented on Jul 9, 2026

Status update — 2026-07-09

Both blockers from the original issue appear resolved upstream

What I haven't done

Downstream

Metadata

Metadata

Assignees

Labels

Type

Projects

Milestone

Relationships

Development

Issue actions