›_ Codex Issues
Codex Issues / #22438

Codex Desktop remote SSH connection does not show persisted remote sessions after app restart

Open 💬 8 comments Opened May 13, 2026 by JiabaoChen1

What version of the Codex App are you using?

Codex Desktop 26.506.31421 (2620)

What subscription do you have?

ChatGPT / Codex account subscription. I can provide the exact plan if needed.

What platform is your computer?

Local machine:

  • macOS 26.4.1
  • Build 25E253
  • Architecture: arm64

Remote machine:

  • Connected from Codex Desktop through SSH
  • Remote host: 172.27.127.196
  • SSH public-key authentication
  • Remote user: jiabao

What issue are you seeing?

When using Codex Desktop with a remote SSH connection, previous remote conversations are not shown in the Codex Desktop sidebar after restarting/reopening the Desktop app.

The remote history is not lost. The remote ~/.codex directory contains valid persisted session data, including:

  • ~/.codex/session_index.jsonl
  • ~/.codex/sessions/.../rollout-*.jsonl
  • ~/.codex/state_5.sqlite

Example remote session_index.jsonl entries:

{"id":"019e1f53-f380-74f3-9b19-62689665b5af","thread_name":"解释代码并说明复现流程","updated_at":"2026-05-13T03:14:51.727688595Z"}
{"id":"019e1f5a-f11b-7320-9df1-56690eebc764","thread_name":"排查 Codex 会话记录丢失","updated_at":"2026-05-13T03:22:01.42465072Z"}

The remote SQLite state database also contains these threads. Querying the remote DB by cwd/source/archive filters returns the sessions correctly.

However, after restarting Codex Desktop and reconnecting to the same remote host/workspace, these remote sessions still do not appear in the Desktop sidebar/history list.

Steps to reproduce

  1. Open Codex Desktop on macOS.
  2. Connect to a remote host through SSH public-key authentication.
  3. Start one or more Codex sessions in a remote workspace, for example /data/jiabao/Libra-MIL.
  4. Confirm that the remote machine has persisted session files under ~/.codex.
  5. Quit/restart Codex Desktop.
  6. Reopen Codex Desktop and reconnect to the same remote host/workspace.
  7. Check the Desktop sidebar/history list.

Expected behavior

Codex Desktop should show the persisted remote sessions for the current remote host/workspace after restart.

If the remote app-server/TUI can query or resume those threads, the Desktop UI should surface them as resumable history entries.

Actual behavior

The remote sessions remain present on disk and in the remote state database, but Codex Desktop does not show them in the sidebar after restart.

This makes it look like the remote conversation history was lost, even though the files and database rows still exist.

Evidence / debugging performed

Remote files exist:

~/.codex/session_index.jsonl
~/.codex/sessions/.../rollout-*.jsonl
~/.codex/state_5.sqlite

Remote DB inspection confirms the sessions are present:

python3 - <<'PY'
import sqlite3, pathlib

p = pathlib.Path.home() / ".codex/state_5.sqlite"
conn = sqlite3.connect(str(p))

for row in conn.execute("""
    select id, title, cwd, datetime(updated_at, 'unixepoch')
    from threads
    order by updated_at desc
    limit 20
"""):
    print(row)
PY

A query similar to the apparent app-server filters also returns the expected remote sessions:

python3 - <<'PY'
import sqlite3, pathlib

p = pathlib.Path.home() / ".codex/state_5.sqlite"
conn = sqlite3.connect(str(p))

q = """
select id, title, cwd, source, model_provider, archived, first_user_message
from threads
where archived = 0
  and source in ('cli', 'vscode')
  and cwd = ?
order by updated_at desc
limit 20
"""

for row in conn.execute(q, ("/data/jiabao/Libra-MIL",)):
    print(row)
PY

I also tried importing/syncing the remote ~/.codex session files and SQLite rows into the local ~/.codex, including:

  • copying remote sessions/
  • appending remote session_index.jsonl
  • inserting remote rows into local state_5.sqlite
  • adding local project trust/config entries
  • updating local global/sidebar state hints

