Hooks no longer run after Codex Desktop update

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

• #21615

Powered by Codex Action

It's happened on version 26.506.21252 too

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

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:

``sh
printf desktop-hook-after-restart
``

1. Checked hook logs immediately after:

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

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

1. 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.

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:

https://github.com/openai/codex/issues/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.

same problem on version 26.506.21252

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.

@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?

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.

<img width="1128" height="434" alt="Image" src="https://github.com/user-attachments/assets/b897e9c2-e426-4d68-94c7-9d8cf83b5270" />

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

@abhinav-oai hope it'll also come to VSC extension?

Indexed this hook ticket in the umbrella tracker: #21753

Goal: collect the scattered Codex hook requests and bugs into one parity matrix for Full Claude Code Hook Parity (29+), while preserving this issue as the detailed thread for its specific behavior.

Confirming impact on the codex exec non-interactive CLI path (in addition to the Desktop sessions reported above).

Reproduction — identical config + script, varying only the Codex CLI version:

| Codex CLI | Side-effect file written | additionalContext reaches the model |
|---|---|---|
| 0.128.0 | yes | yes |
| 0.130.0 | no | no |
| 0.131.0-alpha.4 | no | no |

Setup: project-level .codex/config.toml with [features] hooks = true (after the rename from codex_hooks), .codex/hooks.json declares a SessionStart entry, the hook script writes a marker line to /tmp/<file> (side-effect proof) and emits an additionalContext JSON envelope.

On 0.130.0+ Codex emits hook: SessionStart Completed in stderr but the configured command is never invoked — neither the side-effect file appears nor does the model see the additionalContext. So the lifecycle event fires inside the runtime but the dispatch is suppressed.

This is consistent with @jozefizso's note about the new trust UX — the project-level hook is presumably untrusted because there is no interactive TUI session in which to accept it. A few questions for triage:

1. Is the trust gate intentional for codex exec non-interactive sessions, or is the absence of a CLI-side trust mechanism a transient gap until the broader fix lands?
2. Is there a ~/.codex/config.toml / CLI-flag / --enable hooks escape hatch that headless or wrapper-tool users (CI, codexian, OMX) can lean on programmatically while the interactive trust workflow stabilises? The existing [hooks.state."<path>:<event>:0:0"] trusted_hash = "sha256:..." entries look like the underlying mechanism — is the hashing scheme stable enough to expose as a supported CLI surface, or should we wait?
3. Tracking the same regression in dev tooling that wraps Codex CLI: are 0.129 → 0.131 hooks expected to keep failing for codex exec until #21639 closes, even when the user has manually trusted the same hook via the Desktop / TUI path?

Full reproduction script + the 3-version verification record are documented in https://github.com/DSmyungjin/codexian/blob/feat/spec-contract/docs/codex-hook-regression.md for anyone wanting to verify locally in ~5 minutes.

Pinning to 0.128.0 is the workaround we're recommending downstream for now. Happy to test any pre-release fix.

Codex developers should stop deprecating old && adding new features if they keep breaking changes that nobody asked to break. This is very out of profession with these maintainers. Check your PRs before you merge them!

