openai / openai/codex

Codex Desktop: keep completion banners and sounds for one coordinator thread while muting worker threads

Open
#44,105 0 comments 0 reactions 0 assignees View on GitHub

Nobody has claimed this yet.

app enhancement subagent
Dominant language
Rust
Stars
125k
Forks
19.4k
PR merge metrics
PR metrics pending

Description

What variant of Codex are you using?

Codex in the macOS desktop app. This concerns ordinary interactive/local tasks, not scheduled automations, the terminal TUI, or the IDE extension.

The installed Desktop version/build has not been verified. The separately installed CLI was observed as 0.152.1; this must not be treated as the Desktop version. Please identify the current stable Desktop version and any rollout/account restrictions relevant to the capability below.

What feature would you like to see?

I use one coordinator conversation, called “CEO,” to discuss work and receive results from several Task Owner conversations. I want to focus on the coordinator without receiving a separate desktop banner or sound whenever a worker finishes.

The desired behavior is:

Event Desired behavior
An ordinary worker task finishes No desktop banner and no completion sound
The worker reports to the coordinator through the normal supported cross-task route Preserve message delivery, processing, transcript and task state; clarify whether arrival has a separate alert policy
The coordinator finishes processing and presents its result Retain its normal desktop completion banner and sound

The policy should identify the actual selected conversation, not match text in its title or result. A per-thread mute with a coordinator exception would satisfy the use case. A project-level default with an explicit thread override may also work, if supported. Persistence across app launches and newly created worker tasks should be documented.

Please clarify:

  1. Does the current stable macOS Desktop app support per-thread/per-project completion mute, or a notification allowlist containing only one selected thread? Does it cover both banners and sounds?
  2. If supported, what are the exact UI labels/navigation or documented configuration keys, the minimum Desktop version/build, and any plan/rollout restrictions? Is there a supported agent-accessible setting, or is it user-operated only?
  3. Are incoming cross-task report alerts and the coordinator's subsequent turn-completion alerts controlled separately? How can normal reports be preserved while avoiding duplicate presentation?
  4. If unsupported, is there an existing official issue, planned implementation, or released fix we should follow? Please distinguish an accepted plan from a suggestion, and share a public tracking link or version if available.
  5. Is there a supported way to observe which component emitted a completion banner/sound and correlate it to a thread/turn without uploading conversation contents or modifying internal application state?

Additional information

The public notification documentation describes app-level never/background/always completion alerts. It does not establish the requested ordinary-task scope. We do not infer universal lack of support from that omission or from absent fields in the tools available to one session.

The following routes have not established a safe solution:

  • Global notification mute would also remove the coordinator's useful alerts and is unacceptable.
  • tui.notifications / tui.notification_method are terminal controls, not evidence of a Desktop task-level control.
  • Automation-only notificationPolicy behavior does not establish support for ordinary tasks. We do not want to convert ordinary work into scheduled automations.
  • App-server protocol notification opt-out is distinct from desktop banner/sound presentation and must not interrupt reports or task state updates.
  • The existing notify callback invokes the Computer Use component's SkyComputerUseClient turn-ended. Its package includes end-of-turn/lifecycle and lock-screen coordination handling. It has been preserved. Its actual contribution to Desktop banners/sounds has not been established, so we have not filtered, replaced, or manually invoked it.
  • The agent's CUA tool explicitly refuses access to the Codex app for safety reasons. This is not being treated as a macOS Accessibility/Screen Recording permission problem, and no bypass was attempted.

Normal cross-task report delivery and subsequent coordinator processing have been verified. Banner and sound behavior for the three events above remains unobserved; a queue receipt is not notification-delivery evidence. No settings were changed during the investigation.

Related public requests reviewed are #27022 (scheduled automation notifications), #28013 (optional app sounds), and #35516 (relay controls). They concern adjacent scopes and do not by themselves answer this request. We are asking for a supported ordinary-task route, not adopting third-party notifier scripts or asking to stop worker reports.

No real conversation IDs, private paths, account data, transcripts, credentials, or raw logs are included in this draft. If private diagnostics are needed, please specify the smallest necessary fields and a private official channel.

Contributor guide

Open the contributing guide

First steps

  1. Read the whole issue, then the project's contributing guide.
  2. Comment on the issue to say you are picking it up — it saves two people doing the same work.
  3. Fork the repository and make your change on a branch.
  4. Open a pull request that references the issue number.

Research direction

Start with the linked notification documentation and the existing notify callback and Computer Use turn-ended path mentioned in the report. Reproduce worker completion, cross-task delivery, and coordinator completion separately, then document whether banners and sounds can be controlled per thread, including version or rollout limits. Done means a supported configuration or an official tracking reference with the three alert behaviors distinguished.

Written by the indexing model from the issue text.

Assessment

Tech stack
macos
Domain
desktop
Issue type
Feature
Difficulty
5/5
Estimated time
Over a week
Activity status
Active
Clarity
Mostly clear
Newbie friendliness
35/100

Get new issues in your inbox

A short digest of beginner-friendly GitHub issues.