codex - 💡(How to fix) Fix CLI: first-party completion sound still needed despite hooks / terminal notifications [1 comments, 2 participants]

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:

• notify hooks 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.