Skip to content

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

Open
Open
No trust prompt for project-level hooks causes SessionStart hooks to be silently skipped#35306
Labels
appIssues related to the Codex desktop appbugSomething isn't workinghooksIssues related to event hooks

Description

@cccclf
cccclf
opened on Jul 25, 2026

What version of the Codex App are you using (From “About Codex” dialog)?

26.721.31836

What subscription do you have?

When a newly added project contains an untrusted project-level .codex/hooks.json, Codex does not display any prompt or visible notification asking the user to review and trust the hooks when the first session is created. As a result, the hooks are silently skipped. This is particularly problematic for SessionStart hooks because the event has already passed by the time the user discovers the hooks under Settings → Hooks and manually trusts them.

What platform is your computer?

macOS

What issue are you seeing?

When a newly added project contains an untrusted project-level .codex/hooks.json, the Codex desktop app does not display a prompt, warning, or visible notification asking the user to review and trust the hooks when the first session is created.

The untrusted hooks are silently skipped. This is especially problematic for SessionStart hooks because trusting them later through Settings → Hooks does not run the missed event for the existing session.

Expected behavior:

Codex should prompt the user to review project-level hooks before starting the first session, or display a prominent warning explaining that the hooks were skipped because they are not trusted.

Actual behavior:

The session starts normally with no warning. The user only discovers later that the hooks require manual approval under Settings → Hooks.

No error message was displayed.

What steps can reproduce the bug?

1.Create or add a new local project containing .codex/hooks.json.
2.Configure an untrusted SessionStart command hook. For example:
{
"hooks": {
"SessionStart": [
{
"matcher": "*",
"hooks": [
{
"type": "command",
"command": "touch /tmp/codex-session-start-hook-ran"
}
]
}
]
}
}
3.Add the project to the Codex desktop app.
4.Open the project and create its first session.
5.Observe that Codex does not display a trust prompt or a visible warning about the untrusted hook.
6.Check /tmp/codex-session-start-hook-ran and confirm that the file was not created.
7.Open Settings → Hooks. The hook is listed there and requires manual trust.
8.Trust the hook manually.
9.Return to the existing session. The skipped SessionStart hook is not executed retroactively.
10.Create another new session and confirm that the hook now runs.
Environment:
Product: Codex desktop app
OS: macOS
Hook source: Project-level .codex/hooks.json

What is the expected behavior?

Codex should clearly prompt the user to review and trust project-level hooks before starting the first session, or at least display a prominent warning that the hooks were skipped because they are not trusted.

Additional information

No response

Activity

  1. cccclf
    added
    appIssues related to the Codex desktop app
    on Jul 25, 2026
  2. github-actions
    added
    bugSomething isn't working
    hooksIssues related to event hooks
    on Jul 25, 2026
  3. tamkai
    added a commit that references this issue on Jul 31, 2026

    Codexのhook信頼を、飛ばせない手順として明記する

    806bc25

  4. nordscope-fi commented on Aug 9, 2026

    @nordscope-fi
    nordscope-fi
    on Aug 9, 2026

    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.

  5. nordscope-fi commented on Aug 9, 2026

    @nordscope-fi
    nordscope-fi
    on Aug 9, 2026

    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.

  6. timothyfroehlich commented on Aug 30, 2026

    @timothyfroehlich
    timothyfroehlich
    on Aug 30, 2026

    Confirming the same silent failure for user-level ~/.codex/hooks.json, not only project-level hooks.

    Environment

    • Codex Desktop: 26.825.51511
    • Codex CLI used for diagnostics: 0.149.0
    • macOS 26.6.2, arm64

    Reproduction and isolation

    1. A Stow-managed ~/.codex/hooks.json installed three command hooks: SessionStart, UserPromptSubmit, and PostToolUse.
    2. Multiple Codex Desktop tasks started and received prompts/tool calls over several days. Desktop showed no trust prompt, banner, warning, or skipped-hook diagnostic.
    3. The hooks/list app-server request showed all three entries as enabled: true, source: user, and trustStatus: untrusted, with empty warnings/errors.
    4. Trusted project-level Beads hooks in the same tasks continued to execute, so the task appeared healthy. The failure was discovered only after a peer coordination message was known to exist but had never been injected.
    5. Replaying the exact user-level adapter payload manually emitted the missed message, isolating the failure to Codex hook trust/dispatch rather than the hook command.
    6. Starting the interactive CLI later immediately displayed the well-designed Hooks need review screen for all three entries. After the user approved them, hooks/list reported all three as trusted, and the next prompt in the already-running Desktop task injected 13 pending coordination comments, including the originally missed message.

    This makes the Desktop/CLI asymmetry especially confusing: the interactive CLI surfaces the pending trust decision, while Desktop silently runs without the user-level hooks. A prominent Desktop trust prompt would be ideal; at minimum, each affected task should say that enabled hooks were skipped because they are untrusted so a SessionStart event is not silently lost.

  7. linear commented on Sep 23, 2026

    @linear
    linearBot
    on Sep 23, 2026 – with Linear

    from rachita:

    Retested on Desktop 26.917.51856. A modified project hook was skipped pending trust, but no proactive review indicator or warning appeared. Reviewing and trusting it through Settings restored execution. CLI displayed a review warning for the same scenario.

Sign up for free to join this conversation on GitHub. Already have an account? Sign in to comment

Metadata

Metadata

Assignees

No one assigned

    Labels

    appIssues related to the Codex desktop appbugSomething isn't workinghooksIssues related to event hooks

    Type

    No type

    Projects

    No projects

      Milestone

      No milestone

      Relationships

      None yet

      Development

      No branches or pull requests

      Issue actions