›_ Codex Issues
Codex Issues / #29600

Codex Desktop Archived Chats page discards SSH remote archived threads

Open 💬 5 comments Opened Jun 23, 2026 by yanggs07

What version of the Codex App are you using?

Local macOS Codex Desktop: 26.616.71553 (CFBundleVersion 4265)
Bundled local CLI: codex-cli 0.142.0
Remote Linux CLI/app-server: codex-cli 0.141.0

What platform is your computer?

Local: macOS arm64 Codex Desktop
Remote: Linux SSH managed remote project

What issue are you seeing?

Settings > Archived Chats does not show archived chats for an SSH remote host/project. The page always renders the empty state (No archived chats) even though the remote host has archived threads in ~/.codex/state_5.sqlite and ~/.codex/archived_sessions.

This is not data loss and does not appear to be a remote Codex version/config problem. The remote archive data is present.

Remote metadata check, with host/user/path details redacted:

codex --version
codex-cli 0.141.0

sqlite3 ~/.codex/state_5.sqlite \
  "select archived, count(*) from threads group by archived;"

archived=0  count=2
archived=1  count=2

sqlite3 ~/.codex/state_5.sqlite \
  "select id, title, archived, source, cwd, datetime(updated_at, 'unixepoch')
   from threads where archived=1 order by updated_at desc limit 10;"

<thread-id-1> | hello | 1 | vscode | /home/<user>/workspace | 2026-06-09 10:34:34
<thread-id-2> | <redacted title> | 1 | vscode | /home/<user>/workspace | 2026-06-06 11:05:27

find ~/.codex/archived_sessions -type f -name "*.jsonl" | wc -l
2

Expected behavior

When the selected Settings host is an SSH remote host, Settings > Archived Chats should display the archived threads returned by that host's list-archived-threads / thread/list archived:true path.

Actual behavior

The UI shows No archived chats for the remote host, despite archived rows and archived JSONL files existing remotely.

Likely root cause

I inspected the current Desktop app bundle to avoid guessing. In the extracted webview bundle, the archived chats settings page does call list-archived-threads with the selected host id:

queryKey:[`archived-threads`,t],
queryFn:()=>s(`list-archived-threads`,{hostId:t})

But when it builds the entries passed to the archived chat list, it only preserves the returned thread data when the selected host is exactly local:

let a=t===`local`?u:[]
...
A=xe({
  automationThreadIds:c,
  cloudTasks:m,
  localThreads:a,
  projects:k,
  projectlessThreadIds:new Set(r??[]),
  threadProjectAssignments:i,
  threadWorkspaceRootHints:o
})

So for any SSH remote host, the app can fetch archived threads into u, then discards them by setting localThreads to []. That makes the remote archived list empty even when the host returns data.

This looks like a Desktop archived-page bug, not a user SSH config issue and not missing archive support in the remote server.

Steps to reproduce

  1. Connect Codex Desktop on macOS to a Linux SSH remote project.
  2. Create or use an existing remote conversation.
  3. Archive that conversation from the remote project UI.
  4. Open Settings > Archived Chats and select the SSH remote host.
  5. Observe that the UI says there are no archived chats.
  6. SSH into the remote host and inspect ~/.codex/state_5.sqlite or ~/.codex/archived_sessions; the archived conversation is present.

Related issues

This is related to the broader remote history/sidebar hydration reports, especially #25092 and #27284, but this specific archived-chats failure appears to have a separate client-side cause in the Settings archived page.

Please fix this in the Desktop UI rather than expecting users to reset local state or edit SSH config. Archive is currently a destructive-feeling action for remote projects because the only recovery UI cannot see the remote archive.

View original on GitHub ↗

5 Comments

yanggs07 · 2 months ago

Update: this still reproduces after updating to the current macOS Desktop build.

Current local app:

Codex Desktop: 26.623.31443
CFBundleVersion: 4441
/Applications/Codex.app/Contents/Resources/app.asar timestamp: Jun 26 09:29

I re-extracted the updated app.asar and the same client-side discard logic is still present in webview/assets/data-controls-CHizTqlN.js. The variable names changed, but the behavior is identical:

queryKey:[`archived-threads`,t],
queryFn:()=>_e(`list-archived-threads`,{hostId:t})

// later, when building the archived chat entries
let r=t===`local`?l:[]
...
E=ut({
  automationThreadIds:c,
  cloudTasks:f,
  localThreads:r,
  projects:T,
  projectlessThreadIds:new Set(i??[]),
  threadProjectAssignments:o,
  threadWorkspaceRootHints:s
})

So the latest app still fetches archived threads with the selected remote host id, then discards the returned thread list for every non-local host before rendering. The visible symptom remains: selecting an SSH remote host under Settings > Archived Chats shows the empty state even though the remote host has archived rows/files.

This makes Archive effectively one-way for SSH remote users from the Desktop UI. Please prioritize this as a Desktop UI bug rather than a remote Codex version/config issue.

yanggs07 · 1 month ago

Update: still reproduces on a newer current macOS Desktop build.

Current local app:

