No trust prompt for project-level hooks causes SessionStart hooks to be silently skipped

Same thing in the CLI on 0.147.0, and there is a second silent step before the one reported here.

This report is about the desktop app. The CLI behaves the same way, and adding a data point because the combination is what makes it hard to diagnose.

Two gates, neither of which says anything

Folder trust decides whether the file is read at all. <repo>/.codex/hooks.json yields nothing until $CODEX_HOME/config.toml marks the project trusted. hooks/list over codex app-server reports hooks: [], warnings: [], errors: []. Isolated with five states, changing one thing at a time:

| config.toml | Hooks discovered |
|---|---|
| absent | 0 |
| present, no projects entry | 0 |
| [projects."<path>"] with no trust_level | 0 |
| trust_level = "untrusted" | 0 |
| trust_level = "trusted" | all of them, source: project |

This is documented behaviour ("Project-local hooks load only when the project .codex/ layer is trusted"), so the gate is not the bug. Reporting nothing is.

Hook trust then decides whether they run, which is what this issue covers. In codex exec that step is quieter still: no prompt exists, none is possible, and the run completes normally with no hook output and no mention that anything was skipped.

Why the pair matters

An installer that writes .codex/hooks.json produces a configuration that reads correctly, passes review, and never executes. From the outside a PreToolUse policy hook that never runs is indistinguishable from one that ran and approved everything, which for a guard is the wrong way round to fail.

What would fix it cheaply

A line on stderr naming the number of hooks skipped and why. hooks/list already computes everything needed, including trustStatus and source, so the information exists at the point where nothing is currently said. Even in codex exec, where no prompt can be offered, one line would turn a mystery into a five-second fix.

For anyone landing here from a search: codex app-server answering hooks/list is the fastest way to see which of the two gates you are behind, and it costs no model tokens.

Correcting my comment above: the interactive CLI does prompt for hook trust. I generalised from the wrong two cases.

I wrote that the hook-trust step goes unannounced. That is right for codex exec and wrong for an interactive session, which I had not actually started until afterwards. On 0.147.0 it prompts at startup, before the first turn:

Hooks need review
1 hook is new or changed.
Hooks can run outside the sandbox after you trust them.

1. Review hooks
2. Trust all and continue
3. Continue without trusting (hooks won't run)

That is a good prompt. It names the risk, it defaults to nothing, and option 3 states the consequence plainly. Apologies for implying it did not exist.

So the accurate version of my earlier comment is narrower, and I think it still supports this issue:

• Folder trust reports nothing anywhere. Until [projects."<path>"] trust_level = "trusted" is set, hooks/list returns hooks: [], warnings: [], errors: [], and no interface mentions that a .codex/hooks.json was seen and skipped. The five-state table in my earlier comment still stands.
• Hook trust is announced properly in the CLI, per the screenshot above. It is not announced in codex exec, which has nobody to ask, and that is the case this issue reports for the desktop app.

The asymmetry is the interesting part. The second gate got a well-designed prompt and the first one got nothing, although the first is the one that hides an entire configuration file.

For what it is worth, once trust is granted the headless path works: codex exec with no bypass flag dispatched both a PreToolUse and a UserPromptSubmit project hook on 0.147.0.