Notify not getting triggered

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

• #8189

Powered by Codex Action

Thanks for reporting.

As a workaround, you might want to try the tui.notifications feature documented here.

I have a bad workaround that definitely works:

1. Run codex with tmux new-session -d -s codex 'codex'
2. Attach to the tmux session (tmux a)
3. In another terminal, you can just directly paste this into your shell:

#!/bin/bash
NOTIFIED=0
while true; do
    SCREEN=$(tmux capture-pane -t codex -p 2>/dev/null)
    if echo "$SCREEN" | grep -q "esc to interrupt"; then
        NOTIFIED=0
    elif [[ $NOTIFIED -eq 0 && -n "$SCREEN" ]]; then
        # Beep repeatedly until state changes
        while true; do
            powershell.exe -Command "[console]::beep(1000,300)"
            sleep 3
            NEW_SCREEN=$(tmux capture-pane -t codex -p 2>/dev/null)
            if echo "$NEW_SCREEN" | grep -q "esc to interrupt"; then
                break  # Work resumed, stop beeping
            fi
        done
        NOTIFIED=1
    fi
    sleep 1
done

It will continuously beep while codex is not thinking. You can kill and restart it as you please

yep definitely recent regression. not making any major changes, assuming this will go back to as-was?

@aavetis, do you happen to know which version of the Codex CLI this regression started? If so, it could help us track down the problem more quickly.

i am always auto updating; i noticed it a couple days ago. must have been .77 then, as reported above. because we're already on .79 and i still see the issue

Can we rollback to say, .76? This is a pretty massive regression in UX; I assume most people rely on notifications to optimize their productivity, given the long iteration cycles.

Hi, I don’t have the exact version information, but I started using Codex around the 0.8x versions. I’ve been using the default notification configuration without any customization. Notifications did not work in VS Code when opened in a WSL environment, although they did work when using WSL/Ubuntu sessions via Windows Terminal.

After upgrading to the 0.9x versions over the past two weeks, notifications in Windows Terminal have also stopped working.

@rayjasson98, I think you're talking about the tui.notifications setting, not the notify hook that is covered in this thread. The handling of tui.notifications in WSL did change in recent releases. For details about how tui.notifications works, refer to this documentation.

this should be fixed, confirmed in 0.98. i was just chatting with codex and heard the notification i used to hear and thought, hey that's a sound i haven't heard in a while :)

I’m seeing a very similar issue in my environment as well, but in native Windows rather than WSL.

What I confirmed:

• Codex CLI: 0.120.0
• Platform: Windows
• The notify setting is accepted and Codex starts normally
• However, after a turn completes, there is no sign that the configured notify command actually ran

I reproduced this with very minimal commands. For example, I configured notify to run a simple file-append command, but after a completed turn the file was never created or updated.

I tested both of these forms:

• pwsh.exe with Add-Content
• cmd.exe /c echo complete>>...

In both cases, the Codex UI appeared to complete the response and return to the input prompt, but there was still no trace that the notify command had executed.

I also checked the source:

• notify is implemented as an after_agent hook
• on spawn() failure, the code logs after_agent hook failed; continuing
• but in my environment I could not find that warning in the internal Codex log either

So in this case, it does not look like a simple spawn() failure. It looks more like the after_agent notify path itself may not be running at all.

I also noticed that the upstream notify test seems to exclude Windows, so there may still be a Windows-specific gap here.

This may not be WSL-specific. There may be a broader Windows-side issue affecting notify.

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.

Adding a code-level root cause for one specific manifestation of this bug on Windows — the case where notify[0] is an npm-installed shim (.cmd/.bat). This does not explain @zio3's report of pwsh.exe/cmd.exe also failing — that's a different, deeper issue and worth tracking separately.

Root cause for the .cmd/.bat case

codex-rs/hooks/src/registry.rs:225:

pub fn command_from_argv(argv: &[String]) -> Option<Command> {
    let (program, args) = argv.split_first()?;
    if program.is_empty() { return None; }
    let mut command = Command::new(program);   // no PATHEXT lookup on Windows
    command.args(args);
    Some(command)
}

Command::new on Windows uses CreateProcessW, which does not consult PATHEXT. So notify = [\"my-notifier\"] where the actual file is my-notifier.cmd (typical for any npm-global) fails with NotFound — the Rust analog of Node's spawn EINVAL from CVE-2024-27980 (cross-ref: copilot-cli#1882).

The failure is then swallowed as HookResult::FailedContinue in legacy_notify.rs:65, which matches the \"silently broken\" symptom.

Why this looks like a missed sweep

Codex already applied this exact fix in four other spawn sites:

| Path | Fix | PR |
| --- | --- | --- |
| tui/src/external_editor.rs:25-29 | which::which() to resolve code → code.cmd | #7606 |
| rmcp-client/src/program_resolver.rs:50 | which::which_in() for MCP stdio launches | #3828 |
| cli/src/doctor.rs:108-111 | hardcoded npm.cmd for the doctor probe | #22967 |
| cli/src/main.rs:678-682 | wraps update action in cmd /C for PATHEXT | #6387 |

The legacy notify hook path was missed.

Proposed one-line fix

Mirror the external_editor.rs approach:

pub fn command_from_argv(argv: &[String]) -> Option<Command> {
    let (program, args) = argv.split_first()?;
    if program.is_empty() { return None; }
    #[cfg(windows)]
    let program: std::path::PathBuf =
        which::which(program).unwrap_or_else(|_| std::path::PathBuf::from(program));
    let mut command = Command::new(&program);
    command.args(args);
    Some(command)
}

This fixes the notify = [\"my-notifier\"] case but, again, won't address @zio3's pwsh.exe/cmd.exe report — those should resolve fine since they're real .exe files. That symptom points at the after_agent hook not firing at all on native Windows, which warrants a separate investigation.