Codex Desktop lifecycle SessionStart hooks are detected but command hooks never execute

Open 💬 3 comments Opened Jul 29, 2026 by maurice85

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

26.721.41059

What subscription do you have?

Pro

What platform is your computer?

Microsoft Windows NT 10.0.26200.0 x64

What issue are you seeing?

User-defined SessionStart lifecycle hooks are detected by Codex Desktop and appear correctly in the Hooks UI, but the configured command is never executed.

The hook is listed under the User Config hooks, its status message is displayed during session startup, but no process is launched and no side effects occur.

This makes SessionStart hooks unusable for startup automation.

What steps can reproduce the bug?

Create a hooks.json file containing a simple SessionStart hook that executes a command (for example, launching PowerShell, Notepad, Calculator, or creating a file).

{
  "hooks": {
    "SessionStart": [
      {
        "matcher": "startup",
        "hooks": [
          {
            "type": "command",
            "command": "powershell.exe -NoExit -NoProfile -Command \"Write-Host 'Hello, World';\"",
            "statusMessage": "Opening PowerShell...",
            "timeout": 30
          }
        ]
      }
    ]
  }
}

Restart Codex Desktop.

Open Settings → Hooks and click Trust for the discovered hook.

Start a new Codex session.

Commands tested include:

powershell.exe -NoExit -NoProfile -Command "Write-Host 'Hello, World'"
cmd.exe /c echo Hook executed > %TEMP%\codex-hook-test.txt
notepad.exe
calc.exe

Observed behavior:

The hook appears correctly in the Hooks UI.
The hook can be trusted.
The configured status message is displayed when the session starts.
None of the configured commands are executed.
No PowerShell window opens.
Notepad and Calculator do not launch.
The test file is never created.

What is the expected behavior?

SessionStart command hooks should execute the configured command when a new session starts.

For the examples above:

PowerShell should open and display the configured message.
Notepad or Calculator should launch.
The test file should be created in the Temp directory.

If the hook configuration is invalid or unsupported, Codex Desktop should display a clear error message instead of silently ignoring the command.

Additional information

Environment:

Windows 11

The hook is marked as Trusted.

The Hooks UI successfully discovers the SessionStart hook and displays it under User Config, including the configured matcher, timeout and status message. This suggests the hook is being parsed correctly, but the command itself is never executed.

I originally discovered this while trying to use a SessionStart hook to trigger the Windows permission prompt for PowerShell before running autonomous tasks. During testing it became clear that no command executes at all, regardless of whether it launches PowerShell, Notepad, Calculator or simply creates a file.

View original on GitHub ↗

3 Comments

MrWarPro · 13 days ago

I can add a related Windows data point from Codex Desktop 26.810.41047 (Windows 11, Node 22.23.2).

A trusted user SessionStart hook was discovered and invoked, but this command failed with exit code 1 and produced no application state update:

"C:\Users\<user>\AppData\Roaming\nvm\agent-crystallize.cmd" hook --harness codex --event SessionStart

The npm-generated .cmd shim itself worked when run manually from both PowerShell and cmd.exe. Replacing only the hook command with a direct Node invocation fixed the lifecycle hook after re-trusting and restarting Codex:

node "C:\Users\<user>\AppData\Local\agent-crystallize\node_modules\@stewie-sh\agent-crystallize\dist\index.js" hook --harness codex --event SessionStart

After that change, the hook exited successfully, updated its state timestamp, and its bootstrap output was injected into the new session. This suggests at least one failure mode is Windows hook command resolution/execution around npm .cmd shims, rather than SessionStart discovery or trust itself.

This is not identical to the original report's "no command executes" behavior, but the direct-Node workaround may help narrow the Windows process-launch boundary.

realpkuasule · 4 days ago

macOS confirmation, Codex Desktop 26.818.41509 (CLI 0.146.0): I reproduced the same failure with a trusted plugin-level SessionStart command hook using an absolute Node runner (so this is not an npm shim/PATH issue).

I created a new Desktop task after the central invitation already existed. The expected formal action was absent: the hook command did not run and no hook/started event for that task appeared in the Desktop log. Repeating after restart gave the same result.

This blocks a reliability-sensitive workflow where an agent must perform one idempotent inbox check on task start/resume. A polling or log-scraping workaround is not acceptable.

Could Desktop either:

reliably dispatch trusted SessionStart hooks for startup and resume; or
expose a documented lifecycle stream/configurable app-server wrapper with at least {threadId, cwd, source}?

Either option would allow a thin, deterministic integration without process interception. No private repository, credential, or user data is required to reproduce this.

Sinisterj12 · 6 hours ago

Independent corroborating reproduction on a newer Windows Codex Desktop build.

Environment

Codex Desktop: 26.825.3734.0
Embedded CLI: 0.150.0-alpha.12.2
OS: Windows
Hook source: trusted saved local Git project's .codex/hooks.json
Exact working directory: C:\Projects\Encor_EOD_Agent

What was verified separately

| Layer | Result |
|---|---|
| Configured | Supported: 11 lifecycle event entries; hook definition and its bootstrap/handler/policy SHA-256 chain were unchanged and structurally valid |
| Configured trust | Supported: project trust was trusted; all 11 expected per-entry trusted_hash records existed with no missing or extra event entry |
| Dispatched | Not observed: the hook's harmless external sanitized state root remained absent |
| Behavior-tested | Not established: later lifecycle cases were stopped after the qualifying native-effect check failed |

Reproduction chronology

Review and trust the exact project hook definition and every current entry.
Fully exit Codex Desktop and verify the previous app-server process ended.
Reopen Desktop.
Create a genuinely new top-level task from the saved project (not a resume, fork, subagent, or folder-only task).
Verify that app task metadata reports the expected saved-project association and exact working directory.
Submit a benign prompt.
Check only whether the hook's sanitized external state root exists.

Observed result: the state root remained absent after SessionStart, UserPromptSubmit, benign tool activity, and SubagentStart.

The task's raw session metadata had no parent, fork, or resume fields. A separate folder-only attempt with the same cwd but no saved-project association was deliberately treated as non-qualifying; the final saved-project task removed that alternative and still produced no effect.

Inference limits

This proves the expected native effect did not occur. It does not identify whether the hidden failure is project-hook discovery, trust loading, dispatch, command launch, suppression, or another lifecycle path, and it does not prove that a handler process launched and failed.

A bounded earlier diagnostic around a pre-restart qualifying task found no bootstrap/handler filename match in correctly time-bounded Windows event logs and no hook-specific structured warning/error. The final post-restart task intentionally did not repeat process/log searches after the qualifying effect check failed.

No raw prompts, credentials, environment dump, unfiltered logs, or command lines are included here.