Hooks no longer run after Codex Desktop update

[skydreamer21]

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

26.506.21252 (The affected sessions report cli_version: 0.129.0-alpha.15 in the rollout metadata.)

What subscription do you have?

Pro

What platform is your computer?

Darwin 25.3.0 arm64 arm

What issue are you seeing?

After updating the Codex Desktop app, hooks configured in .codex/hooks.json no longer appear to run at all.

This is not limited to project-local hook discovery. Both of these hook types are failing:

SessionStart
PreToolUse
Before the update, my project had a SessionStart hook that printed instruction text. Codex Desktop injected that output as a developer message at the beginning of new sessions.

After the update, the same hook configuration no longer runs. The SessionStart hook output is absent from new sessions, and PreToolUse hooks also do not run before tool execution.

This appears to be a regression in Codex Desktop 0.129.0-alpha.15. The same setup worked in sessions using 0.128.0-alpha.1.

What steps can reproduce the bug?

1. In a project, create .codex/config.toml:

[features]
codex_hooks = true

2. Create .codex/hooks.json:

{
  "hooks": {
    "SessionStart": [
      {
        "matcher": "startup|resume|clear",
        "hooks": [
          {
            "type": "command",
            "command": "bash '/absolute/path/to/project/.codex/hooks/session_start_hook.sh'",
            "statusMessage": "Session start hook"
          }
        ]
      }
    ],
    "PreToolUse": [
      {
        "matcher": "Bash",
        "hooks": [
          {
            "type": "command",
            "command": "bash '/absolute/path/to/project/.codex/hooks/pre_tool_use_hook.sh'"
          }
        ]
      }
    ]
  }
}

3. Create .codex/hooks/session_start_hook.sh:

#!/bin/bash
set -euo pipefail

cat <<'EOF'
This is a SessionStart hook instruction.
EOF

4. Create .codex/hooks/pre_tool_use_hook.sh:

#!/bin/bash
set -euo pipefail

echo "PreToolUse hook executed" >&2
exit 0

5. Start a new Codex Desktop session in that project and check the session behavior.

What is the expected behavior?

The SessionStart hook should run, and its stdout should be injected into the session as a developer message, as it did before the update.

The PreToolUse hook should also run before matching tool execution.

Additional information

• Working version: Codex Desktop sessions with cli_version: 0.128.0-alpha.1
• Broken version: Codex Desktop sessions with cli_version: 0.129.0-alpha.15

I also tried copying the same hooks.json content from the project-local path to ~/.codex/hooks.json to check whether the issue was only project-local hook discovery. The observed issue is broader: hooks themselves still do not appear to run.

[github-actions]

Potential duplicates detected. Please review them and close your issue if it is a duplicate.

• Provide a supported way for local IDE/wrapper installers to request trust for installed hooks #21615

Powered by Codex Action

[andrefadila]

It's happened on version 26.506.21252 too

[allenlongbaobao]

not only codex app，but also codex cli latest version 0.129.0

[roberdorfer]

I can reproduce this on macOS with the same Desktop build.

Environment:

• Codex Desktop: 26.506.21252
• Embedded Codex CLI in app: 0.129.0-alpha.15
• PATH CLI: codex-cli 0.128.0
• Platform: macOS / Darwin arm64
• Hooks configured in ~/.codex/hooks.json
• Feature flags in ~/.codex/config.toml include both:
  • codex_hooks = true
  • hooks = true
  • unified_exec = true

What I tested:

1. In Codex Desktop, ran a harmless shell tool call:

   printf desktop-hook-after-restart

2. Checked hook logs immediately after:

   stat -f '%Sm %N' -t '%Y-%m-%d %H:%M:%S' ~/.codex/hooks/*.log
   rg -n 'desktop-hook-after-restart' ~/.codex/hooks/*.log

3. No hook log was updated, and the marker did not appear.

4. Restarted both macOS and Codex Desktop, then repeated the same test. Same result: Desktop tool calls still did not trigger hooks.

Control test:

Running the same hook setup through the CLI does trigger hooks correctly:

codex exec --skip-git-repo-check -c service_tier='"fast"' \
  'Run exactly this shell command and nothing else: printf codex-hook-cli-smoke'

That CLI run emitted:

• SessionStart
• PreToolUse
• PostToolUse
• Stop

And ~/.codex/hooks/budget_guard.log received fresh PreToolUse / PostToolUse entries for:

printf codex-hook-cli-smoke

So this does not appear to be a broken hooks.json, hook script permission issue, matcher issue, or filesystem logging issue. It looks isolated to the Codex Desktop / app-server tool path in sessions running 0.129.0-alpha.15.

One extra detail: the affected Desktop tool call appears as exec_command / Desktop app-server tooling, while the successful CLI hook payload records the tool as Bash.

[Boilerplate4u]

I hit something very similar while trying to figure out why my own hooks were no longer active after updating.

In my case, Codex CLI 0.129.0 warns that [features].codex_hooks is deprecated and that [features].hooks should be used instead. At the same time, parts of the documentation/examples still seem to lag behind or reference the older configuration style.

I opened a broader issue about the release-management/documentation side of this here:

#21682

Your issue looks like a concrete example of why clearer release notes and migration guidance are needed: hook behavior/configuration appears to have changed between versions, but it is not immediately clear from the changelog, prerelease notes, or documentation whether this is:

• an intentional breaking change
• a regression
• a deprecated configuration format
• a required migration from old hook config to new hook config
• or a documentation mismatch

For hooks in particular, this becomes extra painful because they affect automation and security-sensitive behavior. Users should not have to reverse-engineer from warnings, old docs, and trial/error to know what changed.

This would be much easier to handle if prerelease notes and changelogs consistently included concrete before/after migration examples for changes to hooks, config keys, approvals, sandboxing, and similar user-facing behavior.

[peckfly]

same problem on version 26.506.21252

[jozefizso]

We have defined per-repository Codex hooks it the $REPO_ROOT/.codex/hooks.json file.
Hooks are also enabled in the config.toml using the new [feature].hooks = true setting.

Yet, each and every developer must manually go through terminal user interface to trust the hooks.

This is a very bad regression and we obviously commited hooks because our team needs them.

[chibhat-orcl]

@jozefizso

every developer must manually go through terminal user interface to trust the hooks.
Wdym by this? Is there a way to get the hooks running manually? We use VSC extension but wdym by going thru TUI to trust the hooks?

[jozefizso]

Codex v0.129.0 disables all hooks unless developer manually trust them.

⚠ 1 hook needs review before it can run. Open /hooks to review it.

[abhinav-oai]

Thanks for reporting folks, will get a fix out to be able to trust hooks from the Codex App in the next release!