Notify not getting triggered

What version of Codex is running?

codex-cli 0.77.0

What subscription do you have?

Plus

Which model were you using?

No response

What platform is your computer?

Windows/WSL

What issue are you seeing?

I noticed that Windows notifications were no longer popping up when codex was done thinking. I then went into WSL's ~/.codex/config.toml, and added notify = ["bash", "-c", "echo $(date) >> /tmp/codex-notify.log"]. The file was never written to, so it seems like codex is no longer triggering notify. The terminal was not in focus for these tests. The behavior began midway through today, an hour into my session. I was using codex-cli 0.77.0, then ran npm update -g @openai/codex for the latest update, and the behavior persisted.

What steps can reproduce the bug?

Install codex in WSL2 - Ubuntu
Ask codex anything which takes some time to think about (I asked it: "parameterize the vectors in the tangent bundle of the torus")
Immediately navigate away from the terminal
Add notify = ["bash", "-c", "echo $(date) >> /tmp/codex-notify.log"] to config.toml
Repeat steps 2 & 3. Observe that /tmp/codex-notify.log is still empty.

What is the expected behavior?

No response

Additional information

No response

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

WSL2: notifications/notify hook often fails for approval prompts; add Windows-native toast backend #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:

Run codex with tmux new-session -d -s codex 'codex'
Attach to the tmux session (tmux a)
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

@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

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

@zio3

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.

Navigation Menu

Repository navigation

Notify not getting triggered #8929

What version of Codex is running?

What subscription do you have?

Which model were you using?

What platform is your computer?

What issue are you seeing?

What steps can reproduce the bug?

What is the expected behavior?

Additional information

Root cause for the `.cmd`/`.bat` case

Why this looks like a missed sweep

Proposed one-line fix

Metadata

Assignees

Labels

Type

Projects

Milestone

Relationships

Development

Notify not getting triggered #8929

Description

What version of Codex is running?

What subscription do you have?

Which model were you using?

What platform is your computer?

What issue are you seeing?

What steps can reproduce the bug?

What is the expected behavior?

Additional information

Activity

github-actions commented on Jan 8, 2026

etraut-openai commented on Jan 8, 2026

AdamJamil commented on Jan 8, 2026

aavetis commented on Jan 9, 2026

etraut-openai commented on Jan 9, 2026

aavetis commented on Jan 9, 2026

AdamJamil commented on Jan 9, 2026

rayjasson98 commented on Feb 4, 2026

etraut-openai commented on Feb 4, 2026

aavetis commented on Feb 10, 2026

zio3 commented on Apr 12, 2026

oxysoft commented on May 8, 2026

ccstr commented on May 19, 2026

Root cause for the .cmd/.bat case

Why this looks like a missed sweep

Proposed one-line fix

Metadata

Metadata

Assignees

Labels

Type

Projects

Milestone

Relationships

Development

Issue actions

Root cause for the `.cmd`/`.bat` case