iOS Codex shows “No tasks yet” while existing conversations remain accessible through search

Problem

Observed November 11, 2026. In ChatGPT for iPhone, the Codex screen shows a connected Mac host with a green status indicator, but the normal conversation/task list is empty. The screen says “No tasks yet” and “Start a task to see it here.”

Existing conversations can still be found and opened through the magnifying-glass search. The user confirms search is currently the only way to find their conversations; they do not appear in the normal list view. The user noticed this after an app update; the exact update that introduced it is not established.

Steps to reproduce in the affected state

Open Codex in the ChatGPT iOS app.
Select the existing connected Mac host.
Observe the empty task list and “No tasks yet” message.
Use search to find an existing conversation.
Observe that the conversation is accessible through search, despite being absent from the normal list.

Expected behavior

Existing conversations should appear in the normal task/conversation list. An empty-state message should not claim there are no tasks when existing conversations are searchable and accessible.

Impact

Normal browsing of conversation history is unavailable. Users must remember searchable words to recover individual conversations, and the empty state makes existing work appear deleted.

Evidence and limits

A user-provided screenshot shows the empty state with a connected host selected.
Read-only inspection of the Mac's local Codex state database found 1,368 thread records, with none marked archived. This includes internal/subagent records and is not a claim that all 1,368 should appear in the mobile list.
Search accessibility is confirmed by the user.
Exact iOS app version, iOS version, desktop app version, and offending thread/list request parameters have not been captured. No root cause is claimed.
No private conversation content, account identifiers, raw logs, or credentials are included.

Possibly related: #25589 reports an empty iOS remote thread list and sourceKinds filtering. This report adds the current search-versus-list discrepancy; the same underlying cause has not been verified.

Same issue here

I'm experiencing the same issue on ChatGPT iOS 1.2026.300.

Remote hosts are visible with their correct connection status.
The main Codex view displays "No tasks yet".
Searching for existing Codex conversations works.
Opening a conversation from search works.
Sending new prompts and receiving responses works normally.

The issue appears isolated to the main task-list view rather than remote connectivity or session execution.

Importantly, this also affects version 1.2026.300, not just 1.2026.307.

Thought i m the only one

I can reproduce the same empty task list on ChatGPT for iOS 1.2026.307 with a Windows 11 / Ubuntu WSL host running Codex CLI 0.167.2. Existing conversations still open from search, and new tasks still run. Signing out and back in temporarily restores the list. Force-quitting and reopening the iOS app reproduced the empty list without a host reboot.

I captured JSON-RPC metadata on the standalone WSL app-server:

During the relaunch that reproduced the empty list, all three iOS initialize requests contained capabilities.experimentalApi: true. The thread/list requests omitted projectId.
On reopening the same host while investigating, the app-server generated successful responses with nonempty data for all six observed thread/list requests. One example used limit: 50, archived: false, useStateDbOnly: true, and sourceKinds: [], and produced a 105,942-byte response.

This capture confirms response generation on the host. It does not establish delivery through the relay or how the iOS app processed those responses. The missing-capability hypothesis discussed in #60799 does not explain this reproduction. Could you check list response delivery and handling on iOS cold-start reconnect?

Experiencing same issue

Experiencing same issue
Only new Chats show up when the mobile session is live. However, it disappears when you refresh/reopen the 📊 or reopen the app

Additional reproducible case on November 12:

iPhone running iOS 27.2 and ChatGPT 1.2026.307.
Linux host running the managed Codex app-server 0.167.2.
Signing out and back into the same ChatGPT account restores the Codex thread list.
Fully closing and reopening the iPhone app makes the list empty again on the same connected host. This was reproduced more than once.
A changed phone process ID independently confirms the app restarted. Host logs show a new connection initializing and making repeated thread/list and threadSection/list requests. The existing conversation can still resume on that connection.
A separate native host thread/list request returns chats. This does not prove the result or delivery of the phone's actual list requests.

Evidence limits:

