›_ Codex Issues
Codex Issues / #35972

Codex Mobile Remote project assignment does not reconcile with Desktop project assignment

Open 💬 4 comments Opened Jul 29, 2026 by xiaoxuesheng123467

Summary

When using Codex Mobile Remote connected to a desktop Codex host, a project/task created from the mobile Remote UI can appear as a project on mobile, but the same work appears on desktop only as a standalone/ordinary conversation rather than as a chat inside the corresponding desktop local project.

If the user then creates the matching project on desktop and moves or continues the conversation there, the original mobile-visible project shell remains on mobile. It does not appear to merge, disappear, or update to reflect the desktop-side project assignment.

This creates two visible project-like entry points for the same body of work and becomes confusing over time.

Important clarification

This report is specifically about ChatGPT mobile app > Codex Remote / Remote connection controlling a desktop Codex host. It is not about ordinary ChatGPT mobile projects.

Remote should use the connected host's projects, chats, files, credentials, permissions, plugins, and local tools. The issue is that the mobile Remote project/list projection and the desktop project assignment appear to diverge.

Reproduction pattern

Exact app versions were not captured, but the user-visible flow is:

  1. Open Codex Mobile Remote on the phone and connect to a desktop Codex host.
  2. From the mobile Remote UI, create a new project/task.
  3. On the phone, the new item is displayed as a project.
  4. Open Codex/Desktop on the connected computer.
  5. The same work appears as a normal standalone conversation, not as a chat under a desktop local project.
  6. On desktop, create the corresponding local project and move/continue the conversation there.
  7. Return to the mobile Remote UI.
  8. The original mobile-created project shell is still visible on mobile instead of being merged, removed, or reassigned to the desktop project.

Actual behavior

  • Mobile Remote displays a project-like item.
  • Desktop displays the same work as an ordinary conversation or under a different project context.
  • Creating the corresponding desktop local project does not reconcile the mobile project shell.
  • Moving/continuing the conversation in the desktop project does not update or remove the stale mobile project entry.
  • The user has to manually rename, archive, or ignore the stale mobile-side project shell.

Expected behavior

Codex Mobile Remote and Desktop should converge on one authoritative project assignment for work running on the connected host.

At minimum:

  • A project/task created from Mobile Remote should clearly indicate whether it is backed by a desktop host project, a local folder, a worktree, or is standalone/unassigned.
  • If the corresponding conversation is moved into or continued from a desktop local project, Mobile Remote should update the project assignment and stop showing the stale mobile-only project shell.
  • If automatic reconciliation is not supported, the UI should expose a supported manual action such as Move to desktop project, Merge duplicate project shell, or Remove stale Remote project shell.
  • The same work should not silently appear as a project on one surface and an ordinary conversation on another.

Why this matters

For users who frequently start or steer work from mobile, the current behavior makes project organization unreliable:

  • work accumulates under duplicate project-like entries;
  • users cannot tell which project has the real local folder/repository context;
  • older mobile-created project shells remain visible after the user has already reorganized the work on desktop;
  • long-running projects become hard to navigate and audit.

The underlying transcripts do not appear lost, but project discoverability and assignment are confusing.

Related issues

This looks related to the broader Mobile Remote / Desktop project and thread indexing family:

  • #24462 - Mobile Remote briefly shows a local project/thread, then removes both after sync
  • #24464 - Codex mobile thread list loses visibility after desktop resume on same host
  • #34076 - Codex desktop loses local project registrations and hides active threads while CLI/core database remains healthy
  • #31623 - Mobile remote: group Git worktree sessions by repository instead of exact cwd
  • #34499 - Cannot create a local Work chat inside a ChatGPT Project (Windows Desktop App)
  • #27243 - Windows path normalization can make project folders show "No chats"

This report is not exactly the same as those: the specific user-visible problem is a mobile Remote-created project shell remaining separate after the user creates/reconciles the corresponding project on desktop.

View original on GitHub ↗

4 Comments

geauxtigers · 29 days ago

I can also confirm that a remote connection to an existing CLI session creates a separate conversation context. The remote session initially appears to inherit the CLI session’s current context, but subsequent messages sent remotely do not appear in the CLI terminal and are not persisted in that CLI conversation. Remote connect should attach to the same underlying conversation/session, synchronizing messages and context both ways. thread ID: 019fb106-6a01-72a2-9ca6-fc63b0bf777a

4918studios · 13 days ago

I can reproduce a closely related and very clean variant of this on macOS Desktop + ChatGPT mobile Remote:

  1. An existing Codex thread is initially in Project A on Codex Desktop (macOS).
  2. Mobile Remote correctly sees that thread under Project A.
  3. On Desktop, use the UI to move the existing thread from Project A to Project B.
  4. Desktop immediately and correctly shows the thread under Project B, with Project B's folder/context.
  5. Return to ChatGPT mobile Remote.

Actual: the same thread remains associated with Project A on mobile Remote. This is not just a display/organization issue: Remote therefore cannot use the new Project B folder/context for that thread.

Expected: once Desktop reassigns the thread to Project B, Remote should reflect the same authoritative project assignment and load Project B's context/folders.

Troubleshooting already attempted without fixing the stale association:

  • revoked Remote authorization and re-authorized/re-paired;
  • completely uninstalled and reinstalled the mobile ChatGPT app.

The stale project association survives both, which suggests the mapping may be persisted upstream / in Remote project-thread metadata rather than only in a mobile cache.

