[Hooks] PreToolUse omits the effective workdir for exec_command and shell_command

Open 💬 2 comments Opened Aug 6, 2026 by mmmprod

What version of Codex CLI is running?

codex-cli 0.146.1, which is the latest stable release at the time of filing.

What subscription do you have?

Not relevant to this local CLI hook-dispatch behavior.

Which model were you using?

Not model-dependent. The behavior is in the CLI tool and hook dispatch paths.

What platform is your computer?

Linux 6.18.33.2-microsoft-standard-WSL2 x86_64 x86_64

Codex doctor report

Not included because this is deterministic local hook payload behavior and is also visible in the tagged release and current main source.

What issue are you seeing?

exec_command and shell_command accept a per-call workdir and correctly use it as the command process cwd. However, their PreToolUse hook payload contains only the command. The top-level hook cwd is taken from the turn context, not from the resolved per-call execution cwd.

As a result, a PreToolUse policy hook cannot distinguish these two calls:

  • the same relative command executed in the session worktree;
  • the same relative command executed in another allowed directory or Git worktree.

The command runs in the requested workdir, but the hook sees the session cwd plus a tool_input containing only the command.

This is not a sandbox escape: the sandbox still enforces its configured writable roots. It is a hook contract gap that prevents correct policy enforcement and audit attribution inside those allowed roots, especially in multi-worktree repositories.

Current main still has the mismatch:

  • exec_command resolves environment_args.workdir into the actual cwd:

https://github.com/openai/codex/blob/74b8f8db93e7a53794b8a190b77d1195097d117e/codex-rs/core/src/tools/handlers/unified_exec/exec_command.rs#L142-L151

  • its PreToolUse payload preserves only args.cmd:

https://github.com/openai/codex/blob/74b8f8db93e7a53794b8a190b77d1195097d117e/codex-rs/core/src/tools/handlers/unified_exec/exec_command.rs#L410-L420

  • classic shell_command also preserves only command:

https://github.com/openai/codex/blob/74b8f8db93e7a53794b8a190b77d1195097d117e/codex-rs/core/src/tools/handlers/shell/shell_command.rs#L253-L257

  • hook_runtime fills request.cwd from turn_context.cwd:

https://github.com/openai/codex/blob/74b8f8db93e7a53794b8a190b77d1195097d117e/codex-rs/core/src/hook_runtime.rs#L165-L185

What steps can reproduce the bug?

  1. Configure a PreToolUse hook for Bash that records its stdin JSON.
  2. Start Codex in repository or worktree A.
  3. Ask Codex to invoke exec_command with:
  • cmd set to a relative write such as mkdir hook-cwd-probe
  • workdir set to another sandbox-allowed directory or worktree B
  1. Observe that the directory is created under B.
  2. Inspect the hook event:
  • cwd still identifies the turn/session directory A;
  • tool_input is only {"command":"mkdir hook-cwd-probe"};
  • the effective workdir B is absent.
  1. Repeat the same command with workdir A. The hook cannot distinguish the effective targets from the supplied cwd and tool_input.

The same contract loss exists in both unified exec and classic shell handlers.

What is the expected behavior?

Before execution, hooks should receive the effective resolved cwd of the command.

Either of these contracts would make enforcement possible:

  1. set the top-level PreToolUse cwd to the resolved per-call execution cwd for shell-like tools; or
  2. preserve workdir in tool_input and document that top-level cwd remains the turn cwd.

The behavior should be consistent for exec_command and shell_command, with regression coverage proving that two identical relative commands using different workdirs produce distinguishable hook inputs.

Additional information

Related but not duplicate:

  • #20879 concerns native apply_patch having no per-call workdir at all.
  • This issue concerns exec_command and shell_command, which do have a per-call workdir and execute there, but omit it from the hook event.
  • #21753 tracks broader hook parity and payload-contract completeness.

A local bridge cannot reconstruct the missing value reliably. Blanket-blocking relative commands or temporary directories would break valid development and test workflows without fixing the contract.

View original on GitHub ↗

2 Comments

CheckPickerUpper · 17 days ago

This is blocking an external policy consumer in oja-gamez/ai-lab (#939): https://github.com/oja-gamez/ai-lab/issues/939

The consumer receives payload.cwd and derives CommandIntent.workingDirectory and projectRoot; it intentionally refuses when cwd is absent rather than guessing a checkout. A Codex session launched in canonical checkout A with exec_command(workdir=B) currently runs in B but sends PreToolUse cwd=A, so the hook blocks legitimate declared-worktree writes and cannot safely distinguish undeclared B.

For this consumer, the safest contract is an explicit effective tool_cwd (or equivalent) field alongside the existing hook-process cwd, preserving absent-vs-explicit semantics. Acceptance is three real client cases: canonical A -> refusal; declared linked worktree B -> allow; undeclared linked worktree C -> refusal, with the exact hook payload and derived projectRoot captured.

T-sanjay-ram · 17 days ago

Hi maintainers — I prepared a fix for this issue and pushed it to my fork:

https://github.com/T-sanjay-ram/codex/tree/agent/expose-pre-tool-workdir

The change exposes a non-empty requested workdir in the PreToolUse Bash-hook input for both exec_command and shell_command, with handler-level coverage.

GitHub currently reports that only repository collaborators may open pull requests to openai/codex, so I cannot submit it from my fork. Could you please advise whether external PRs can be enabled for this contribution, or whether I can be granted the access needed to open the PR? Thank you.