Repository navigation
Notify not getting triggered #8929
Description
Activity
Potential duplicates detected. Please review them and close your issue if it is a duplicate.
Powered by Codex Action
Thanks for reporting.
As a workaround, you might want to try the
tui.notificationsfeature 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 doneIt will continuously beep while codex is not thinking. You can kill and restart it as you please
- Run codex with
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.8xversions. 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.9xversions over the past two weeks, notifications in Windows Terminal have also stopped working.@rayjasson98, I think you're talking about the
tui.notificationssetting, not thenotifyhook that is covered in this thread. The handling oftui.notificationsin WSL did change in recent releases. For details about howtui.notificationsworks, refer to this documentation.Reacted by Ray Jassonthis 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
notifysetting 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
notifyto 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.exewithAdd-Contentcmd.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:
notifyis implemented as anafter_agenthook- on
spawn()failure, the code logsafter_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 theafter_agentnotify path itself may not be running at all.I also noticed that the upstream
notifytest 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.- Codex CLI:
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 ofpwsh.exe/cmd.exealso failing — that's a different, deeper issue and worth tracking separately.Root cause for the
.cmd/.batcasecodex-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::newon Windows usesCreateProcessW, which does not consultPATHEXT. Sonotify = [\"my-notifier\"]where the actual file ismy-notifier.cmd(typical for any npm-global) fails withNotFound— the Rust analog of Node'sspawn EINVALfrom CVE-2024-27980 (cross-ref: copilot-cli#1882).The failure is then swallowed as
HookResult::FailedContinueinlegacy_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-29which::which()to resolvecode→code.cmd#7606 rmcp-client/src/program_resolver.rs:50which::which_in()for MCP stdio launches#3828 cli/src/doctor.rs:108-111hardcoded npm.cmdfor the doctor probe#22967 cli/src/main.rs:678-682wraps update action in cmd /Cfor PATHEXT#6387 The legacy notify hook path was missed.
Proposed one-line fix
Mirror the
external_editor.rsapproach: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'spwsh.exe/cmd.exereport — those should resolve fine since they're real.exefiles. That symptom points at theafter_agenthook not firing at all on native Windows, which warrants a separate investigation.
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 rannpm update -g @openai/codexfor the latest update, and the behavior persisted.What steps can reproduce the bug?
notify = ["bash", "-c", "echo $(date) >> /tmp/codex-notify.log"]to config.tomlWhat is the expected behavior?
No response
Additional information
No response