Codex App SSH remote project shows "No chats" while remote threads exist in state DB

Potential duplicates detected. Please review them and close your issue if it is a duplicate.

• #27159
• #26157
• #27243
• #26640
• #26647

Powered by Codex Action

Update: I found a local workaround on the affected macOS machine.

Quitting Codex App and moving aside the Desktop UI state file fixed the sidebar for this SSH remote project. After reopening Codex App and reconnecting to the same remote project, the remote chats became visible again.

Workaround used:

ts=$(date +%Y%m%d-%H%M%S)

mkdir -p "$HOME/.codex-backups/$ts"
cp "$HOME/.codex/.codex-global-state.json" "$HOME/.codex-backups/$ts/" 2>/dev/null || true
cp "$HOME/.codex/.codex-global-state.json.bak" "$HOME/.codex-backups/$ts/" 2>/dev/null || true

osascript -e 'quit app "Codex"'
sleep 2

mv "$HOME/.codex/.codex-global-state.json" "$HOME/.codex/.codex-global-state.json.reset-$ts" 2>/dev/null || true
mv "$HOME/.codex/.codex-global-state.json.bak" "$HOME/.codex/.codex-global-state.json.bak.reset-$ts" 2>/dev/null || true

open -a Codex

This supports the earlier diagnosis that the remote threads were intact and the failure was in the macOS App's local Desktop/sidebar state. The reset removed/recreated local UI state, after which the App rebuilt the remote project chat list correctly.

Same bug, can confirm that workaround works!

I can reproduce a very similar failure mode, but with macOS -> macOS Remote Control rather than SSH remote.

Environment / setup:

• Controller: MacBook Pro, macOS 27.0 (26A5368g), arm64
• Host: Mac mini, shown in Codex as administrators-Mac-mini.local
• Codex app-server reported by logs: 0.142.5 on both local and remote-control host
• Flow: Codex Desktop on MacBook controlling Codex Desktop on Mac mini via Remote Control

What happened:

1. The MacBook sidebar showed a remote/project entry for administrators-Mac-mini... with a red error badge, while Settings > Connections still showed administrators-Mac-mini.local as green/Connected.
2. Logs showed two remote-control host ids for what appeared to be the same Mac mini. One was connected and healthy; the other repeatedly failed with:

``text
remote control app-server stream sequence gap detected
Codex app-server initialize handshake timed out
``

1. I removed the stale/broken remote entry from the UI. After that, the error badge went away, but the MacBook sidebar no longer showed the remote projects/chats (OpenClaw, DontPressThis, Skills, etc.). It only showed local chats.
2. The remote Mac mini's own Codex window still showed all project-grouped chats normally.
3. From the MacBook, a known remote chat could still be opened directly by thread id, but it did not appear in the sidebar. App search also failed to find known remote thread titles and only matched the current local chat.

Additional diagnostic signal from inside the MacBook Codex app:

• list_threads could see the remote threads under the healthy remote-control host id, including examples like:
• Check Hermes connections (cwd=/Users/administrator/Documents/OpenClaw)
• Investigate and fix the issue (cwd=/Users/administrator/Documents/OpenClaw)
• Update Update Machine (cwd=/Users/administrator/Documents/DontPressThis)
• Implement ClickUp spec (cwd=/Users/administrator/Documents/LinksBabe.com)
• navigate_to_codex_page / direct thread navigation successfully opened Check Hermes connections from the MacBook.
• But list_projects returned an empty project registry:

``json
{"schemaVersion":1,"projects":[]}
``

• After a full Codex restart on the MacBook, list_threads still saw remote threads cleanly, but the visible sidebar/search still did not show them because the project registry remained empty.

This looks very consistent with the issue described here: data/thread state is present and direct navigation works, but the Desktop sidebar/search project mapping or hydration layer is broken. In my case, the trigger seemed to be removing a stale duplicate Remote Control host/project entry after repeated app-server handshake failures.

Related issue that matches the Mac mini Remote Control / handshake side of the repro: #29262.

I may be seeing the same class of issue, but with ChatGPT mobile Remote Control targeting the local Mac itself, not an SSH remote project.

Environment

• Host: macOS
• Codex App: 26.623.101652

Released: Jul 3, 2026

• Codex CLI: codex-cli 0.142.5
• Client: ChatGPT mobile app Remote Control
• Remote target: the same local Mac
• Not using SSH remote for this reproduction
• Not using a separate remote devbox for this reproduction