These workarounds did not make the remote histories appear in Codex Desktop after restart.

This suggests the issue is likely in Codex Desktop's remote-history/sidebar hydration or filtering logic, rather than missing persisted session files.

Related issues

This looks related to local/Desktop history surfacing issues, but the reproduction here is specifically for Codex Desktop remote SSH connections:

  • #13713
  • #21076
  • #21659

Impact

Remote Codex sessions appear to disappear from the Desktop UI after restart, even though they are still persisted on the remote machine. This makes remote workflows difficult to continue from Codex Desktop.

View original on GitHub ↗

8 Comments

zhengjiaw · 2 months ago

I’m seeing the same issue with Codex Desktop and SSH remote workspaces.

Repro:

  1. Open Codex Desktop on macOS.
  2. Connect to an SSH remote workspace.
  3. Create a new session in the remote workspace.
  4. The session appears while Codex Desktop is still running.
  5. Quit Codex Desktop completely and reopen it.
  6. Reconnect to the same SSH remote/workspace.
  7. The previously-created remote session no longer appears in the sidebar/history.

The underlying files still exist on the remote side, including ~/.codex/sessions/**/rollout-*.jsonl and ~/.codex/session_index.jsonl. In my case, creating a new session after reconnecting makes only that new live session visible, while older remote sessions are not backfilled into the UI after restart.

This looks like a remote SSH history/sidebar hydration or backfill issue rather than the session data being lost.

JackeyCloud · 2 months ago

我也遇到了同样的问题

haikangdeng · 1 month ago

same here, had to log onto the ssh node to resume conversations

yanggs07 · 1 month ago

I can still reproduce this on the current Codex Desktop build after updating.

Environment:

  • Local machine: macOS, Codex Desktop 26.527.31326 (3390)
  • Local bundled CLI: codex-cli 0.135.0-alpha.1
  • Remote SSH host: CentOS/Linux, connected from Codex Desktop via SSH
  • Remote CLI: codex-cli 0.135.0
  • Remote project path: /opt/<redacted-project>

What I see:

  • The SSH remote host shows as connected/green in Codex Desktop.
  • The remote project exists in local Desktop state as a remote-ssh-codex-managed:<redacted-host> project with remote path /opt/<redacted-project>.
  • The Desktop UI/sidebar still shows no conversations for the remote project after restart/reconnect.
  • This is not data loss: the remote host still has the persisted threads in ~/.codex/state_5.sqlite and ~/.codex/session_index.jsonl.

Remote DB evidence:

codex-cli 0.135.0
019e76a9-ced4-7e80-b545-095b2d90f198 | <redacted title> | /opt/<redacted-project> | vscode | archived=0 | 2026-05-30 02:29:58
019e7574-6aa8-7813-b7c4-b3abda8b7e17 | <redacted title> | /opt/<redacted-project> | vscode | archived=0 | 2026-05-29 20:49:49
019e7261-43f2-7d71-8dbb-65224c31da7d | <redacted title> | /opt/<redacted-project> | vscode | archived=0 | 2026-05-29 06:17:28
019e71f0-7ee7-7783-91d8-858ecb40335f | <redacted title> | /opt/<redacted-project> | vscode | archived=0 | 2026-05-29 04:17:14

Relevant Desktop logs show thread/list requests against the remote app-server returning without an app-server error, for example:

method=thread/list hostId=remote-ssh-codex-managed:<redacted-host> errorCode=null

So this still looks like a Desktop remote sidebar/history hydration or filtering bug rather than missing remote persistence or SSH failure.

One important UX point: logging into the SSH node and running codex resume is not an acceptable workaround for this issue. That does recover the conversation data, but it bypasses Codex Desktop entirely and loses the intended workflow: local Desktop UI/control plane with execution and filesystem access on the remote host. The remote CLI can resume the thread, but the local Desktop sidebar cannot discover/resume it.

Expected behavior:

  • Codex Desktop should list and resume persisted remote threads for the selected remote host/project after restart.
  • Remote threads should be treated as first-class Desktop UI objects, with enough host/project/path identity to route thread/list and thread/resume to the correct remote app-server/state.
