Make non-managed hook trust reusable across linked worktrees
Problem
Codex appears to key non-managed hook trust to the hook source path. In a linked-worktree setup, the same repo-local hook config has a different absolute path in each worktree, so Codex asks the user to review/trust the same unchanged hook repeatedly.
Repro
- Create a repo with linked worktrees.
- Add a repo-local
.codex/hooks.jsonwith a non-managed hook. - Open Codex in worktree A and trust the hook via
/hooks. - Open Codex in worktree B for the same repository.
- Codex asks for hook review again.
Expected
Codex should support a trust scope that can recognize the same repo-local hook across linked worktrees, without letting the project self-trust hooks.
Actual
Each linked worktree requires another manual hook review because the hook source path differs.
Why this matters
Worktree-heavy users often run one agent per branch/task. Re-approving unchanged hooks per worktree adds friction and trains users to click through security prompts.
Suggested fix
Add a worktree-aware trust key for repo-local hooks, for example:
- canonical repository identity
- repo-relative hook config path
- event / group / handler index
- hook command or content hash
Alternatively, allow a user-level trust entry to match linked worktrees for the same canonical repo.
This should preserve the existing security model:
- project config must not be able to mark its own hooks trusted
- changed hook content should still require review
- managed hooks should remain policy-controlled separately
Related issues
I found related but broader/different hook-trust issues before filing:
- #21615 covers a supported way for local installers/wrappers to request trust for installed hooks.
- #21753 is a broad hook parity umbrella.
This issue is narrower: reuse trust for the same repo-local hook across linked worktrees.
4 Comments
I have the same issue too
Path-keyed trust is the wrong abstraction once linked worktrees are normal. The thing users are actually trusting is the hook identity plus content, not the absolute path wrapper around it. A trust key built from canonical repo identity, repo-relative hook location, event, and content hash sounds like the right floor. That preserves the security model while stopping the prompt fatigue that trains people to click through every review.
agreed. it's a nice touch but currently causing me more pain than what it is worth. typical security vs usability conundrum.
Thanks for reporting!! This should be addressed in
0.131.0, LMK if its working now