The installed host's request trace records method, connection ID and request ID, but not the list parameters or response result. A short paired-USB diagnostic read in the failed state confirmed ChatGPT log activity, but the retained error metadata did not identify a list-specific error. No raw logs, conversation contents, account/device identifiers, credentials or pairing material are included here.

The missing experimentalApi explanation in #60799 remains unconfirmed for this case. The capture already posted in this issue reproducing the failure with that capability present is a reason not to assume that explanation.

Could the team investigate persisted remote-session state and list response delivery/handling after an iOS cold start? Is there a supported way to collect per-connection list-result and client-decoding metadata without recording message contents or credentials?

No host restart, pairing reset, database rewrite or application patch was used in this reproduction. Logout/login is a temporary recovery, not a durable fix.

Same issue on ios app and codex on a windows machine. Reinstalling the chatgpt app solved it for 1h, after that the projects list disapeared again.

Another confirmed report from a user on November 13, 2026:

ChatGPT for iOS: 1.2026.307.
Host: Linux, with Codex CLI and the running app-server both at 0.167.2.
The connected host appeared online, but the mobile task list showed “No tasks yet,” including after starting a task from the phone.
Restarting the remote app-server and a reconnection attempt did not restore the list. A read-only local thread/list check returned 24 non-archived threads; the host trace showed mobile list requests, but did not record the mobile requests' parameters or responses.
The user confirmed that signing out of ChatGPT on the iPhone and signing back into the same account restored the list.

We have not tested whether the problem returns after another app restart, and cannot determine the root cause from these observations. Please investigate a durable fix for the mobile task list after reconnecting or restoring an app session.

Account identifiers, host addresses, pairing codes, conversation contents, and raw logs are omitted. Posted at the user's request.

Update: recurrence confirmed (November 13): After the sign-out/sign-in temporarily restored the list, the user reported that the same empty task list appeared again. The action or event that triggered the recurrence has not been established. At the time of the new report, the host service was active, remote control was connected, and a separate read-only local thread/list request returned 26 threads. The host log shows recent mobile list requests but does not capture their parameters or responses. The underlying cause remains unconfirmed.

✅ Workaround confirmed (Windows + iOS)

Logging out of the ChatGPT mobile app and signing back in fixed the issue for me. All Codex Desktop threads are now visible in the Remote tab.

✅ Workaround confirmed (Windows + iOS)

Logging out of the ChatGPT mobile app and signing back in fixed the issue for me. All Codex Desktop threads are now visible in the Remote tab.

This worked once for me, and now the workaround stopped working again. Migrating to Pi as this is completely blocking mobile work.

Additional user reproduction — 14 Nov 2026 (Australia/Sydney)

This is materially disrupting a mobile-first Codex Remote workflow, with the same symptoms as #60799 and related #60561 / #60813.

Environment

ChatGPT for iOS: 1.2026.307; iPhone 17 Pro, iOS 27.2.1
Host: Mac mini running Codex Desktop (host app/macOS build not captured)
Regression first noticed around 11 Nov 2026

Observed

The iPhone Codex Remote task/session list is blank even though existing sessions are present and running on the Mac.
Starting a new Codex task on the phone succeeds: execution continues on the Mac, but the new task also disappears from the iPhone list.
A completion push notification can deep-link into that specific Codex conversation; the conversation can be read and interacted with normally.
Exiting that conversation returns to the empty list. Mac-side work is intact; there is no evidence the threads have been deleted.
Sign-out/reinstall not attempted in this case because other reports show only short-lived relief.

Impact: The iPhone can initiate work but cannot reliably navigate, supervise or resume ongoing remote sessions. This substantially degrades the primary remote-management workflow for a paying Codex user.

Request for engineering triage: Please investigate what happens between the host's thread/list response and the iOS task-list state after reconnection/cold-start: request parameters, relay delivery, response decoding/filtering and UI state hydration. As documented earlier in this issue, a reproduction occurred with experimentalApi: true and the host produced non-empty list responses; missing experimentalApi (hypothesised in #60799) therefore cannot explain every case. A supported privacy-safe diagnostic capture procedure or acknowledgement of ownership would help substantially.

