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

Activity

1. github-actions

   added

   bugSomething isn't workingSomething isn't working

   appIssues related to the Codex desktop appIssues related to the Codex desktop app

   remote

   sessionIssues involving session (thread) management, resuming, forking, naming, archivingIssues involving session (thread) management, resuming, forking, naming, archiving

   on Jul 29, 2026
2. geauxtigers commented on Jul 30, 2026

   

   geauxtigers

   on Jul 30, 2026

   Last edited by geauxtigers

   More actions

   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

   👍React with 👍1Reacted by xiaoxuesheng123467
3. 4918studios commented on Aug 14, 2026

   

   4918studios

   on Aug 14, 2026 – with ChatGPT Codex Connector

   More actions

   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.
4. frogfarewell commented on Aug 22, 2026

   

   frogfarewell

   on Aug 22, 2026 – with ChatGPT Codex Connector

   More actions

   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.
5. qijiu79-79 commented on Aug 24, 2026

   

   qijiu79-79

   on Aug 24, 2026 – with ChatGPT Codex Connector

   More actions

   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.
6. sakekasunuts commented on Oct 10, 2026

   

   sakekasunuts

   on Oct 10, 2026

   More actions

   Additional occurrence observed on 2026-10-10, with read-only host-side state checks. This matches the initial mobile-created-project / desktop-standalone-chat symptom in this issue; the later move/reconciliation steps have not been tested in this environment.

   Environment

   • Windows Codex installed package: OpenAI.Codex 26.1002.7124.0.
   • ChatGPT iPhone Codex Remote connected to the Windows host. The iOS app version was not captured.
   • The user reports starting the affected work from the phone and then continuing the same conversation on the PC.

   Observed behavior

   • The supplied iPhone screenshot shows two directory-named headings in Projects, each containing its corresponding conversation.
   • The supplied Windows screenshot shows both conversations in Recent, while neither heading appears in Projects.
   • One other existing saved project is visible in both screenshots, so this is a partial mismatch rather than the whole desktop project list being unavailable.

   Read-only host evidence

   • The desktop saved-project registry contains three projects, with no entry for either affected working directory.
   • The app-server SQLite projects / project_roots tables likewise contain only those three saved projects, with no registration for either affected root.
   • Both affected rows in threads have the expected local working directory but project_id = NULL.
   • Both working directories use the ordinary Windows extended-path representation, sanitized here as \\?\C:\Users\<redacted>\Projects\<redacted>. Unlike the path correlation described in [iOS Remote on Windows] Three projectless-chat cwd labels appear in Projects #36417, these two affected rows do not use /mnt/c or mixed Windows/WSL syntax.

   These observations establish a mismatch between mobile project presentation and the host's saved project catalogue / assignments. They do not establish that two different persistent project IDs exist: the host has no saved project or assigned project ID for either affected entry, and the mobile-side identity has not been inspected.

   Expected behavior

   Starting work from a host project in Mobile Remote should preserve an authoritative project registration and thread assignment that Desktop also recognizes. If a mobile heading is only a working-directory grouping, the UI should distinguish that from a saved project and provide a supported way to reconcile the two views without creating duplicate entries or moving files.

   This was not a clean-install reproduction. No project records were edited and no duplicate desktop project was created as a workaround. Screenshots were inspected locally but are omitted here because they contain private project names and conversation titles. Usernames, host names, full paths, project/thread IDs, and raw logs are also omitted.

   Related presentation mismatch: #47963.
7. foo-hao commented on Oct 15, 2026

   

   foo-hao

   on Oct 15, 2026 – with ChatGPT Codex Connector

   More actions

   [macOS + iOS Remote] iOS-created chat missing from a later-added Desktop project; explicit assignment restored visibility

   Additional occurrence observed on 2026-10-15 (Asia/Singapore). This adds the mobile-first creation order and a confirmed recovery outcome to this issue.

   Environment

   • ChatGPT/Codex desktop on macOS: 26.1007.30912, build 20156, read from the installed application's bundle metadata (not the About dialog).
   • macOS 26.5.1, Apple Silicon (arm64).
   • Client: Codex in the iOS app, working with the Mac host. Exact iOS app and iOS versions were not captured.
   • Subscription: not captured.
   • Desktop sidebar was grouped by project.

   User-reported trigger and recurrence

   1. Start a project/chat from Codex on iOS.
   2. Later add the corresponding local project on Desktop, pointing to the intended folder (called Example Project here).
   3. Expand that project in the Desktop sidebar.
   4. The previously created chat is missing from the project's chat list.

   The user says this happens every time they follow this order. This is a report from normal use, not a fresh controlled reproduction. No test project/chat was created for this feedback.

   Verified state before and after recovery

   Before recovery:

   • The user-provided Desktop screenshot showed Example Project expanded without the affected chat.
   • The native list_threads and read_thread tools could find/read the same chat, with its conversation content intact and the expected working directory.
   • The chat's returned projectId was null.

   Recovery and verification:

   1. Used the native move_thread_to_project tool to assign the existing chat to the already existing Desktop project.
   2. Read back with list_threads and confirmed that the intended project ID was now persisted.
   3. Opened that same chat with navigate_to_codex_page.
   4. The user explicitly confirmed that the chat was now visible.

   This establishes a successful recovery sequence for this occurrence. It does not isolate which step changed rendering or prove the underlying cause.

   Expected behavior and requested improvement

   When a local Desktop project is added, please reconcile eligible existing chats on the same host whose working directory matches that project's root. Where assignment is ambiguous, offer a clear Find existing chats / Assign to this project recovery action instead of silently leaving earlier mobile-created work undiscoverable under the project.

   Please also make project membership consistent and understandable between iOS Remote and Desktop, including when the chat predates the saved Desktop project.

   Evidence limits

   • Creation-order-related missing association/backfill is a hypothesis, not a confirmed code-level cause.
   • Another chat in this investigation was visible under a project even though its returned projectId was also null. Therefore projectId = null alone is not established as a sufficient explanation.
   • We did not independently test every filter/cache path, re-create the mobile-to-desktop flow, or verify mobile grouping after this Desktop recovery.
   • No data loss was observed for the inspected chat. This report concerns project assignment and discoverability.

   Private project names, paths, conversation titles/content, account and host identifiers, project/thread IDs, screenshots, and raw logs are omitted. No project files, configuration, or other chats were changed for this feedback.