macOS remote Codex app misses unread indicator for completed task marked unread on Linux host #48444

Codex App version

macOS controlling app: 26.924.22138. Linux execution host app: 26.917.71314.

Subscription

ChatGPT Pro.

Platform

macOS: Darwin 27.0.0 arm64 arm. Execution host: Linux desktop app, connected through Codex's remote connection feature.

Issue

An existing task receives and completes a new message on the Linux host. The Linux app reports the task as unread, but the connected macOS app does not show its blue unread dot. The macOS sidebar can show blue dots for other tasks, so the indicator is available in that UI. Reopening the macOS app, reopening the panel, and checking that notifications are set to push do not restore the missing dot. This makes completed background work hard to discover without opening tasks individually.

Reproduction

1. Connect the macOS Codex app to a Linux Codex desktop app using the built-in remote connection feature, signed in to the same ChatGPT account.
2. Pick an existing task that appears in the Mac sidebar but is not open. Before the test, both clients report it as not unread.
3. Send that task one ordinary message using the Codex app's native inter-task messaging tool. Wait for the recipient turn to complete and produce a final response.
4. Without opening the recipient task on the Mac, compare its unread status on both clients and the Mac sidebar. Then reopen the Mac app and panel.

In one controlled test on 2026-09-26, the recipient completed at 09:24:12 UTC. The Linux app's list_threads returned isUnread: true, and its persisted read state included the task. The Mac's persisted read state did not include the task before the test, just after completion, eight minutes later, or after the app was reopened. The Mac sidebar showed no unread dot for that task, while another task did have a blue dot. The user independently confirmed the missing indicator.

Expected

A completed turn that is unread on the execution host should become visibly unread on connected desktop clients, including when the task was not loaded there at completion. Reconnect or reopening should recover the unread state from durable activity/read information. Opening the task should then clear it according to the normal read behavior.

Additional diagnostic evidence

The recipient turn finished successfully, so this is not a delivery or execution failure. The Mac and Linux read-state stores have the same account identity and execution-host scope, but the unread membership did not propagate to the Mac. In the inspected macOS build, the turn/completed handler skips conversations that are not live in that renderer, and sidebar unread presentation depends on client-local saved state. This is a plausible failure path, not proof that this particular completion event was received and dropped. A missed subscription/event versus an ignored event remains unresolved. Please check completion delivery for unloaded remote threads and durable unread reconciliation on reconnect/listing.

There is a separate phone notification concern, but this controlled test did not measure phone in-app unread or push, so it is not claimed as part of this reproduction. I can provide redacted timestamps and diagnostic captures privately if maintainers need them.

Related but different: #20930 concerns desktop completion banners. This report is about the missing unread membership and sidebar dot for a completed remote task, even after reopening the app.