No account IDs, tokens, logs or private conversation content are included.

Same issue here on iPhone 17, iOS 27.1, ChatGPT 1.2026.307, connected to a Linux host.

The overview shows “No tasks yet,” but searching finds existing sessions and opens them normally. Notification links also open sessions successfully. My Mac lists the same host’s sessions correctly. Force-quitting and reopening the iOS app doesn’t help.

Update — 14 November 2026: the Codex Remote session list spontaneously reappeared on my iPhone (ChatGPT iOS 1.2026.307) and has remained available through subsequent use today. Existing sessions are visible again and I can navigate them normally.

I did not sign out/in, reinstall ChatGPT, reset remote pairing or change my Mac mini host setup. I cannot tell whether this reflects a server-side change, staged rollout, or transient recovery.

Current status: working again for me; not confirmation of a global fix. Please keep the reports open if others are still affected. Thanks to everyone sharing diagnostics.

Correction to my 14 Nov recovery report — regression returned on 15 Nov (Sydney time)

I previously reported in #60778 (comment) that the Codex Remote sessions had spontaneously returned. That recovery was not durable. They remained available through Saturday evening/night, but by approximately 06:33 AEDT on Sunday 15 Nov the iPhone session list was blank again, without a reported sign-out/reinstall or Mac-host reconfiguration.

New UI clue from the working period: while the sessions were visible, the ChatGPT iOS app's main sidebar behaviour was noticeably different. Codex sessions were interleaved with normal ChatGPT conversations under the general “Recents” list, rather than only accessible through the dedicated Codex navigation. This morning those Codex entries disappeared from Recents as well, and the dedicated Codex menu once again opens to a blank session list.

This appears to be a recurrence of the same discoverability regression, not a confirmed fix. The correspondence between sidebar/navigation behaviour and session visibility may help differentiate an iOS UI state/feature-flag/configuration issue from a host-side thread/list failure, but I have no telemetry to prove the cause.

Request: Please investigate whether server-driven navigation variants/feature flags, account/session state hydration, or merged Recents-vs-Remote data sources are changing between the working and failing states. If possible, document a privacy-safe way to capture the mobile variant/configuration and list-response result without exposing user data. Existing Mac conversations had not been reported lost.

Status on 15 Nov: issue reproduced again; previous “working for me” report superseded.

iOS list recovered after repairing historical rollout/index inconsistencies — November 14, 2026 (São Paulo; November 15 UTC)

My iPhone reproduced this symptom again: existing Codex sessions were visible, I started a task, and after returning a few seconds later the entire list showed “No tasks yet” while the Mac remained connected. After the host-side historical-index repair described below, I checked the iPhone and confirmed that the normal task list had returned, including recent and older sessions.

Environment

iOS Remote client identified in host logs: codex_chatgpt_ios_remote, version 1.2026.307.
macOS desktop app: 26.1111.21308, build 27194; bundled session runtime recorded 0.169.0-alpha.11.1.
Standalone CLI / codex doctor: 0.169.0.
ChatGPT authentication, default openai model provider.

Evidence before repair

The host received repeated iOS thread/list requests, followed by successful task creation and message submission. Recent sessions still existed on the Mac. The captured host logs did not include the mobile list response payload, so they establish request arrival, not what iOS received or rendered.

codex doctor passed SQLite integrity checks but reported these rollout/state-index inconsistencies:

Check	Before	After repair
Active rollout files missing matching index entries	2	0
Archived rollout files missing matching index entries	1	0
Stale state rows pointing to missing/unusable rollout paths	2	0
Duplicate rollout thread IDs	1	0
Archive-state mismatches	0	0

A separate read of one affected historical session failed with invalid paginated history lineage: missing source rollout.

What was repaired

