[macOS][Activity] New Chat conversations stop syncing while a local Work task is open

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

Unified ChatGPT desktop app 26.901.51231, build 8109, bundle identifier com.openai.codex.

Version/build were read from the installed app's Info.plist.

What subscription do you have?

ChatGPT authentication with ordinary Chat and Work available. Exact subscription tier is omitted from this public report.

What platform is your computer?

macOS 26.6.1; uname -mprs: Darwin 25.6.0 arm64 arm.

What issue are you seeing?

Ordinary Chat conversations available in account history do not appear in the Mac app's Activity view while a local Work task is open. Activity has Work and Chat enabled and Scheduled disabled. Older Chat entries remain visible and local Work entries continue updating.

The observed failure is a stale local Chat catalogue, before Activity's display filtering: five newer ordinary Chat conversations are present in a fresh account-history read but entirely absent from local_thread_catalog. Two older comparison conversations are present in both sources. Conversation titles, IDs, account identifiers, and message contents are omitted here.

Evidence from September 6, 2026 (PDT):

• At 1:09 p.m., the catalogue held 7,415 Chat entries, but its newest Chat source_updated_at and Chat sync watermark remained at 8:57:15 a.m. Chat observation_sequence was 793.
• Local Work catalogue entries continued updating, including at 1:06 p.m.
• A fresh account-history read at 1:14 p.m. returned all seven comparison conversations, with no unavailable sources. The five absent locally had account update times after 9:03 a.m.
• The app log records the Chat update subscription being removed at 9:03:23 a.m., immediately after switching to a local Work route. There was no later mount event in the same app process through the final 1:16 p.m. check.

Sanitized lifecycle excerpt; the first line summarizes the route event, while the second preserves the relevant logged event name:

2026-09-06T16:03:23.833Z  local Work route becomes active sidebar owner
2026-09-06T16:03:23.838Z  chatgpt_conversation_updates_subscription_unmounted

The 8:57 timestamp is the newest Chat data stored locally, not a claimed sync-execution timestamp. The shutdown itself is logged at 9:03. The database was queried read-only; no reset, cache deletion, app modification, or restart was performed during diagnosis.

What steps can reproduce the bug?

The following is a targeted reproduction recipe derived from the observed state and installed implementation; it has not been independently replayed as a controlled end-to-end test:

1. In the unified Mac app, use an account with ordinary Chat and local Work enabled. Let existing ordinary Chat history populate.
2. Use one main window, with no other ordinary Chat viewer keeping the conversation-update subscription mounted.
3. Open Activity, enable Work and Chat, and disable Scheduled.
4. Open a local Work task while leaving Activity visible.
5. On the web, create or update an ordinary, non-temporary Chat conversation in the same account. This must be ordinary Chat, not a local/remote Work task.
6. Check whether it appears in Activity without navigating away. Check the Chat catalogue and chatgpt_conversation_updates_subscription_mounted / _unmounted logs.

Observed-state expectation for the failure: the listener is unmounted, the new ordinary Chat never enters the catalogue, and local Work remains current. Repeat with iOS to check the same account-history path; an independent iOS reproduction was not performed in this investigation.

What is the expected behavior?

Activity should keep receiving new ordinary Chat conversations and updates from other clients while a Work task is open. The Chat checkbox should be sufficient to include eligible ordinary chats. Scheduled tasks should remain hidden when Scheduled is disabled.

Additional information

Suspected root cause, supported by installed code and runtime logs

The Chat conversation-update subscription appears to have the wrong lifetime: it is owned by the ordinary sidebar's Chat history hook and the ordinary Chat viewer, rather than an always-mounted account/app component.

In this exact installed build:

