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.

Windows validation update on Codex Desktop 26.715.10079.0:

The local PreCompact route is present, discovered, and trusted, but the post-update acceptance check is still RETEST_REQUIRED. I do not have a fresh native Desktop PreCompact receipt plus popup from a throwaway /compact; the latest local receipt is from a direct verification path, not Desktop lifecycle dispatch.

Could maintainers confirm whether this build contains the fix for #21639? If not, the remaining gap appears to be Desktop lifecycle dispatch rather than hook discovery, trust, configuration, or the handler.

Windows reproduction: Desktop 26.721.4979.0 / embedded 0.146.0-alpha.3.1 still does not dispatch trusted PreToolUse hooks

I can reproduce this regression on a current Windows Codex Desktop build. The hook is discovered and trusted, the handler passes direct self-tests for the exact Desktop tool shapes, and the Desktop task was created after the hook definition and trust state were written. Nevertheless, both protected tool actions execute and modify temporary probe files.

Environment

• Codex Desktop package: OpenAI.Codex 26.721.4979.0
• Session metadata:
• originator: Codex Desktop
• source: vscode
• embedded cli_version: 0.146.0-alpha.3.1
• PATH Codex CLI: codex-cli 0.145.0
• OS: Windows 11 Pro x64, build 10.0.26200
• codex features list: hooks stable true
• codex doctor --json: overall status ok; user config loads successfully

Sanitized hook configuration

User-level %USERPROFILE%\.codex\hooks.json contains one PreToolUse group:

{
  "hooks": {
    "PreToolUse": [
      {
        "matcher": "Bash|Edit|Write|apply_patch|shell_command",
        "hooks": [
          {
            "type": "command",
            "command": "python3 \"$HOME/.example/hooks/policy.py\" --platform codex",
            "commandWindows": "py \"<absolute-policy-path>\" --platform codex",
            "timeout": 30
          }
        ]
      }
    ]
  }
}

The corresponding entry under [hooks.state] in %USERPROFILE%\.codex\config.toml has a current trusted_hash. In /hooks, the PreToolUse group is shown as installed/active and was explicitly trusted.

Timing evidence (rules out a stale task snapshot)

Local timestamps were:

1. hooks.json updated: 22:22:31
2. trusted state in config.toml updated: 22:24:19
3. brand-new Desktop task created: 22:26:13

The task therefore started after both installation and trust persistence. Restarting Desktop and creating fresh tasks did not restore dispatch.

Minimal current-session probe

The probe uses only isolated files under %TEMP%\md_live_hook_probe_<random>\; no real project file is involved.

Action 1 — structured file edit

Desktop invoked functions.apply_patch against:

%TEMP%\md_live_hook_probe_<random>\protect\manuscript.md

The policy handler supports both apply_patch and functions.apply_patch, including FREEFORM string payloads. It should return a PreToolUse deny decision for this protected filename.

Observed: the patch succeeded and changed the temporary file. No DENY was surfaced.

Action 2 — shell command

Desktop invoked shell_command to run a deterministic apply script against a pending temporary changeset:

py "<apply-script>" \
  --changeset "%TEMP%\md_live_hook_probe_<random>\gate\swarm\probe_changeset.json" \
  --manuscript "%TEMP%\md_live_hook_probe_<random>\gate\manuscript.md" \
  --allow-no-hooks

The matcher includes both Bash and shell_command, and the policy recognizes shell_command plus namespaced variants.

Observed: the command ran to completion with exit code 0; the temporary changeset was applied. No DENY was surfaced.

Handler controls

The same deployed policy handler was tested directly:

py "%USERPROFILE%\.example\hooks\policy.py" --platform codex --selftest

Result:

OK policy self-test passed

The self-test covers the exact relevant inputs:

• apply_patch with object payload
• apply_patch with FREEFORM string payload
• functions.apply_patch
• Bash
• shell_command
• pending changeset gate denial

Direct evaluation returns deny for both probe actions. This indicates the failure occurs before handler evaluation: discovery/trust succeeds, but the live Desktop tool path does not invoke the handler.

A separate codex exec control on PATH CLI 0.145.0 also allowed the pending temporary changeset to land. I am not using that as proof of the Desktop-specific path, but it is consistent with the other reports here that some non-interactive paths are affected after the trust/dispatch changes.

Expected behavior

Before either tool executes, Codex should dispatch the matching trusted PreToolUse handler and honor its deny result:

• the temporary manuscript.md must remain unchanged;
• the pending temporary changeset must not be applied;
• the user/model should receive the policy denial reason.

Actual behavior

Both temporary writes land successfully. Reinstalling the handler, re-reviewing trust, restarting Codex, restarting Windows, and creating brand-new tasks do not change the result.

This extends the reproduced affected range on Windows to Desktop 26.721.4979.0 / embedded runtime 0.146.0-alpha.3.1.

macOS App Server reproduction: stable codex-cli 0.146.0 still omits PreToolUse and PostToolUse

I reproduced the dispatch failure with the stable @openai/codex@0.146.0 release through the stdio App Server on macOS arm64.

Exact tuple

• Codex package and executable: 0.146.0
• Release tag: rust-v0.146.0
• Host: VS Code 1.130.0, Extension Development Host
• OS: macOS arm64
• Node: 22.23.1
• Transport: app-server --stdio --strict-config
• Thread: ephemeral, read-only sandbox, network disabled
• Web search and MCP servers disabled

Hook configuration shape