Symptom

Remote Control works while connected, but the resulting threads are not discoverable later.

After using ChatGPT mobile Remote Control to either continue an existing thread or create a new one:

• The threads do not appear in the Codex App sidebar.
• codex resume reports no resumable conversations.
• /resume inside the CLI also reports no resumable conversations.

Local persistence checks

The local Codex state is updated after mobile Remote Control interactions.

I observed updates to files such as:

~/.codex/state_5.sqlite-wal
~/.codex/logs_2.sqlite-wal
~/.codex/memories_1.sqlite-wal

I also inspected ~/.codex/state_5.sqlite.

The database contains a threads table, and that table contains persisted thread records.

I am not pasting raw thread rows because fields such as title, first_user_message, preview, cwd, rollout_path, and repository metadata may contain private project or conversation content.

Safe aggregate query:

SELECT archived, has_user_event, COUNT(*)
FROM threads
GROUP BY archived, has_user_event;

Result:

0 | 0 | 26

I also checked distinct source values without exposing thread content.

Observed values:

cli
unknown
vscode

The historical file mentioned in some older reports does not exist in this environment:

~/.codex/session_index.jsonl

Why this seems related

This does not look like complete data loss or a failed Remote Control connection.

The local SQLite state contains thread records, and the state WAL is updated after mobile interactions. However, the normal history/resume surfaces behave as if there are no resumable threads.

Compared with the original SSH remote report, this reproduction uses a simpler setup:

ChatGPT mobile app -> Remote Control -> local macOS Codex App

So this may point to a more general thread/sidebar/history hydration or indexing issue, rather than something specific to SSH remote projects.

I can still reproduce this class of bug on the new ChatGPT desktop app that now hosts Codex.

Environment

• macOS desktop app: ChatGPT.app / bundle id com.openai.codex
• App version: 26.707.31123 build 5042
• Local standalone CLI: codex-cli 0.142.3
• Remote Linux SSH host CLI/app-server: codex-cli 0.144.0
• Connection type: Codex/ChatGPT desktop SSH remote project

Additional failure mode

This is not only an all-or-nothing No chats state. I am also seeing partial/stale sidebar hydration:

• A recent remote thread exists in the remote host's ~/.codex/state_5.sqlite and was updated today.
• The same thread is completely absent from the local Mac ~/.codex/sqlite/codex-dev.db local_thread_catalog table for the SSH host.
• A few other remote threads do exist in local_thread_catalog, but their source_updated_at values are several days behind the remote threads.updated_at values, so the Mac sidebar ordering/history is stale.
• The local .codex-global-state.json can still contain title/order/project state for the affected thread, while local_thread_catalog has no corresponding row. That leaves the sidebar in a half-hydrated state: the thread is real and can be opened/resumed by id, but it does not reliably appear in the project sidebar.

Path canonicalization signal

The remote thread rows have cwd values using the host's physical path, shaped like:

/real/home/user/workspace/project

The Mac remote project is registered through the SSH project picker using the logical/symlinked path, shaped like:

/home/user/workspace/project

The two paths refer to the same directory on the SSH host, but the sidebar/catalog behavior appears to treat them as different project roots in at least some hydration/backfill paths.

Safe diagnostic shape

The mismatch can be observed by comparing remote state_5.sqlite with the Mac local catalog:

-- remote SSH host
select id, title, cwd, updated_at
from threads
where cwd like '/real/home/user/workspace/project%'
   or cwd like '/home/user/workspace/project%'
order by updated_at desc
limit 20;

-- local Mac
select host_id, thread_id, display_title, cwd, source_updated_at, missing_candidate
from local_thread_catalog
where host_id = '<remote-ssh-host-id>'
  and (cwd like '/home/user/workspace/project%'
       or cwd like '/real/home/user/workspace/project%')
order by source_updated_at desc
limit 20;

Observed result:

• Remote DB top thread: present and recently updated.
• Local local_thread_catalog: missing that thread entirely.
• Several older local rows: present but stale compared with the remote DB.

Expected

When an SSH remote project reconnects, the desktop app should reconcile the remote threads source of truth into the local local_thread_catalog, normalize equivalent remote paths, and update the sidebar ordering/titles without requiring a manual restart or local DB repair.

Actual

The remote session data is intact, but the Mac sidebar/local catalog remains stale or partially missing. This persists on the new ChatGPT.app desktop build 26.707.31123.

