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

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.

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..

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.

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.

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.

problem sitll exist

Yes it does.

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

1. 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/...

1. 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

1. 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

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!