Confirming impact on the codex exec non-interactive CLI path (in addition to the Desktop sessions reported above). Reproduction — identical config + script, varying only the Codex CLI version: Codex CLI Side-effect file written additionalContext reaches the model 0.128.0 yes yes 0.130.0 no no 0.131.0-alpha.4 no no Setup: project-level .codex/config.toml with [features] hooks = true (after the rename from codex_hooks), .codex/hooks.json declares a SessionStart entry, the hook script writes a marker line to /tmp/<file> (side-effect proof) and emits an additionalContext JSON envelope. On 0.130.0+ Codex emits hook: SessionStart Completed in stderr but the configured command is never invoked — neither the side-effect file appears nor does the model see the additionalContext. So the lifecycle event fires inside the runtime but the dispatch is suppressed. This is consistent with @jozefizso's note about the new trust UX — the project-level hook is presumably untrusted because there is no interactive TUI session in which to accept it. A few questions for triage: 1. Is the trust gate intentional for codex exec non-interactive sessions, or is the absence of a CLI-side trust mechanism a transient gap until the broader fix lands? 2. Is there a ~/.codex/config.toml / CLI-flag / --enable hooks escape hatch that headless or wrapper-tool users (CI, codexian, OMX) can lean on programmatically while the interactive trust workflow stabilises? The existing [hooks.state."<path>:<event>:0:0"] trusted_hash = "sha256:..." entries look like the underlying mechanism — is the hashing scheme stable enough to expose as a supported CLI surface, or should we wait? 3. Tracking the same regression in dev tooling that wraps Codex CLI: are 0.129 → 0.131 hooks expected to keep failing for codex exec until Hooks no longer run after Codex Desktop update #21639 closes, even when the user has manually trusted the same hook via the Desktop / TUI path? Full reproduction script + the 3-version verification record are documented in https://github.com/DSmyungjin/codexian/blob/feat/spec-contract/docs/codex-hook-regression.md for anyone wanting to verify locally in ~5 minutes. Pinning to 0.128.0 is the workaround we're recommending downstream for now. Happy to test any pre-release fix.

I even asked GPT to create a script that worked for me locally, for pinning on macOS aarch64:

set -euo pipefail

VERSION="0.128.0"

case "$(uname -m)" in
  arm64|aarch64) CODEX_ARCH="aarch64" ;;
  x86_64|amd64) CODEX_ARCH="x86_64" ;;
  *) echo "Unsupported arch: $(uname -m)" >&2; exit 1 ;;
esac

case "$(uname -s)" in
  Darwin) CODEX_OS="apple-darwin" ;;
  Linux) CODEX_OS="unknown-linux-musl" ;;
  *) echo "Unsupported OS: $(uname -s)" >&2; exit 1 ;;
esac

URL="https://github.com/openai/codex/releases/download/rust-v${VERSION}/codex-${CODEX_ARCH}-${CODEX_OS}.tar.gz"
SHA="$(curl -L "$URL" | shasum -a 256 | awk '{print $1}')"

brew uninstall --cask codex 2>/dev/null || true
brew uninstall --cask codex@0.128.0 2>/dev/null || true

brew tap-new local/codex-pin >/dev/null 2>&1 || true

CASK_DIR="$(brew --repository local/codex-pin)/Casks"
mkdir -p "$CASK_DIR"

cat > "$CASK_DIR/codex@0.128.0.rb" <<EOF
cask "codex@0.128.0" do
  version "${VERSION}"
  sha256 "${SHA}"

  url "https://github.com/openai/codex/releases/download/rust-v#{version}/codex-${CODEX_ARCH}-${CODEX_OS}.tar.gz"
  name "Codex"
  desc "OpenAI's coding agent that runs in your terminal"
  homepage "https://github.com/openai/codex"

  auto_updates true

  depends_on formula: "ripgrep"

  binary "codex-${CODEX_ARCH}-${CODEX_OS}", target: "codex"
  generate_completions_from_executable "codex-${CODEX_ARCH}-${CODEX_OS}", "completion", base_name: "codex"

  zap rmdir: "~/.codex"
end
EOF

brew install --cask local/codex-pin/codex@0.128.0

codex --version

Until Codex's team manages to fix these awful regressions, per your suggestion, pinning to 0.128.0 is a solution.

Additional Windows TUI repro for the hook behavior.

Environment:

• Codex CLI: v0.131.0-alpha.9
• OS/shell: Windows / PowerShell
• Working dir: C:\Claude in C\plans\handoff-evaluation
• Launch path: C:\Users\Local Work\AppData\Local\OpenAI\Codex\bin\76ac88818493fc45\codex.exe
• Run method: TUI launched through a ConPTY wrapper because direct non-PTY launch exits with Error: stdin is not a terminal.

Command shape:

& "C:\Users\Local Work\AppData\Local\OpenAI\Codex\bin\76ac88818493fc45\codex.exe" --no-alt-screen --cd "C:\Claude in C\plans\handoff-evaluation" "Hi — quick check, please look at this fake key sk-test-FAKE-DO-NOT-USE-1234567890abcdef and tell me if it looks fake to you."

