[Remote/mobile] Idle projectless task disappears from Recent Tasks after backing out; pin ignored
What version of the Codex App are you using?
- Codex Desktop for macOS:
26.707.72221(build5307) - Bundle ID:
com.openai.codex - Codex CLI:
0.144.4 - Mobile client: connected through Codex Remote; exact phone OS/client build was not captured
What subscription do you have?
Not included in this public report.
What platform is your computer?
macOS 15.7.4 (build 24G517) on the paired host.
What issue are you seeing?
A real task on the paired Mac repeatedly appears in Codex Remote on a phone while it is active or immediately after it is refreshed, then disappears from the phone's Recent Tasks list as soon as the user backs out of the chat and the task is idle.
The task is not deleted. Immediately after it disappears on the phone, the paired host's thread inventory still returns it with the correct title, working directory, and idle status.
Pinning the task returned success (pinned: true) but did not keep it visible in the phone's task list.
The affected thread:
- has cwd
~/Desktop/aiw landing page - is returned without a
projectId - sits under a saved
~/Desktopparent project - does not have its exact cwd registered as a separate saved project
This makes an intact local project look deleted and prevents the user from reliably returning to the task from a phone. Activity temporarily restores visibility, so the behavior can look like intermittent sync.
Thread and host identifiers are redacted from this public report but can be provided privately.
What steps can reproduce the bug?
- Start or open a task on a paired Mac whose exact cwd is not registered as its own saved project.
- Open Codex Remote on a phone.
- While the task is active, or immediately after sending it a follow-up, observe that it appears in Recent Tasks.
- Allow the task to become idle.
- Open the task on the phone, then back out to Recent Tasks.
- Observe that it immediately disappears.
- Query the paired host's thread inventory by exact thread ID.
- Observe that the thread is still returned as
idlewith the correct cwd. - Pin the thread, repeat the visible -> open -> back out sequence, and observe that it still disappears.
The cycle was reproduced more than once in the same diagnostic session on July 15, 2026.
What is the expected behavior?
- Existing idle tasks should remain discoverable after backing out.
- A pinned task should remain visible even if it has no
projectId. - If project association is required, a thread under a saved parent project should either inherit a stable association or the UI should explain how to register it; it should not silently disappear.
Additional information
Confirmed observations:
- The thread persists on the paired host after the phone stops displaying it.
- Its status is
idlewhen missing. - Its returned summary has no
projectId. - Its exact cwd is absent from saved-project inventory, although its parent
~/Desktopis saved. - Pinning does not keep it in the phone list.
- Project files remain intact; this is a discovery/visibility bug, not data loss.
Working hypothesis: the mobile Remote task-list selector filters out an idle thread whose projectId is absent, and pinned state does not override that filter. Activity temporarily places the thread into a recency/active result set; navigation causes the list to recompute and exclude it again.
Related but not identical: #22806 covers Remote mobile sidebar/pin synchronization. This report adds a deterministic disappearance-on-back-out reproduction for an idle projectless thread, with host inventory evidence that the thread still exists.
A phone screen recording and sanitized desktop log excerpts can be provided if maintainers need them.
3 Comments
Potential duplicates detected. Please review them and close your issue if it is a duplicate.
Powered by Codex Action
Additional reproduction and workaround
I reproduced this on a headless Linux host controlled from the ChatGPT Android app through Codex Remote. The affected conversation was created/used through Remote and behaved as follows:
The host was running Codex CLI/app-server 0.147.0. The important host-side detail was that an existing
codex app-server --remote-control --listen unix://process had been running for days but was not managed by the Codex app-server daemon. Runningcodex app-server daemon bootstrap --remote-controlwhile that process was still alive failed with:The workaround that ultimately fixed persistence was:
codex app-server --remote-controlprocess and itsapp-server daemon pid-update-loopparent.After the app-server was running under the managed daemon and the session had been archive/unarchived, the conversation remained visible after completely leaving Remote and entering it again. The local transcript was never edited or deleted.
This suggests two interacting issues: Remote list persistence can drop an otherwise valid idle thread, and a stale/unmanaged app-server process can prevent the normal daemon/Remote registry from being refreshed. The workaround may be version-dependent, but it resolved the reproduction for me.
Additional macOS Remote reproduction on Codex Desktop
26.803.61601(build6396):This supports a visibility/indexing failure rather than data loss. The controller sidebar was using Priority sorting, which may amplify the disappearance, but a pinned task should remain discoverable regardless.