Two historical state rows pointed to obsolete locations belonging to another local client. Their actual .jsonl.zst files still existed in the canonical sessions directory with matching metadata IDs. The rows were updated to the correct logical .jsonl paths.
Two archived rollouts contained different parts of a conversation but shared one thread identity. The original conversation's state row pointed to the continuation file and contained the continuation's chronological/version/usage metadata. The continuation's original ID had no state row, although its paginated history still existed separately: 5 turns and 562 items.
The original conversation was re-associated with its own rollout and metadata. The continuation's original identity and archived state row were restored. Only structured ownership identifiers in its rollout were corrected. Its inherited parent reference, historical sender identities, free text, and per-line byte lengths were preserved, keeping existing history offsets valid.

This was a narrowly scoped repair with backups, not a database reset or history deletion. Both original files were retained. No host restart, sign-out, re-pairing, or security-setting change was performed as part of the repair.

Verification and limits

codex doctor now reports rollout files and state DB thread inventory agree, with zero missing rows, stale rows, duplicate IDs, or scan errors.
All four affected sessions can now be read through the running desktop app, including the previously failing session and the restored continuation.
Hash comparisons confirm that the affected paginated history records and projection state were unchanged.
I confirmed recovery of the normal iPhone task list afterward; this is an observed recovery, not yet a durability test across subsequent relaunches.

This gives another concrete diagnostic path for this symptom: check rollout/index parity and historical lineage, even when SQLite integrity passes and new tasks still run. It does not prove which inconsistency affected mobile listing, exclude a coincident transient recovery, or establish the root cause of other reports. We did not capture the failing mobile list response, and multiple repairs were applied together.

Could maintainers investigate whether a missing historical rollout or inconsistent fork lineage can cause the mobile list to fail as a whole, and consider a supported, backup-aware index repair plus a visible error instead of an empty-state screen? The identifier repair above was specific to verified local records; it is not a general-purpose SQL workaround.

Related: #60799, #25589. Private conversation contents, account/host identifiers, local paths, screenshots containing project names, and raw logs are omitted.

Deleting the iOS app and re-installing fixed the problem for me.

Navigation Menu

Repository navigation

iOS Codex shows “No tasks yet” while existing conversations remain accessible through search #60778

Problem

Steps to reproduce in the affected state

Expected behavior

Impact

Evidence and limits

Additional user reproduction — 14 Nov 2026 (Australia/Sydney)

Correction to my 14 Nov recovery report — regression returned on 15 Nov (Sydney time)

iOS list recovered after repairing historical rollout/index inconsistencies — November 14, 2026 (São Paulo; November 15 UTC)

Metadata

Assignees

Labels

Type

Projects

Milestone

Relationships

Development

iOS Codex shows “No tasks yet” while existing conversations remain accessible through search #60778

Description

Problem

Steps to reproduce in the affected state

Expected behavior

Impact

Evidence and limits

Activity

Fejm commented on Nov 11, 2026

SteefCKE commented on Nov 11, 2026

joknight commented on Nov 11, 2026

chiragborse1 commented on Nov 11, 2026

kdo82 commented on Nov 12, 2026

transparenceco commented on Nov 12, 2026

aurates commented on Nov 12, 2026

xantoine-dev commented on Nov 12, 2026

titocadavez commented on Nov 12, 2026

linger020 commented on Nov 13, 2026

jamaoui commented on Nov 13, 2026

sunmer commented on Nov 13, 2026

terryhur commented on Nov 13, 2026

Additional user reproduction — 14 Nov 2026 (Australia/Sydney)

flonle commented on Nov 14, 2026

terryhur commented on Nov 14, 2026

terryhur commented on Nov 14, 2026

Correction to my 14 Nov recovery report — regression returned on 15 Nov (Sydney time)

brunocechet commented on Nov 15, 2026

iOS list recovered after repairing historical rollout/index inconsistencies — November 14, 2026 (São Paulo; November 15 UTC)

ryansmith3136 commented on Nov 15, 2026

Metadata

Metadata

Assignees

Labels

Type

Projects

Milestone

Relationships

Development

Issue actions