Codex Desktop: 26.623.81905
CFBundleVersion: 4598
/Applications/Codex.app/Contents/Resources/app.asar timestamp: Jul 1 12:15

I re-extracted this build:

/tmp/codex-asar-current-20260703-003656

The same client-side discard logic is still present, now in:

webview/assets/data-controls-D7sY499U.js

Relevant minified snippet from this build:

queryKey:[`archived-threads`,t],
queryFn:()=>L(`list-archived-threads`,{hostId:t}),
...
let o=t===`local`?c:[]
...
D=ut({
  automationThreadIds:l,
  cloudTasks:p,
  localThreads:o,
  projects:E,
  projectlessThreadIds:new Set(r??[]),
  threadProjectAssignments:i,
  threadWorkspaceRootHints:a
})

So in build 4598 the Archived Chats settings page still fetches archived threads for the selected host id, but then passes an empty thread list into the renderer for every non-local host.

This also lines up with #30312, where another investigation confirmed the Rust/app-server thread/list archived path and tests are fine, and the failure appears to be Desktop webview/client-side.

Please route this to the Desktop/webview owner. For SSH remote users, Archive still behaves like a one-way hide operation because the only recovery UI drops the remote archive results before render.

hongjieh · 1 month ago

Additional reproduction on a newer macOS Desktop build, with the same client-side discard path.

Environment:

  • Codex Desktop: 26.623.101652
  • CFBundleVersion: 4674
  • Local platform: macOS Desktop app
  • Remote host type: remote-control / SSH-managed Linux host
  • Remote host id shape: remote-control:env_e_<redacted>
  • Remote CLI/app-server version: codex-cli 0.141.0

Observed behavior:

  • Settings > Archived chats with the remote host selected renders the empty state (No archived chats).
  • The remote state DB still contains archived rows:
archived=0  count=128
archived=1  count=131
  • A direct read of one archived remote thread by id through the selected remote host succeeds and returns thread metadata/turns, so the remote data and transport are not the blocker.
  • Normal thread search/list does not return that archived thread, which is expected while it is archived.

Bundle inspection from this build still shows the same behavior, now in:

webview/assets/data-controls-C6SV6hqU.js

Relevant minified snippet:

queryKey:[`archived-threads`,t],
queryFn:()=>ne(`list-archived-threads`,{hostId:t}),
...
let r=t===`local`?l:[]
...
O=ut({
  automationThreadIds:c,
  cloudTasks:p,
  localThreads:r,
  projects:D,
  projectlessThreadIds:new Set(i??[]),
  threadProjectAssignments:a,
  threadWorkspaceRootHints:o
})

For a selected remote host, t is not local, so the archived threads returned into l are replaced with [] before rendering. This exactly matches the UI symptom on this build as well.

This still looks like a Desktop/webview issue rather than remote SQLite data loss or a remote app-server listing failure.

yanggs07 · 1 month ago

Update: still present in the current integrated ChatGPT/Codex macOS app build.

The Codex app is now running from the ChatGPT app bundle on this machine rather than /Applications/Codex.app:

ChatGPT.app: 26.707.31428
CFBundleVersion: 5059
Codex Framework: 150.0.7871.101
App bundle path: /Applications/ChatGPT.app
ASAR inspected: /Applications/ChatGPT.app/Contents/Resources/app.asar
Extracted to: /tmp/chatgpt-codex-asar-20260710-082749

The same webview-side discard logic is still in this build, now in:

webview/assets/data-controls-CE14yfYB.js

Relevant minified snippet:

queryKey:[`archived-threads`,t],
queryFn:()=>Ce(`list-archived-threads`,{hostId:t}),
...
let i=t===`local`?c:[]
...
O=mt({
  automationThreadIds:l,
  cloudTasks:p,
  localThreads:i,
  projects:D,
  projectlessThreadIds:new Set(r??[]),
  threadProjectAssignments:a,
  threadWorkspaceRootHints:o
})

So as of build 5059, selecting an SSH/remote host in Settings > Archived Chats still fetches remote archived threads, then replaces the returned list with [] before rendering because the selected host id is not local.

This is still reproducible after the app moved under /Applications/ChatGPT.app, so the Desktop/webview fix has not landed yet.

KachurPro · 1 month ago

I can independently reproduce this on the current integrated ChatGPT/Codex macOS app.

Environment:

  • ChatGPT/Codex Desktop: 26.707.31428 (build 5059)
  • Remote Codex CLI/app-server: 0.144.1
  • Remote host: SSH-managed Linux machine

Evidence:

  • Settings > Archived Chats shows no archived chats for the selected remote host.
  • The remote state database integrity check returns ok.
  • The remote database contains 92 archived threads; all 92 have rollout paths, and 92 archived JSONL files are present.
  • Reading an archived thread directly by ID through the selected remote host succeeds and returns its turns.
  • The installed app bundle still fetches archived threads by hostId and then discards the list for non-local hosts before rendering (selectedHostId === "local" ? archivedThreads : []).

No host names, addresses, local paths, thread IDs, or titles are included here. This confirms the issue persists with remote app-server 0.144.1 and is a Desktop/webview listing bug, not remote data loss. For SSH users, Archive remains effectively one-way in the UI.