• features.hooks=true
• One inline PreToolUse command hook
• One inline PostToolUse command hook
• Matcher *
• --dangerously-bypass-hook-trust
• The command handler is an authenticated local broker that records one-time pre-decisions and terminal post-outcomes.

Controls that pass

• codex --version returns codex-cli 0.146.0.
• Generated App Server JSON schema succeeds: 275 files, stable canonical bundle digest.
• initialize / initialized succeed.
• hooks/list returns both injected hooks with the expected command, matcher, and hashes.
• Repository .codex state is unchanged by the probe.
• The same broker and hook runner pass deterministic complete, missing, duplicate, reordered, replayed, mismatched, cancellation, timeout, IPC, shutdown, audit-failure, and unknown-tool cases.

Real action result

A bounded exact-host turn requested one read-only shell action and one disposable-workspace patch.

{
  "observedSupportedActionCount": 2,
  "expectedPreDecisionCount": 2,
  "preDecisionCount": 0,
  "expectedTerminalPostOutcomeCount": 2,
  "terminalPostOutcomeCount": 0,
  "reconciliationFailure": "missing-pre"
}

The App Server emitted the two supported action items, but the injected handler received neither PreToolUse nor PostToolUse. The client failed closed, withheld the final response, and its read-only sandbox prevented the disposable file mutation.

No credentials, personal paths, raw prompts, raw responses, governed file contents, or raw tool output were captured. This extends the affected range to the stable 0.146.0 App Server path, after successful discovery and trust bypass but before handler dispatch.

macOS VS Code reproduction with same-runtime CLI control (0.146.0-alpha.9.2)

I reproduced the hook-dispatch gap in a fresh VS Code extension thread and then ran a controlled standalone CLI session using the exact embedded Codex binary from that extension.

Environment

• macOS arm64
• VS Code extension: openai.chatgpt 26.727.40816
• Embedded runtime: codex-cli 0.146.0-alpha.9.2
• Hook source: trusted user-level ~/.codex/hooks.json
• Events tested: SessionStart and PostToolUse for apply_patch
• Runtime feature list contains CodexHooks
• Exact current trust hashes exist for both handlers

Fresh VS Code thread - failure

• Session: 019fbc72-947f-7ca3-b4c0-566e53fde46c
• Origin/source: codex_vscode / vscode
• App-server process UUID: pid:59837:9b7dea1f-3772-4b38-959f-f88eafeae38a

Observed:

• No automatic SessionStart developer context.
• An exact SQLite query restricted to target = codex_app_server::outgoing_message returned zero bodies beginning with app-server event: hook/started or app-server event: hook/completed.
• A harmless disposable .sh file was created via apply_patch; PostToolUse produced no lifecycle events, context, or session throttle marker.
• No hook failure, skipped/disabled-hook message, trust-review warning, configuration warning, spill file, or truncation warning.
• The probe was removed.

Standalone CLI control - success

The CLI was launched from the extension embedded binary and reports the same runtime version.

• Session: 019fbc7a-dd55-71c2-95e5-e56938107286
• Origin/source: codex-tui / cli
• Process UUID: pid:63569:a55d3405-10da-4b66-a82e-acb7b5851d2e

Observed:

1. SessionStart

• Real hook/started and hook/completed outgoing-message rows.
• Automatic developer-context message: 13,438 bytes.
• Canon body: 13,345 bytes, approximately 3.3K tokens.
• Body matched the complete expected four-scope output byte-for-byte:

sha256:97093bb4d6df54cacacdbfebc735b8a2f4458e0b579228e48c6e1866f8ae424a

• No spill or truncation.

1. PostToolUse creation via apply_patch

• hook/started log ID 960459.
• hook/completed log ID 960461.
• 3,821-byte coding-instruction context added.
• Session-specific throttle marker created.

1. PostToolUse deletion via apply_patch

• hook/started log ID 961010.
• hook/completed log ID 961011.
• No duplicate context, as expected inside the configured throttle window.
• Probe verified absent afterward.

The same user hook link, configuration, trust state, working directory, and runtime version were used by both surfaces. The handler also passes direct and synthetic controls. The distinguishing variable is the launch surface: TUI dispatches completely, while the VS Code/app-server thread emits no lifecycle events at all.

This appears to place the failure after discovery and trust but before lifecycle dispatch in the VS Code/app-server path. I can provide narrowly filtered, redacted transcript or SQLite rows if useful.

macOS Desktop: plugin trusted, but no lifecycle events dispatch

I can reproduce this with a plugin-installed hook bundle.

Environment

• Codex Desktop: 26.727.51351 (6119)
• Embedded runtime: codex-cli 0.146.0-alpha.9.2
• Platform: macOS arm64
• Hooks installed through an enabled, trusted plugin

Observed

• No delivery for SessionStart, UserPromptSubmit, PermissionRequest, PreToolUse, PostToolUse, or Stop.
• Fresh tasks, continued turns, prompts, and tool calls produce no receiver traffic.
• Restarting Desktop and the companion does not restore delivery.
• Plugin discovery succeeds and Desktop reports the plugin enabled/trusted.
• Codex App Server thread discovery works independently.
• The plugin’s explicit skill command reaches the same local Unix socket successfully.
• Direct synthetic invocation of the installed hook handler also reaches the receiver successfully.
• The receiver’s socket health check passes.

This appears to fail after plugin discovery/trust but before Desktop/app-server lifecycle dispatch. It also shows the regression is not limited to PreToolUse and PostToolUse; even UserPromptSubmit and Stop are absent.

No prompts, responses, transcripts, credentials, command arguments, or raw tool output were captured.