mbouzian42 · 1 month ago

I’m seeing the same issue with Codex Desktop and a remote SSH project.

Setup:

  • Local machine: macOS, Codex Desktop
  • Remote machine: Linux VPS accessed through Codex Desktop SSH remote project
  • Codex CLI on remote: 0.136.0
  • Connection type: SSH remote project

Observed behavior:

  • Conversations for the remote SSH project disappear from the Codex Desktop sidebar.
  • The sidebar can show the remote project as having “No chats”.
  • However, the conversations are not deleted.
  • I can still open the missing conversation by searching/pasting its thread ID.
  • The same conversation is also visible from another iphone Codex client connected to the same remote host.

Remote evidence:

  • The missing thread is present in ~/.codex/session_index.jsonl.
  • The corresponding rollout-*.jsonl file exists under ~/.codex/sessions/....
  • The thread can be resumed/opened by ID, so the persisted session data is valid.

Expected behavior:
Remote SSH project conversations that exist in the remote Codex session index and session files should appear in the Codex Desktop sidebar for that remote project.

Actual behavior:
The remote session exists and is resumable by ID, but it is not listed in the sidebar/history for the remote project.

This looks like a sidebar/history hydration or filtering issue for remote SSH projects, rather than missing or corrupted session data.

xuzheng · 6 days ago

I can reproduce this on the current Codex Desktop SSH remote flow and have additional evidence that narrows the failure to sidebar hydration rather than persistence or thread/list transport.

Environment

  • Codex Desktop for macOS: 26.707.71524 (5263)
  • Remote host: Linux over SSH (host details intentionally omitted)
  • Remote Codex CLI / app-server: 0.144.4
  • Managed persistent app-server daemon with remote control enabled

Additional evidence

  1. The remote session files and state database are intact.
  2. After restarting the desktop app, a direct app-server JSON-RPC sequence (initialize -> initialized -> thread/list) returns all 22 persisted, non-archived user threads.
  3. The desktop logs also show successful remote WebSocket initialization, app-server 0.144.4, multiple successful thread/list responses, conversationCount=22, and refreshRecentConversationsFailed=false.
  4. Despite that, the project groups in the sidebar render "No tasks" except for a thread explicitly opened by its ID.
  5. The listed remote threads initially have status notLoaded. Navigating to each existing thread changes its status to idle; after doing this, the corresponding sidebar entries appear. Once all 22 threads are opened once, the remote sidebar is fully restored.
  6. Restarting only the daemon, fully restarting the desktop app, and re-bootstrapping the managed daemon do not backfill the sidebar by themselves.

This suggests the remote transport and enumeration path is working, but the project sidebar either filters out notLoaded remote threads or fails to hydrate successful thread/list results into project groups.

Workaround

Open every persisted remote thread by ID once. This restores the sidebar entries, but it does not scale and requires the thread IDs to be known externally.

Expected behavior

A successful thread/list response should populate the appropriate project groups even while a remote thread is notLoaded. Alternatively, expanding a project group should lazily load/resume its persisted threads.

No host identifiers, user identifiers, repository names, workspace paths, thread titles, or thread contents are included in this report.

drinktee · 4 days ago

same here
codex-cli 0.144.3
chatgpt 26.707.91948

drinktee · 4 days ago

I found an additional reproduction condition on my side: this issue occurs when the remote project directory opened in Codex App is a symbolic-link path.

For example, the project is registered/opened through a path shaped like:

/home/user/workspace/project -> /data/workspace/project

After restarting the app and reconnecting to the same SSH host, the project can show no previous chats even though the remote session data is still present.

This suggests the project/thread association may be comparing paths by exact string while only one side is canonicalized—for example, the saved project path remains the symlink path while the persisted or rehydrated thread cwd resolves to the physical path.

It would be helpful for the remote sidebar hydration logic to either:

  • canonicalize both the saved remote project path and thread cwd consistently; or
  • preserve the originally registered path identity across restart.

At minimum, equivalent symlink and physical paths should not make existing remote conversations appear to be lost.