This looks related to the original issue here and also to #30520: not data loss, but remote thread catalog/sidebar hydration not being invalidated/refetched reliably, with an additional path-canonicalization edge case.

same problem

After restarting Codex Desktop following today’s update, all Remote SSH projects now show “No tasks,” not only the previously affected project. The threads still exist and are returned by global thread search, and their cwd now matches the registered project paths exactly. This appears to be a sidebar project/thread indexing or cache-rebuild regression after restart, rather than deleted or archived threads.

I am experiencing a closely related issue on Codex Desktop for Windows with a stable SSH connection named ga-server.

The remote tasks are not lost:

• They remain searchable and openable.
• They are not archived.
• Their task tooltip still identifies the correct project and host.
• Pinning can make them appear temporarily.

However, the corresponding remote project (freee) disappears entirely from the Projects section of the sidebar. Unpinning causes tasks to disappear from the sidebar again.

The SSH connection itself remains configured, enabled, and online. This is not caused by switching hosts.

Additional path-normalization detail:

• saved project path: /home/naoto/MYWORK/freee
• task cwd: /mnt/data/dropbox/MYWORK/freee
• /home/naoto/MYWORK is a symbolic link to /mnt/data/dropbox/MYWORK

This appears to be the same remote project/sidebar hydration or project-thread association failure described in this issue.

Codex feedback ID:
019f5472-7f08-7511-81f2-d09d7446e1a1

Confirmed reproduction: symlink path vs physical path after restart

I completed a controlled reproduction across multiple Windows 11 clients connected to the same Linux host through Codex Desktop Remote SSH.

Environment

• Multiple Windows 11 client PCs
• Same ChatGPT account
• Same Linux SSH host and Linux user
• Same remote Codex/app-server version: 0.145.0-alpha.4
• Same underlying project directory
• Chat/task data remained present and searchable throughout the test

Directory layout

The Linux host exposes the same directory through two equivalent paths:

Symlink path:
/home/<user>/MYWORK/<project>

Physical path:
/mnt/data/dropbox/MYWORK/<project>

The first path is a symbolic link to the second path. Both paths resolve to the same directory on the Linux host.

Test procedure

1. I registered the same remote directory as two Codex projects on the same Windows client:

• one using the symlink path;
• one using the physical path.

1. Before restarting, I created a test thread under the symlink-path project.
2. The test thread successfully synchronized between two Windows clients when both clients registered the project using the exact same symlink path.
3. I then fully restarted the Windows PC and reconnected to the same SSH host.
4. After restart, I compared the two project entries.

Result after restart

Symlink-path project:
0 threads

Physical-path project:
8 threads

The threads were not deleted.

All threads, including the thread created under the symlink-path project before restart, appeared under the physical-path project after startup recovery/sidebar hydration.

Global search could also find and open the conversations.

Confirmed behavior

This is not simply a general synchronization failure.

Before restart, cross-device synchronization works when both clients use the exact same symlink path.

After restart, the sidebar appears to rebuild or hydrate its remote thread catalog using the physical/canonical path. The saved symlink-path project remains registered as a separate project but shows zero threads.

In other words, Codex Desktop treats these equivalent paths as different project identities:

/home/<user>/MYWORK/<project>
!=
/mnt/data/dropbox/MYWORK/<project>

even though they resolve to the same directory.

User-visible impact

• Active threads appear to disappear from the project sidebar after restart.
• The symlink-path project shows 0 threads / No tasks.
• The conversations still exist and remain searchable.
• Pinning can temporarily keep threads visible because pinned threads appear outside normal project grouping.
• Registering the physical path makes the threads reappear under that project.
• Different clients may show different project/thread groupings depending on which equivalent path they registered.

Workaround confirmed

Using the same physical path on every Windows client avoids the problem in this environment:

/mnt/data/dropbox/MYWORK/<project>

The important requirement appears to be consistent path identity across:

• the saved remote project path;
• the thread cwd;
• all connected desktop clients;
• startup catalog/sidebar hydration.

Expected behavior

Codex Desktop should normalize or resolve equivalent remote paths before associating threads with saved projects.

A symlink path and its physical target should either:

1. be treated as the same project identity; or
2. preserve the original thread/project path consistently across restart.

Threads should not appear lost because startup hydration resolves the path differently from the saved project registration.

This appears related to the path-normalization class of issues reported in #27243, but this reproduction specifically affects Linux Remote SSH projects and is triggered by a full desktop/PC restart.