PreToolUse hooks do not fire for the internal patch/edit tool

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

• #26729

Powered by Codex Action

Update: Internal tool name is apply_patch

Checked Codex session transcripts (~/.codex/sessions/*.jsonl) and found the internal tool name:

{
  "type": "custom_tool_call",
  "name": "apply_patch",
  "input": "*** Begin Patch\n*** Update File: ...\n@@\n..."
}

The tool is registered as custom_tool_call with name apply_patch. Current PreToolUse matchers (Write, Edit, Bash) do not match this tool name.

Proposed fix: Either:

1. Fire PreToolUse hooks for apply_patch tool calls (most consistent)
2. Document apply_patch as a valid matcher name so plugins can register for it
3. Map apply_patch to the existing Write/Edit matchers since it performs the same operation

Candidate fix branch / compare URL:

https://github.com/openai/codex/compare/main...trotsky1997:fix-apply-patch-hooks

I attempted to open this as a draft PR, but both gh pr create and the GitHub connector were denied by repository permissions (CreatePullRequest / Resource not accessible by integration). So I cannot submit the PR directly from this environment, but the branch is pushed and ready for maintainers to inspect or open as a PR.

Candidate fix branch / compare URL: main...trotsky1997:fix-apply-patch-hooks I attempted to open this as a draft PR, but both gh pr create and the GitHub connector were denied by repository permissions (CreatePullRequest / Resource not accessible by integration). So I cannot submit the PR directly from this environment, but the branch is pushed and ready for maintainers to inspect or open as a PR.

Thank you very much, I'm looking forward to trying it.

If an agent is allowed to invoke destructive shell commands, then path confusion, stale context, or a simple typo can still lead to unintended deletions. Once the command is issued, recovery often depends on timing rather than guarantees.

A useful pattern is to enforce policies at the tool boundary. Pre execution hooks can inspect every Bash command before it runs and block known dangerous operations regardless of whether they come from the main agent, a sub agent, or a background task. Projects like https://github.com/FailproofAI/failproofai are exploring that approach with policies such as blocking rm -rf before execution.

For matcher compatibility, I would expose two fields instead of choosing only one name.

• raw tool name: apply_patch
• normalized capability: file_write or file_edit

Then existing policy hooks can keep matching the capability class used by Write/Edit, while advanced hooks can target apply_patch exactly.

That matters because raw tool names are not a stable policy surface across providers or host versions. The policy usually wants the capability: this call mutates files before execution. The debug path wants the raw name: this was the internal patch tool. Keeping both makes the fix less brittle than only documenting a new matcher string.

---

_Generated with ax._

This issue highlights an important runtime boundary:

user-facing tool name
≠ semantic side-effect class

A safety policy should not need to know whether Codex performs a file mutation through "Write", "Edit", "Bash", "apply_patch", or an internal patch implementation.

The interception point should be based on the effect being requested:

FILE_MUTATION
PROCESS_EXECUTION
NETWORK_REQUEST
EXTERNAL_APP_ACTION
SECRET_ACCESS

rather than only the internal tool identifier.

A canonical pre-effect event could look like:

{
"schema_version": "pre-effect-event/v0.1",
"event_id": "effect-001",
"event_type": "PRE_EFFECT",
"trajectory_id": "repository-task-123",
"continuation_id": "thread-456",
"actor": {
"agent_id": "codex-root",
"session_id": "thread-456"
},
"effect": {
"class": "FILE_MUTATION",
"operation": "CREATE",
"targets": [
"test.txt"
]
},
"implementation": {
"tool_name": "internal_patch",
"handler": "codex_patch_runtime"
},
"decision": {
"status": "PENDING"
}
}

Plugins could then match the stable semantic class:

{
"matcher": {
"effect_class": "FILE_MUTATION",
"path": "production/**"
},
"decision": "BLOCK"
}

The central invariant would be:

«Every side effect must cross the same policy boundary, regardless of which internal tool or handler performs it.»

A second invariant:

«Adding or renaming an internal tool must not silently create a new path around existing safety hooks.»

This also suggests separating two layers:

tool event
→ describes how Codex attempted the operation

effect event
→ describes what external state would change

One tool invocation could produce multiple effects, while multiple tools could map to the same effect class.

For example:

shell: echo value > file
internal patch tool
IDE write operation
MCP filesystem tool

should all produce a matchable "FILE_MUTATION" event.

A deterministic conformance fixture could test:

1. "Write" tool attempts a file creation → hook fires;
2. internal patch tool performs the same creation → identical semantic hook fires;
3. shell redirection performs the same creation → identical semantic hook fires;
4. protected path policy returns "BLOCK" → no file mutation occurs;
5. allowed path returns "ALLOW" → mutation proceeds;
6. hook failure or timeout follows an explicit fail-open/fail-closed policy;
7. post-effect event contains the actual result and content digest;
8. a newly introduced internal edit tool automatically inherits the same boundary.

The post-effect record could bind the outcome:

{
"event_type": "POST_EFFECT",
"parent_event_id": "effect-001",
"effect_class": "FILE_MUTATION",
"target": "test.txt",
"status": "SUCCEEDED",
"after_digest": "sha256:..."
}

This would also improve replay and auditability because the runtime log would describe actual state transitions rather than only model-facing tool calls.

Related LS work:

• evidence gates:

https://github.com/safal207/LS/issues/595

• commit-before-effect:

https://github.com/safal207/LS/issues/596

• deterministic replay:

https://github.com/safal207/LS/issues/597

• recovered-evidence continuation:

https://github.com/safal207/LS/pull/651

Would a small vendor-neutral "PreEffectEvent" / "PostEffectEvent" fixture help test that all Codex file-mutation paths cross the same blocking policy boundary?

Closing as not reproducible. apply_patch already emits PreToolUse/PostToolUse events, and Write and Edit are explicitly supported matcher aliases. This coverage is present in the reported v0.137.0 release and passes on current main. If the hook still does not fire for a real custom_tool_call: apply_patch, please share a minimal plugin reproduction, the rollout entry, and the exact CLI build.