[Hooks] PreToolUse omits the effective workdir for exec_command and shell_command
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:
- its PreToolUse payload preserves only args.cmd:
- classic shell_command also preserves only command:
- hook_runtime fills request.cwd from turn_context.cwd:
What steps can reproduce the bug?
- Configure a PreToolUse hook for Bash that records its stdin JSON.
- Start Codex in repository or worktree A.
- 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
- Observe that the directory is created under B.
- 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.
- 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:
- set the top-level PreToolUse cwd to the resolved per-call execution cwd for shell-like tools; or
- 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.
2 Comments
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.cwdand derivesCommandIntent.workingDirectoryandprojectRoot; it intentionally refuses when cwd is absent rather than guessing a checkout. A Codex session launched in canonical checkout A withexec_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-processcwd, 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.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
workdirin thePreToolUseBash-hook input for bothexec_commandandshell_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.