Repository navigation
iOS Codex remote project picker does not mirror Desktop Codex projects #24271
Description
What version of the Codex App are you using?
- Codex App:
26.519.41501(build3044) - Bundled Codex CLI in app:
0.133.0-alpha.1 - Standalone Codex CLI / app-server daemon:
0.133.0 - Host OS: macOS
26.5(25F71),arm64 - Mobile client: ChatGPT iOS app using Codex remote connections, observed through iPhone Mirroring
What subscription do you have?
ChatGPT Pro
What platform is your computer?
macOS arm64 host connected to ChatGPT iOS through Codex remote access.
What issue are you seeing?
When using ChatGPT on iOS to connect to a Mac running Codex Desktop, the mobile Codex project picker does not appear to mirror the projects saved in the Mac Codex Desktop app.
In my repro, a local project saved in Codex Desktop was missing from the iOS project picker, while another project shown on iOS was not present in Desktop Codex's saved project order. This makes the mobile project picker feel like it is using a separate source of truth from the desktop app.
This also appears to block a common Mac mini remote-agent setup: use the Mac mini as the always-on Codex host, then have that Mac connect onward to SSH remote projects that only the Mac can reach. The iOS app asks for a local path instead of exposing the Mac-managed remote project, so there is no usable path to select for a remote project that exists only through the Mac host.
In other words, this workflow does not work reliably:
iPhone ChatGPT app -> Mac mini Codex host -> SSH/VPN/private remote project
The phone should not need direct SSH/VPN access or a local path for the remote project. The Mac host already has the Codex Desktop state, SSH config, keys, network access, and/or VPN access.
What steps can reproduce the bug?
- On the Mac, open Codex Desktop.
- Add/save one or more local projects in Codex Desktop.
- Pair ChatGPT iOS Codex remote connections to that Mac.
- Open the Codex project picker in the iOS app.
- Compare the projects visible in iOS with the projects saved in Codex Desktop.
- Separately, configure a Mac-managed SSH remote connection/project in Codex Desktop, where the Mac can reach the SSH host but the phone may not be able to.
- Try to start or resume that Mac-managed SSH remote project from the iOS app.
I validated the iOS side through iPhone Mirroring. The iOS Codex screen showed the Mac host connected and listed only a subset/different set of projects.
I could not use Computer Use to directly inspect/click inside the Codex Desktop app because the automation layer refused access to com.openai.codex for safety reasons, so I validated the desktop side by reading Codex's local host state instead.
The host state showed saved desktop projects like this, with project names redacted:
{
"project-order": [
"/Users/<user>/Documents/<desktop-only-project>",
"/Users/<user>/Documents/<shared-project>"
],
"electron-saved-workspace-roots": [
"/Users/<user>/Documents/<desktop-only-project>",
"/Users/<user>/Documents/<shared-project>"
],
"codex-managed-remote-connections": [
{
"hostId": "remote-ssh-discovered:<ssh-host>",
"displayName": "<ssh-host>",
"source": "discovered"
}
],
"selected-remote-host-id": "remote-ssh-discovered:<ssh-host>"
}The iOS project picker for the connected Mac host showed:
<mobile-visible-project>
<shared-project>
So the desktop-saved project was missing from iOS, and the mobile-visible project was not part of Desktop Codex's saved project list.
What is the expected behavior?
The iOS Codex project picker should use the Mac Codex host's project state as the source of truth, or the UI should clearly explain that it is not showing Desktop Codex projects.
For local projects saved in Codex Desktop, the iOS project picker should show the same saved projects when connected to that Mac host.
For Mac-managed SSH remote projects, the iOS app should expose those projects as host-backed remote projects instead of requiring the phone to enter a local filesystem path. The phone should be able to say, effectively, "start this project through the connected Mac host," while the Mac handles the SSH connection and filesystem access.
Additional information
This seems related to:
- Mobile Remote Control does not discover SSH remote project threads despite documented remote development environment support #23062
- Codex mobile does not show SSH remote projects from connected Mac host #23527
- Mobile Codex should inherit SSH hosts configured on the paired desktop app #23466
Those issues discuss SSH remote projects not appearing in mobile remote control / mobile needing to configure SSH directly. This issue adds a concrete local-project mismatch: even before SSH remote project routing, the iOS project picker does not appear to mirror Desktop Codex's saved local projects for the connected Mac host.
Possible fix:
- Use the connected Mac Codex host as the authoritative project source for iOS remote connections.
- Include Desktop Codex saved local projects in the host app-server/project discovery response used by mobile.
- Include Mac-managed SSH remote projects as first-class project entries, not as paths the phone has to resolve.
- Preserve project identity across project list, thread list, thread resume, and turn start APIs.
- Render local projects and SSH remote projects distinctly in the mobile picker.
- If Mac-managed SSH remote projects are intentionally unsupported, show that explicitly in the mobile UI instead of presenting a path-entry flow that cannot work for them.
Workarounds:
- For local Mac projects, manually adding a path from the iOS app may make a project appear, but that creates a separate/mobile-origin project entry and does not reliably mirror Desktop Codex's saved projects.
- For SSH remote projects, the current workarounds are using Codex Desktop directly on the Mac, screen sharing into the Mac, configuring direct SSH from the phone if the phone can reach the host and has the right keys/VPN, or cloning/mounting the remote project onto the Mac as a local path.
Activity
github-actions commentedon May 23, 2026
Potential duplicates detected. Please review them and close your issue if it is a duplicate.
Powered by Codex Action
nurdgit commentedon Jun 8, 2026
Codex mobile connects successfully but only shows Chats, not Projects or SSH projects.
Reproduces with Windows host, WSL remote-control host, and Mac mini host.
Stale enrollment reset and re-pairing did not fix it.
Desktop Codex shows the projects; mobile picker does not.
jingweike commentedon Jul 21, 2026
Confirmed a deterministic narrower trigger on Codex/ChatGPT Desktop 26.715.31925 (build 5551), macOS 26.5.2 arm64, Codex CLI 0.144.1.
A project explicitly saved on the host but containing zero Codex tasks/threads is absent from the Remote project picker. After the project receives one local thread, it becomes remotely selectable. A project whose historical threads are all archived remains selectable, so visibility appears to depend on whether any thread record has ever existed rather than whether the project is registered.
Read-only diagnostics:
unavailableHostsis empty.codex doctor --jsonpasses installation, authentication, configuration, network, state-path, and rollout/database-parity checks. Its only failure is the expectedTERM=dumbresult from the noninteractive diagnostic shell.Expected: Remote should mirror the host’s explicitly registered project catalog, including projects with
tasks: [], without scanning or exposing arbitrary filesystem folders.Suggested fix: build the Remote catalog from
registered host projects ∪ thread-derived project buckets; preserve a registered project through zero → one → zero task transitions and remove it only after explicit unregister.Minimum tests:
thread/listremains returned.JoelAlexander commentedon Aug 1, 2026
I can reproduce the desktop/remote project-list mismatch on Windows as well.
Environment
Key trigger
The project appears in the remote-project list only after I initiate a brand-new chat inside that project.
Moving an existing chat into the project does not make the project appear in the remote-project list. This suggests that new-chat creation updates or creates remote project metadata, while the move-existing-chat flow does not perform the same indexing/synchronization step.
Reproduction
Expected
Moving an existing chat into a project should register or refresh that project in the same way as initiating a new chat. The remote-project picker should show the project regardless of whether its first/current chat was newly created there or moved into it.
Actual
The desktop app shows the project after an existing chat is moved into it, but the remote-project list does not. Starting a new chat in the project causes it to appear remotely.
This looks like a missing project-index or synchronization update in the move-existing-chat path rather than general project data loss. It also confirms that the issue is not macOS/iOS-specific; the same behavior occurs with a Windows desktop host.
yuyuyu0170-dot commentedon Oct 19, 2026
Additional reproduction on macOS + ChatGPT iOS, checked on 2026-10-19: registered project display names and grouping differ on mobile in both the existing-chat sidebar and the New Chat project picker.
Environment
26.1013.40934, build20770, production channel. The in-app update check returnedup_to_date.unavailableHosts: [].Observed behavior
Project names below are anonymized where appropriate; no user-specific absolute paths or screenshots are attached.
code-mainThe desktop has six registered local projects. The iOS sidebar also lists historical working-directory names such as
new-chatas projects, even though these are not registered desktop projects. Across the supplied partial screenshots, 19 distinct visible names could all be matched to basenames of existing chats' recorded working directories. This is not a claim about the complete iOS project count.The user separately checked the New Chat project picker on iPhone and confirmed that it also shows the folder basenames rather than the desktop's registered display names. This therefore affects more than the existing-chat sidebar alone.
Read-only host checks
project.A possible diagnostic lead, not a confirmed cause: the installed desktop application's workspace-root-options aggregation adds a project-name label only when
rootPaths.length === 1. The two affected renamed projects contain multiple source folders (two and three respectively), so this particular path produces no display-name label for them. We have not established that iOS consumes this path, and reducing the source-folder list has not been tested as a workaround.Expected behavior
When connected to the same Mac, mobile should use the registered host project identity, display name, and chat membership for both the project picker and existing-chat grouping. Historical working-directory basenames should not replace registered project names or create additional apparent projects solely because old chats retain their working directory.
Please provide a supported synchronization/recovery method, or fix the host/mobile project-discovery and presentation path, while preserving all existing chat transcripts, project membership, working directories, archive states, and file locations. The user does not want to move/rename folders or recreate chats to correct presentation.
The documented iOS 1.2026.223 improvement to the New Thread project picker does not by itself establish that this currently observed name/grouping mismatch is resolved.