1. app-initial-cadb12d4a15e.js: atom emi (exported as fet) subscribes to the conversations and alder-conversations topics. conversation-created, conversation-history-update, and conversation-turn-complete forward a refresh notification via nV to localThreadCatalog.notifyThread. The cleanup removes handlers and unsubscribes from both topics. The missed-message source-invalidation handler also exists only while this atom is mounted.
2. The named-import consumers found in the packaged JS are the primary app's Chat history capability atom (fet imported as xxe, read by Pgn, mounted by hook Whn) and the ordinary Chat viewer (fet imported as _r, read by iu). The ordinary sidebar component str calls Whn.
3. In parent component Onr, the Activity render branch and ordinary sidebar str branch are mutually exclusive. Activity removes the ordinary sidebar subscription owner. When a local Work task is open, the ordinary Chat viewer does not provide the other owner.
4. Activity initializer D3o calls the catalogue reader's ensurePage. Its loader returns when enough entries are already cached and otherwise reads local catalogue pages. This does not guarantee a fresh account-history source sync, so it does not repair the missed updates.
5. The main-process Chat source dPe provides listPage and readItem, but no independent subscribeNotifications implementation. Local Work has its own notification path, explaining why it can remain current while Chat freezes.

For maintainers locating the exact packaged code, these are zero-based character offsets after UTF-8 decoding:

Bundle	Offset	Anchor
app-initial-cadb12d4a15e.js	5396480	emi, subscription mount and cleanup
app-initial-cadb12d4a15e.js	4744131	nV, catalogue notification
app-initial-cadb12d4a15e.js	8774007	D3o, Activity initialization
app-initial-cadb12d4a15e.js	8136976	ensurePage
app-initial-cadb12d4a15e.js	8139593	Cached-page early return
app-primary-6cd7b8b3f5e3.js	2762526	Subscription read in Pgn
app-primary-6cd7b8b3f5e3.js	6166614	Ordinary sidebar str
app-primary-6cd7b8b3f5e3.js	6210315	Parent Onr render branches
viewer-142e91b0720e.js	18809	Ordinary Chat viewer subscription read
main-BT6ViFC-.js	2560192	Chat account source dPe

This identifies an implementation-level cause consistent with the runtime evidence. It is not a claim that an upstream fix or a controlled reproduction has been validated.

Proposed fix

• Keep the Chat conversation-update subscription mounted at the authenticated app/account level whenever Chat access is enabled, independently of Activity, ordinary sidebar, and Chat/Work route selection. Preserve proper teardown on sign-out or account change.
• On reconnect and when entering Activity after a period without a subscription, request a real Chat source refresh so missed conversations can be recovered. Ensuring existing cached pages are loaded is insufficient.
• Avoid duplicate listeners when ordinary Chat viewers or multiple windows are open; retain the existing shared subscription/ref-count semantics as appropriate.

Suggested regression checks

• Activity + local Work open: create an ordinary Chat from another client and verify catalogue insertion and visible Activity row without navigation.
• Update an existing ordinary Chat remotely and verify Activity ordering refreshes.
• Switch repeatedly between Activity/ordinary sidebar and Chat/Work; verify there is no subscription gap or duplicate listener leak.
• Disconnect/reconnect or suspend/resume; verify missed history is reconciled.
• Repeat with Scheduled off and confirm scheduled tasks remain hidden.

Related issues checked

#36623 and #32565 describe broader Mac/account-history discrepancies; #42176 describes conversations present on a Mac but absent from other clients. This report adds the specific Activity + local Work condition, the subscription lifecycle trace, and a catalogue/account comparison. I did not find an existing issue documenting this listener ownership failure. Happy to consolidate if maintainers identify the same underlying defect.

The diagnosis and this report were prepared with Codex assistance. Only the sanitized observations above are included; raw account history, conversation contents, credentials, and full logs are not attached. Submitting analysis here follows the current contribution policy requesting issue reports and root-cause analysis instead of external PRs.

Start with app-initial-cadb12d4a15e.js at atom emi and nV, then inspect Activity initializer D3o, ensurePage, and the consumers in app-primary-6cd7b8b3f5e3.js, viewer-142e91b0720e.js, and main-BT6ViFC-.js. Trace subscription ownership and cleanup across Activity, Work, and Chat routes; done means Chat updates continue while local Work is open, missed history can recover, and the listed regression checks pass without duplicate listeners.