A useful diagnostic may be to compare the project/cwd identity returned for the same thread ID through Remote before and after a Desktop project reassignment.

frogfarewell · 6 days ago

I can reproduce this on Windows Codex Desktop 26.818.5229.0 with ChatGPT mobile Remote, and the local state provides a concrete explanation for the stale assignment.

Reproduction and state evidence

  1. Create a thread in local Project A.
  2. On Desktop, move that thread into local Project B.
  3. Desktop correctly shows the thread under Project B and applies Project B's working folder.
  4. Open the connected host in ChatGPT mobile Remote.

Actual: Mobile Remote still groups the thread under Project A's original directory. Project B shows only threads that were originally created there.

For the moved thread, the Windows host state showed:

  • the Desktop thread-project-assignments entry pointed to Project B;
  • the Desktop applied workspace state had cwd = <Project B root>;
  • its runtime workspace roots included both Project B and the original Project A root;
  • but the rollout's immutable session_meta.payload.cwd still contained Project A's original root.

Mobile Remote followed the original session_meta.payload.cwd, not the current Desktop project assignment/applied workspace. This strongly suggests that Remote project/thread grouping is keyed by the thread's creation-time cwd rather than the authoritative current project assignment.

I also confirmed the same behavior with an older thread whose original cwd was a parent workspace directory. Although Desktop had since assigned that thread to a named local project, Mobile Remote continued to expose a stale top-level workspace project containing that thread.

Additional project-discovery observation

A newly created local Project B used an initially empty folder. It did not appear in Mobile Remote. After adding a README file to that folder, the project appeared in Mobile Remote without re-pairing the device. This suggests that empty local project folders may be omitted from Remote discovery.

Why this is high impact

A common workflow is:

  1. explore architecture and tool integrations in one or more ChatGPT/Codex conversations;
  2. create a durable local project once the work becomes concrete;
  3. move the relevant conversations into that project so they share the intended project organization, files, instructions, and context;
  4. continue or steer that project from Mobile Remote.

Today, Desktop shows the reorganized structure, while Mobile Remote reconstructs the old creation-time structure. Projects can therefore appear empty, contain conversations that were moved elsewhere, or leave stale parent-workspace shells behind. Multi-folder desktop projects compound the problem because Remote currently presents only one folder.

Expected behavior

Desktop's current project assignment should be authoritative across Desktop and Mobile Remote. After a thread is moved:

  • Remote should group it under the destination project;
  • Remote should use the destination project's primary/current workspace context;
  • stale source-project or parent-workspace shells should disappear when they no longer contain currently assigned threads;
  • the original cwd may remain as historical provenance, but should not override the current project assignment.

If automatic reconciliation is intentionally unsupported, the UI needs an explicit supported action to re-home/reconcile a thread for Remote.

qijiu79-79 · 4 days ago

I can reproduce this on the current macOS ChatGPT/Codex desktop app and ChatGPT iOS Remote. This is a privacy-scrubbed report; no screenshots, project names, local paths, host names, account identifiers, thread IDs, or raw logs are included.

Environment

  • ChatGPT/Codex desktop for macOS: 26.818.41705 (build 6971)
  • Bundled Codex CLI/app-server: 0.149.0-alpha.4.1
  • ChatGPT iOS Remote client identified by the host: 1.2026.224
  • Remote pairing is online and otherwise functional

Reproduction

  1. Move/rename the folder used by an existing local Desktop project.
  2. Create a completely new Desktop project pointing to the new folder and move the relevant conversations into it.
  3. Confirm on Desktop that the new saved project, root folder, and conversation assignments are correct.
  4. Open the same host through ChatGPT iOS Remote.
  5. Observe that iOS continues to show the old folder basename/project shell, while affected conversations appear under ordinary chats instead of the current Desktop project.
  6. From iOS Remote, choose the new folder and start a test conversation.
  7. The test conversation is successfully created on the host with the new working directory, but its local project_id is NULL.
  8. Leave and reopen Remote. The test conversation remains outside the Desktop project, and the stale old project/folder entry remains.

Host-side findings

  • The Desktop saved-project record and current project root are correct.
  • Thirteen affected conversations have the current Desktop project assignment.
  • Twelve of those conversations have the new working directory in the host thread database.
  • The iOS-created test conversation has the new working directory but no project assignment.
  • There is exactly one Remote enrollment for the host, and its environment ID matches the current Desktop Remote state.
  • Restarting both apps/devices, revoking and re-pairing Remote, recreating the Desktop project, and refreshing Remote did not reconcile the project list or assignments.
  • Reinstalling or repeated pairing does not appear relevant because the stale association survives a valid current host connection.

This is consistent with Remote reconstructing project presentation from historical/bounded thread or cwd metadata, or from a separate stale projection, instead of treating the Desktop saved-project catalogue and current project_id assignment as authoritative.

Expected behavior

  • iOS Remote should enumerate the selected host's complete current saved-project catalogue.
  • A conversation reassigned on Desktop should move to the destination project on Remote.
  • Starting a conversation from a selected host project/folder on iOS should persist the corresponding Desktop project_id, not only the cwd.
  • Old folder/project shells should disappear once no current Desktop assignment refers to them.
  • Remote should provide a supported refresh/rebuild path for project/thread mappings after a folder move or project reassignment.

The local conversation data remains intact; the failure is specifically in Remote project discovery, assignment, and reconciliation.