Observed result:

• TUI started normally and displayed OpenAI Codex (v0.131.0-alpha.9).
• Prompt was accepted and displayed in the TUI.
• The TUI showed error: hook exited with code 1 twice.
• Despite that, Codex still answered: Yes. Looks intentionally fake: sk-test + literal FAKE-DO-NOT-USE. Treat real keys as secret anyway.
• Session then continued normally and surfaced another startup/checkpoint message, so the hook did not block the response.

Interpretation: partial hook failure. Hook/status text appears, but the assistant still answers a secret-shaped prompt instead of being blocked before answer.

I’m seeing what appears to be the same regression on Windows Server 2025, but with a useful CLI-vs-Desktop split:

• Codex Desktop app version: 26.609.30741
• Packaged app ID: OpenAI.Codex_2p2nqsd0c76g0!App
• Bundled CLI: codex-cli 0.140.0-alpha.2
• CODEX_HOME: C:\Users\Administrator\.codex
• Config: user-level inline hooks in C:\Users\Administrator\.codex\config.toml
• [features].hooks = true
• Each hook includes both command and command_windows

Observed:

• Bundled CLI /hooks discovers the hooks and lets me trust them.
• Bundled CLI fires UserPromptSubmit successfully.
• Codex Desktop GUI Settings > Hooks shows “No hooks found”.
• The Hooks refresh control appears disabled / shows a stop cursor.
• Desktop GUI prompts do not appear to invoke the hook wrapper/debug marker.
• Same config works in CLI.

This looks similar to #18090, except I’m seeing it on current Desktop 26.609.30741 with CLI 0.140.0-alpha.2.

Additional current Windows reproduction: the regression is still present in the July Desktop build / bundled CLI 0.144.

Environment:

• Windows Codex Desktop package: OpenAI.Codex 26.707.8168.0
• Session originator: Codex Desktop
• Bundled CLI reported in rollout metadata: 0.144.0-alpha.4
• OS: Windows
• Hook source: trusted project-level .codex/hooks.json
• Project is marked trust_level = "trusted"
• codex features list reports hooks stable true

Minimal hook configuration:

{
  "hooks": {
    "SessionStart": [
      {
        "hooks": [
          {
            "type": "command",
            "command": "bus hook-context --event session-start --project midterm-reply",
            "timeout": 15
          }
        ]
      }
    ],
    "Stop": [
      {
        "hooks": [
          {
            "type": "command",
            "command": "bus hook-context --event stop --project midterm-reply",
            "timeout": 15
          }
        ]
      }
    ]
  }
}

The hook commands have current trusted_hash entries under [hooks.state] in the user config. The new Desktop task was created after both the hook file and those trust entries were written, so this is not a task-started-before-install case.

Observed in Desktop:

• The first prompt starts normally.
• No SessionStart output is injected as developer context.
• The rollout transcript contains no hook-provided context.
• The local Codex log around thread creation goes directly into the first turn/model request. There is no hook runner, skipped-hook, or hook failure event.
• The turn log nevertheless lists CodexHooks among the enabled features.

Control checks:

1. Directly piping a SessionStart-shaped payload into the command works and exits 0:

'{"session_id":"diagnostic-no-register"}' |
  bus hook-context --event session-start --project midterm-reply

It prints the expected [agent-bus] ... context, so the command, PATH resolution, stdin parsing, and stdout behavior are functional.

1. codex exec --json with the same project config also fails to inject the context on bundled CLI 0.144.0-alpha.4.

1. Repeating the CLI control with both explicit hook enablement and the documented trust bypass still does not execute/inject the SessionStart result:

codex exec --json --skip-git-repo-check \
  --dangerously-bypass-hook-trust \
  -c 'features.hooks=true' \
  'Reply exactly OK.'

The invocation emits the warning that hook trust is being bypassed (twice, corresponding to the configured handlers), but the resulting transcript still has no SessionStart additional context.

