Codex App remote project conversations disappear from local sidebar, but still exist on the remote server #25092

Activity

1. howhere7

   added

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

   on May 29, 2026
2. etraut-openai

   added

   bugSomething isn't workingSomething isn't working

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

   remote

   on May 29, 2026
3. shakier commented on May 31, 2026

   

   shakier

   on May 31, 2026

   More actions

   Comment body

   Reproduced on macOS (Codex Desktop) with an SSH remote project on a Linux server. Spent some time tracing this in the minified bundles inside app.asar. Posting the diagnosis in case it helps — happy to file a PR if you point me at the source repo.

   Root cause (sidebar disappearance)

   The chain that decides "what hostId owns this conversation" has two atoms in app-server-manager-signals-*.js:

   • fk(hostId) -> AppServerManager — returns the manager for a hostId
   • fA(conversationId) -> hostId — returns the hostId for a conversation, with a ?? local fallback

   When a remote conversation is synced from the remote AppServerManager to the local UI:

   1. The remote manager is only registered in a Jotai-like scope. fk is computed from a mk atom that only constructs a manager when hostId === "local" — remote managers are not retrievable through fk at all, so any "look up the manager for this hostId" call returns null.
   2. fA(conversationId) calls dA(conversationId) which reads from a TA atom / THREAD_PROJECT_ASSIGNMENTS storage; for remote conversations these are empty, so it falls back to the local hostId.
   3. The sidebar W(thread, project) matching function in sidebar-project-groups-*.js then sees the thread with hostId === "local" and refuses to match it against a remote project (whose hostId is the SSH host's id), so the thread is dropped from the group.

   So the conversation isn't lost — it just gets stamped with the wrong hostId and the sidebar grouping silently drops it.

   Local workaround

   I patched four call sites in the asar to bridge this:

   1. fk: fall back to a globalThis.__codexMgrMap.get(hostId) lookup when the scoped atom returns null.
   2. addManager(...): also populate globalThis.__codexMgrMap.set(hostId, manager) so the fallback above has data for remote managers.
   3. Sidebar W: when the thread's hostId is local but the project is remote, try matching against every remote project's hostId.
   4. (Related) A "missing directory" warning fires for any cwd starting with /home/ because the local app can't stat it — suppressed for remote-shaped paths.

   After these four patches, remote conversations reliably appear under the right remote project in the sidebar across app restarts.

   Repro consistency

   The "sometimes" in the original report seems to depend on whether THREAD_PROJECT_ASSIGNMENTS has a cached entry from a prior session — when it does, dA finds the right hostId and the sidebar shows the thread; when it doesn't (fresh app start, new conversation, or after the cache is invalidated), the fallback to local hostId kicks in and the thread disappears.

   Happy to share the patched bundles or a more detailed write-up if useful.

   👍React with 👍2Reacted by Jeff and John
4. zhou13 commented on Jun 18, 2026

   

   zhou13

   on Jun 18, 2026

   Last edited by zhou13

   More actions

   Is the archive function working for anyone with remote ssh? If I archive a chat in a remote ssh instance, it completely disappears from the app UI. I was not able to recover it from <settings> -> <remote-machine> -> <archived chats>, which always shows No archived chats..
5. nbrosei commented on Jun 26, 2026

   

   nbrosei

   on Jun 26, 2026

   More actions

   Same, archival has been broken for me too, archived threads disappear from the sidebar but don't appear in Archived Chats.
   And now after the latest updates all my remote chats have disappeared in all remote projects in the sidebar, even though they're still accessible through the Cmd+G palette.

   👍React with 👍1Reacted by John
6. GaiZhenbiao commented on Jun 29, 2026

   

   GaiZhenbiao

   on Jun 29, 2026

   Last edited by GaiZhenbiao

   More actions

   All my remote threads has been lost too. They do appear for like a split second when connected to the remote, then completely disappeared. Pinned chats are alright though. The ChatGPT mobile app loads the threads just fine though, so this is a codex-macos specific bug.

   👍React with 👍1Reacted by John
7. burmjohn commented on Jun 29, 2026

   

   burmjohn

   on Jun 29, 2026

   More actions

   Same here as well, its been happening for at least a week now. Super frustrating, one thing you can do is ask it to pin the recent threads so you can at least see where you left off.
8. howhere7

   closed this as completedon Jul 10, 2026
9. HaoLiuHust commented on Jul 12, 2026

   

   HaoLiuHust

   on Jul 12, 2026

   More actions

   problem sitll exist

   👍React with 👍1Reacted by John
10. burmjohn commented on Jul 17, 2026

    

    burmjohn

    on Jul 17, 2026

    More actions

    Yes it does.
11. remco-dot commented on Jul 20, 2026

    

    remco-dot

    on Jul 20, 2026

    More actions

    I ran into what looks like the same issue on macOS with an SSH remote: project conversations briefly appeared in the Codex sidebar and then disappeared again, while the iPhone route could still see them.

    The workaround that fixed it for me was to treat the remote session files as the source of truth, not the local sidebar cache.

    What I did:

    1. On the remote host, inspect:

    • ~/.codex/session_index.jsonl
    • ~/.codex/sessions/**/*.jsonl
    • ~/.codex/archived_sessions/*.jsonl
    • ~/.codex/state_5.sqlite

    2. I found that the rollout/session files still existed, but some session_meta.payload.cwd and state_5.sqlite.threads.cwd values pointed at stale paths like:

    • /workspace/projects/...

      while my registered remote projects now used:

    • /home/codex/projects/...

    3. I stopped the remote Codex app-server, then migrated those stale paths in:

       • first-line session_meta records in rollout files
       • state_5.sqlite threads.cwd
       • local Mac ~/.codex/sqlite/codex-dev.db local_thread_catalog.cwd
       • local and remote .codex-global-state.json thread-project-assignments

    4. After rebuilding from the remote rollout/session records, the missing conversations showed again in the Mac app.

    The key point: state_5.sqlite and the local sidebar catalog can be stale or partially rebuilt. The durable source of truth was the remote session_index.jsonl plus the actual rollout files under sessions/ and archived_sessions/.

    In my case I also had to kill the remote app-server before patching, otherwise it could rewrite state_5.sqlite back from stale in-memory state.

    Validation after the workaround:

    • remote rollout metadata: 0 stale /workspace/projects/... cwd values
    • remote state_5.sqlite: 0 active stale /workspace/projects/... cwd values
    • local sidebar catalog repopulated with the missing remote project conversations

    👍React with 👍1Reacted by Chuan Hu
12. GaiZhenbiao commented on Jul 20, 2026

    

    GaiZhenbiao

    on Jul 20, 2026

    More actions

    I ran into what looks like the same issue on macOS with an SSH remote: project conversations briefly appeared in the Codex sidebar and then disappeared again, while the iPhone route could still see them.

    The workaround that fixed it for me was to treat the remote session files as the source of truth, not the local sidebar cache.

    What I did:

    1. On the remote host, inspect:

    • ~/.codex/session_index.jsonl
    • ~/.codex/sessions/**/*.jsonl
    • ~/.codex/archived_sessions/*.jsonl
    • ~/.codex/state_5.sqlite

    2. I found that the rollout/session files still existed, but some session_meta.payload.cwd and state_5.sqlite.threads.cwd values pointed at stale paths like:

    • /workspace/projects/...
      while my registered remote projects now used:
    • /home/codex/projects/...

    3. I stopped the remote Codex app-server, then migrated those stale paths in:

       • first-line session_meta records in rollout files
       • state_5.sqlite threads.cwd
       • local Mac ~/.codex/sqlite/codex-dev.db local_thread_catalog.cwd
       • local and remote .codex-global-state.json thread-project-assignments

    4. After rebuilding from the remote rollout/session records, the missing conversations showed again in the Mac app.

    The key point: state_5.sqlite and the local sidebar catalog can be stale or partially rebuilt. The durable source of truth was the remote session_index.jsonl plus the actual rollout files under sessions/ and archived_sessions/.

    In my case I also had to kill the remote app-server before patching, otherwise it could rewrite state_5.sqlite back from stale in-memory state.

    Validation after the workaround:

    • remote rollout metadata: 0 stale /workspace/projects/... cwd values
    • remote state_5.sqlite: 0 active stale /workspace/projects/... cwd values
    • local sidebar catalog repopulated with the missing remote project conversations

    Thanks!!! This worked!
13. eladmoshe commented on Jul 26, 2026

    

    eladmoshe

    on Jul 26, 2026

    More actions

    I’m seeing the same issue on macOS with an SSH-connected remote Mac. The chats remain visible in Recent and on mobile, but the matching remote project shows “No chats.” Removing and re-adding the project did not repair the association.
    One affected thread has cwd=/Users/<remote-user>/3dprint, exactly matching the saved project path, but its projectId remains null. The thread is also listed through two identities: remote-ssh-discovered:<ssh-host-alias> and a Remote Control environment.
    Codex Desktop: 26.721.41059
    Feedback ID: 019f9cff-af8b-7d82-ad72-5d54d5ce7b82
    This may share the same project-association failure described in #23609.