Codex hooks not running: review, trust and the hooks switch

1. Did you review and trust it?

Codex records trust against each hook's current hash, so new or changed hooks are marked for review and skipped until you trust them. If hooks need review at startup, Codex prints a warning telling you to open /hooks. Plugin hooks work the same way, and if a plugin update changes a bundled script, Codex asks for a new review even when the hook definition is unchanged.

Fix: run codex in that project and type /hooks inside the session to inspect each hook's source and command, then trust it (it isn't a shell command like codex /hooks). In the desktop app, use Review hooks in the composer or Settings › Hooks. Restarting sessions that were already open is the safe bet.

--dangerously-bypass-hook-trust runs enabled hooks without persisted trust for that one invocation. Use it only for hooks you wrote and are testing, never for ones you haven't read.

2. Are hooks switched off?

Hooks are on by default, but hooks = false under [features] in ~/.codex/config.toml turns all of them off. The old name codex_hooks still works as a deprecated alias. In this state Codex doesn't load hooks at all, so /hooks has nothing to trust (checked on codex-cli 0.163 and 0.166).

Fix: delete that line or set hooks = true, then restart Codex. If you use a separate CODEX_HOME, check the config.toml there. Trust is recorded in that Codex home's config too, so a different CODEX_HOME needs its own review.

3. Is a managed policy blocking it?

If an administrator sets allow_managed_hooks_only = true in requirements.toml, Codex skips user, project, session and plugin hooks and loads only managed ones. Managed hooks are trusted by policy and can't be turned off from the user hook browser. There's nothing to fix on your machine; ask your administrator.

4. Is it a project hook?

Hooks in <repo>/.codex/hooks.json load only when that project's .codex/ layer is trusted. User and system hooks still run in untrusted projects. If one layer has both hooks.json and an inline [hooks] table in config.toml, Codex merges them and warns at startup.

When Codex won't start at all

If config.toml still has approval_policy = "untrusted", current Codex exits right away with approval_policy = "untrusted" is no longer supported; remove this setting (checked on codex-cli 0.163 and 0.166). Delete the line or change it to on-request.

With Lidnight

When you connect Codex, Lidnight shows the exact Lidnight hooks Codex will run (command, timeout, hash) and trusts only those, only when you press the button (through the official codex app-server; other tools', projects' and plugins' hooks are left alone). If hooks are switched off, it shows why and, after you confirm, turns on just that one line (undoable); if a managed policy is the reason, it says so. If Codex can't start because of a settings error, it shows the first line of that error.

Checked 2026-11-07 against OpenAI's Codex ‘Hooks’ docs (learn.chatgpt.com/docs/hooks) and runs of codex-cli 0.163 and 0.166. Things change; check the docs.