Make non-managed hook trust reusable across linked worktrees

Resolved 💬 4 comments Opened May 18, 2026 by shawnsw Closed May 19, 2026
💡 Likely answer: A maintainer (abhinav-oai, contributor) responded on this thread — see the highlighted reply below.

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

  1. Create a repo with linked worktrees.
  2. Add a repo-local .codex/hooks.json with a non-managed hook.
  3. Open Codex in worktree A and trust the hook via /hooks.
  4. Open Codex in worktree B for the same repository.
  5. 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.

View original on GitHub ↗

4 Comments

BrennerSpear · 3 months ago

I have the same issue too

Keesan12 · 3 months ago

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.

shawnsw · 3 months ago
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.

abhinav-oai contributor · 3 months ago

Thanks for reporting!! This should be addressed in 0.131.0, LMK if its working now