[Linux] Every ChatGPT desktop window emits its own turn-complete notification, so one response shows two or three identical notifications

What version of the Codex App are you using (From "About Codex" dialog)?

26.825.51511 (Arch package openai-codex-desktop 26.825.51511-1, ChatGPT desktop app, Electron)

What subscription do you have?

ChatGPT Plus

What platform is your computer?

Linux 7.1.9-arch1-2 x86_64 unknown (Omarchy 4.0.2-1 / Arch Linux, Hyprland, native Wayland with --ozone-platform=wayland)

Arch is outside the documented Linux preview targets (Ubuntu, Debian, Fedora; see #42193 for the Omarchy support request). The evidence below is from the app's own main-process log and does not depend on the distribution: the duplicate calls are issued before any desktop notification daemon is involved.

What issue are you seeing?

With several ChatGPT desktop windows open, one completed response produces two or three identical native desktop notifications.

The duplication happens inside the desktop app before the notification reaches the desktop. The main-process log shows each renderer window handling the same completed turn and the notification service forwarding a native show for each, all with the same turn-derived notificationId:

06:45:54.639  show turn-complete rendererWebContentsId=1  turnId=<TURN_B>
06:45:54.640  forward show kind=turn-complete notificationId=turn-<TURN_B>
06:45:54.640  show notification notificationId=turn-<TURN_B>
06:45:54.646  forward show kind=turn-complete notificationId=turn-<TURN_B>
06:45:54.646  show notification notificationId=turn-<TURN_B>
06:45:54.672  show turn-complete rendererWebContentsId=8  turnId=<TURN_B>
06:45:54.673  forward show kind=turn-complete notificationId=turn-<TURN_B>
06:45:54.673  show notification notificationId=turn-<TURN_B>
06:45:54.679  show turn-complete rendererWebContentsId=18 turnId=<TURN_B>

The desktop notification daemon received those as three separate org.freedesktop.Notifications.Notify calls (ids 97, 98, 99) within 33 ms, with identical app name, summary, body, urgency, icon, image and expiry. No replaces_id was used.

This is not occasional in a multi-window session. In one day's main-process log every one of the 9 completed turns produced 2 or 3 native shows and none produced exactly one (5 renderer web-contents were active). Earlier sessions show the same. An earlier turn also got a third show from another renderer 2 min 15 s after the first two, which looks like a renderer catching up on already-completed state and re-notifying.

What steps can reproduce the bug?

1. Open several ChatGPT desktop windows (in my capture: one main process, four windows on separate Hyprland workspaces).
2. Open conversations or tasks in those windows and leave them visible but unfocused.
3. Start a response or Codex task in one window.
4. Focus another application and wait for the response to finish.
5. Two or three identical native completion notifications appear.
6. In the main-process log (~/.local/state/codex/logs/<yyyy>/<mm>/<dd>/codex-desktop-*-t0-*.log) look for repeated [desktop-notifications] show notification … notificationId=turn-… lines with the same id.

The count varies with how many renderers have the completed turn loaded, but with several windows open it reproduces on every completion.

What is the expected behavior?

One completed turn should produce at most one native notification for the whole app process, however many windows observe the turn-completed event.

The main-process notification service already receives a stable notificationId of the form turn-<turnId>. Making show idempotent per id (or letting one owner decide whether to notify) would fix it without changing the renderers.

Additional information

Evidence, redacted, attached: openai-evidence.zip. The key file is also attached on its own as chatgpt-native-shows-redacted.log. The archive contains:

• chatgpt-native-shows-redacted.log: the relevant main-process records for four completed turns, ids replaced by placeholders;
• check-chatgpt-native-shows.sh: read-only detector that groups native show notification records by notificationId;
• omarchy-history-redacted.jsonl: the corresponding desktop notification daemon records for the three most recent bursts;
• check-omarchy-history-bursts.sh: read-only detector for exact app/summary/body duplicates arriving within one second.

Detector output on the attached log:

duplicate native-show group=1 count=3 first=2026-09-04T06:42:29.955Z last=2026-09-04T06:44:44.932Z
duplicate native-show group=2 count=3 first=2026-09-04T06:45:54.640Z last=2026-09-04T06:45:54.673Z
duplicate native-show group=3 count=2 first=2026-09-04T06:56:57.969Z last=2026-09-04T06:56:57.979Z
duplicate native-show group=4 count=2 first=2026-09-04T07:05:26.299Z last=2026-09-04T07:05:26.312Z

Detector output on the daemon records:

duplicate history burst group=1 count=3 span_ms=33 first_ms=1788504354645 last_ms=1788504354678
duplicate history burst group=2 count=2 span_ms=27 first_ms=1788505017977 last_ms=1788505018004
duplicate history burst group=3 count=2 span_ms=25 first_ms=1788505526311 last_ms=1788505526336

Both exit 1 when duplicates are present. The files contain no conversation text, real conversation or turn ids, account details, hostname, IP address, authentication material or personal paths.

Possibly related: #40482 (Arch Linux/KDE, completion notifications delayed until the app regains focus) and #36169 (macOS, turn-complete banner logged but not shown) both involve the same per-renderer show turn-complete path and its rendererWindowFocused gating.

The desktop side (Omarchy's notification daemon) is separately regaining mako-style grouping of identical notifications (omacom/omarchy#10145), which hides the symptom but does not remove the extra calls.

Start at the desktop notification service's show path and the renderer show turn-complete entry point, using the repeated notificationId=turn-<turnId> log lines as the reproduction signal. Trace how multiple renderers forward the same completed turn, then verify that one completed turn produces at most one native notification across several open windows.