CLI: first-party completion sound still needed despite hooks / terminal notifications
What variant of Codex are you using?
CLI
What feature would you like to see?
Codex CLI still needs a first-party, curated completion sound / notification experience.
The current hook-based and terminal-based options are useful, but in practice they do not fully solve the problem for long-running CLI turns.
This is not about VS Code / IDE extension support. This is specifically about the Codex CLI.
Why the existing options are not enough in practice:
notifyhooks are flexible, but they push the burden of implementation, OS quirks, permissions, and audio-backend choice onto the user.- Terminal-native paths like BEL / terminal notifications are often too quiet, inconsistent, or limited by the terminal environment.
- Custom hook-based audio solutions can technically work, but the resulting sound experience is often still poor in practice: silent, distorted/crackly, unexpectedly too loud, or otherwise not something I would call a polished built-in solution.
So the real request is a first-party CLI experience for turn-complete audio notifications that is:
- opt-in
- cross-platform
- curated / sensible by default
- distinct from the IDE extension path
- better than "just write your own hook script"
A good solution could still coexist with hooks. Hooks are valuable for custom integrations, but they are not the same thing as a built-in, reliable, user-friendly completion sound in the CLI itself.
Additional information
Context: issue #3962 was clarified by an OpenAI maintainer on April 9, 2026 as being for the IDE extension, with a request to open a separate CLI issue so CLI feedback does not get lost.
Related history:
- #3962 collected both extension and CLI discussion, but is now explicitly scoped to the extension.
- #6210 previously requested an optional sound when a CLI turn ends, but was closed as a duplicate of #3962 before that scoping clarification.
- This new issue is intended to restore a dedicated tracking thread for the CLI side specifically.
If the team would rather track this by reopening or relinking #6210 instead, that would also work for me.
2 Comments
The
tui.notificationsmechanism is intended to be the curated experience and solution here. It works with all terminals, SSH, and remote connections.A custom sound might work for some of these cases, but it wouldn't be a general solution.
Can you explain in more detail why
tui.notificationsis not meeting your needs? Which terminal emulator are you using? Does it support osc9 escape sequences and OS-level notifications? If not, have you considered switching to a terminal emulator that has this support? This should provide the best experience since it uses the notification mechanisms built into the OS, which are generally quite configurable (including sound and visual settings).This feature request hasn't received enough upvotes, so it is being closed automatically. If you still feel this feature is needed, please open a new feature request with an updated title and description.