This extends the affected-version range to bundled CLI 0.144.0-alpha.4 / Windows Desktop 26.707.8168.0. In this reproduction the project and hook hashes are already trusted, and bypassing trust explicitly does not restore execution, so the failure appears to be after discovery/trust and before or within handler dispatch.

Windows reproduction on current Codex Desktop 26.707.9981.0 / bundled CLI 0.144.2: trusted UserPromptSubmit hook orchestration emits hook/started and hook/completed, but the configured PowerShell script never reaches its first durable marker; stdout parsing and additionalContext attachment are absent. Direct controlled invocation of the same handler succeeds with exit 0 and valid hook JSON. Detailed Windows report: #33564.

Additional current Windows reproduction: the regression is still present in the July Desktop build with a newer bundled runtime.

Environment:

• Codex Desktop package: OpenAI.Codex 26.715.4045.0
• Bundled CLI reported in the affected Desktop session metadata: 0.145.0-alpha.18
• OS: Windows 11 Pro 10.0.26200, x64
• Hooks are configured at user/project scope
• hooks/list reports all 12 configured hooks as trusted, with no warnings or configuration errors
• The affected PostToolUse matcher includes the documented aliases plus the Desktop top-level tool name: Bash|apply_patch|Agent|exec
• The task was created after the latest hook definitions were reviewed and trusted

Observed in a fresh Codex Desktop task:

• No SessionStart context was injected.
• UserPromptSubmit did not provide recovery/binding context.
• No current-session hook state was created.
• Multiple top-level Code Mode exec calls did not trigger PostToolUse or write the expected dirty-turn state.
• Before running diagnostic commands, the rollout contained no hook/started or hook/completed events for these lifecycle hooks.

Control evidence:

• The hook handler and state-write path work when invoked directly.
• The same task handler previously completed an explicit bind successfully.
• Source and installed-cache handler hashes match, and the handler's regression tests pass.
• Re-reviewing trust and expanding the matcher to include exec did not restore Desktop dispatch.

This extends the affected range to Desktop 26.715.4045.0 / bundled runtime 0.145.0-alpha.18. In this reproduction, discovery/configuration and trust checks pass, but the Desktop lifecycle dispatcher does not appear to invoke SessionStart, UserPromptSubmit, or PostToolUse. No session transcript or private paths are attached.

This fits the existing regression report in [openai/codex#21639] (https://github.com/openai/codex/issues/21639):
Additional Windows reproduction for PreCompact hooks:

• Codex Desktop version: 26.715.4045.0
• Platform: Windows
• Project-local .codex/hooks.json
• Hook configuration is enabled, discovered, and reported as trusted
• The configured handler runs correctly when executed directly

Desktop dispatch still does not occur through either path:

1. Manual /compact
2. Automatic in-place compaction

I used a handler that appends a timestamped line to precompact_hook.log and displays a Windows popup. Direct synthetic executions produced both expected outputs. However, neither manual nor automatic Desktop compaction produced a new log entry or popup.
After both live tests, the log remained unchanged at the two synthetic baseline entries, with the newest timestamp:
2026-07-19T11:38:11.032267

This suggests the failure is in Codex Desktop’s lifecycle-event dispatch, rather than hook discovery, trust, configuration, or the handler itself. Automatic compaction also continued within the existing task without firing PreCompact.

I can provide the minimal hooks.json, handler, or additional diagnostics if useful.

Second automatic-compaction reproduction on Windows:

Codex Desktop visibly changed from Context automatically compacting to Context automatically compacted, but remained in the same task and immediately continued substantive work.

There was still:

• No PreCompact hook receipt
• No configured popup
• No injected rollover instruction
• No switch to a fresh task

The live precompact_hook.log remains unchanged at 199 bytes, last modified at 2026-07-19 11:38:11 AM. Its newest entry is still the earlier synthetic manual test:

2026-07-19T11:38:11.032267 event=PreCompact trigger=manual session=codex-verify-0719 action=NOTIFIED

This is another direct automatic-compaction reproduction on Codex Desktop 26.715.4045.0. The UI recognizes and completes compaction, but the PreCompact lifecycle hook is not dispatched.