Codex mobile notifications stop for older threads; only newly created threads notify, and the first turn is often missed

What issue are you seeing?

Codex mobile notifications become unreliable on existing/older desktop threads. After a thread has been used for a while, iOS stops receiving notifications from that thread entirely, while the Windows or macOS Codex Desktop app continues to show the thread activity and approval prompts normally.

Creating a brand-new thread temporarily restores iOS notifications. However, the first assistant turn in a newly created thread often does not produce a notification either; notifications may begin working only on a later turn.

The behavior has been reproduced with both Windows and macOS desktop hosts, so it does not appear to be specific to Windows lock-screen, sleep, or remote-desktop state.

The following notification/attention events were tested:

• ordinary assistant progress/messages
• turn completion
• user questions
• structured Plan-mode questions with selectable answers
• approval/permission requests

On an affected older thread, iOS received none of these notifications. The desktop host still showed approval requests and allowed them to be handled locally.

A new thread on the same account/device could receive iOS notifications, showing that iOS notification permission and the account-wide push channel were still functional.

What steps can reproduce the bug?

1. Pair Codex Desktop with Codex mobile in the ChatGPT iOS app.
2. Confirm notifications are enabled on iOS.
3. Use an existing desktop thread for multiple turns.
4. With the iOS app backgrounded, trigger several attention states from that thread:

• ask a normal question
• complete a turn
• trigger an approval request
• optionally trigger a structured Plan-mode question

1. Observe that Windows/macOS shows the activity or approval prompt, but iOS receives no notification.
2. Keep the desktop awake and connected, then repeat. The old thread still does not notify.
3. Create a new thread on the same desktop host and send new turns.
4. Observe that iOS notifications begin working again for the new thread, although the first turn is often missed.
5. Return to the older thread and repeat the test. Notifications remain absent there.

What is the expected behavior?

Mobile notification delivery should not depend on thread age or require creating a new thread.

• Existing and newly created threads should reliably notify iOS when a turn completes or needs user attention.
• Approval-needed states should generate a durable mobile notification/attention state.
• The first turn in a newly created thread should be eligible for notification just like later turns.
• Notification state should recover after reconnecting and remain consistent across Windows and macOS hosts.
• Approval notifications should ideally expose actionable Allow/Deny controls on iOS where supported.

What actually happens?

• Older/existing threads stop producing any iOS notifications.
• Desktop notifications and approval UI still work.
• Keeping the desktop awake or connected through remote desktop does not restore notifications.
• Creating a new thread restores notifications temporarily.
• The first turn of the new thread is often not notified.
• Approval requests have repeatedly appeared on desktop without any corresponding iOS notification.

Additional information

Reproduced on June 12, 2026 with:

• Codex Desktop host: Windows, exact app version not captured
• Codex Desktop host: macOS, exact app version not captured
• Mobile client: ChatGPT/Codex on iOS, exact app version not captured
• Same account and mobile device during old-thread/new-thread comparison

This seems related to #25606, which reports missed approval/attention states when mobile is backgrounded or focused elsewhere. This report adds a repeatable thread-lifecycle distinction: an affected older thread remains silent while a newly created thread on the same host/account can notify, and the first turn of that new thread is often missed.

The behavior suggests a thread-scoped notification subscription, attention-state registration, or push routing record may become stale or fail to initialize on the first turn.