Recent Thread history wiped in app, present in CLI

What version of the Codex App are you using (From “About Codex” dialog)?

26.406.31014

What subscription do you have?

Plus

What platform is your computer?

MacOS - Darwin 25.3.0 arm64 arm

What issue are you seeing?

All recent thread history from probably the past 2-3 months has been lost in the GUI MacOS App. Restarting my machine, and quitting/reopening Codex has note resolved this.

The current thread state in the CLI is correct and is properly showing all recent messages and responses. I can still interact with the Agent in the App, and it has no knowledge that the recent history is not displaying in the app. It suggested I clear the app thread cache in ~/Libraries/Application Support.

When the App is restarted, any new messages or commands in the thread will appear to be deleted, but it will show correctly in the CLI.

What steps can reproduce the bug?

I have no way to reproduce this.

What is the expected behavior?

Full recent thread history should be displayed in GUI App.

Additional information

Incorrectly displayed thread content in App:

the C6 isn't explicitly supported, but the c3 blobs work perfectly on the c6 if you just copy the folder and rename it. 


Good to know — that makes this viable. If the C3 blobs run cleanly on C6, we can proceed pragmatically: treat C6 as C3 for the BSEC2 binary selection.

If you want to move forward, I suggest this path:

Create a new repo or branch targeting ESP‑IDF + esp‑matter on C6.
Add BSEC2 as a component, using the C3 blobs renamed for C6.
Build a minimal sensor task that emits:
Temperature / humidity / pressure
IAQ / eCO2 / bVOC (mapped into Matter Air Quality cluster + related measurement clusters)
Tell me which repo strategy you want (new repo vs branch), and I’ll outline the folder structure and the first few files to get compiling.


Are there any other files in the root directory that aren't being used or could be moved elsewhere to make the root a bit more organized?
10:07 AM


Yes — beyond what we already discussed, these are the main root-level “organization” candidates:

/Users/cwaite/Documents/nrf-TinyENV/HANDOFF.md → move to docs/ (or notes/)
/Users/cwaite/Documents/nrf-TinyENV/AGENTS.md → move to docs/ (or keep if you prefer root)
/Users/cwaite/Documents/nrf-TinyENV/resources/ → could be split into docs/resources/ if it’s reference-only
/Users/cwaite/Documents/nrf-TinyENV/sample.yaml → likely metadata-only; can move to docs/ or remove if unused
/Users/cwaite/Documents/nrf-TinyENV/VERSION → keep only if you use it for release/version tooling
/Users/cwaite/Documents/nrf-TinyENV/.DS_Store → safe to delete
For actual build/runtime, the key root files to keep are still:
CMakeLists.txt, Kconfig, Kconfig.sysbuild, prj*.conf, sysbuild.conf, and board/PM files you actively build against.


10:07 AM
So this thread just lost a VERY large amount of history. What happened?
10:08 AM


Nothing was deleted from your repo history or branch history.

What happened is the chat context hit size limits, so the system performed a context compaction: it replaced a long stretch of earlier messages with a summarized block so we could keep working. That’s why the visible thread suddenly looks much shorter.

What this means:

Your git history is intact.
Commits/branches are intact.
Only the conversational transcript in this session got condensed.
If you want, I can reconstruct a timeline from git (log --oneline --graph) and summarize the major milestones so you have a durable record.


10:08 AM
Ok, its odd that it didn't prioritize saving the more recent history. It looks more like it just deleted all the recent history going back to early work on integrating BSEC2... Why would Codex not inform me of its compacting the thread content? I'venever had it do this on other threads. And of course I've seen it compact its context window, but thats never really been destructive to the contents of the thread/chat history. Are you sure you're characterizing this correctly? It really seems like the chat history was just wiped.
10:10 AM


You’re right to question it. What I can confirm from my side is:

I can see a compacted summary block injected into the conversation stream.
That indicates the runtime reduced prior message content available to me and replaced it with a summary.
I do not control or get notified ahead of that; it’s system-side behavior.
What I cannot guarantee:

Whether your app UI intentionally hid messages vs. an actual display/history bug.
Why that specific cutoff happened where it did.
So: I’m confident compaction occurred, but your concern about apparent “wiped chat” is valid and could be a UI/history issue on top of compaction.

If you want, I can immediately generate a “continuity note” in your repo (e.g., docs/session-recovery-2026-04-10.md) with:

branch/commit state,
what was done recently,
open tasks,
so you’re protected even if chat history truncates again.

10:10 AM
Strange, its only in this GUI app. Codex in the CLI shows the history properly... Is there a way to clear this app's cache?
10:12 AM



Yep — on macOS you can clear just the GUI app’s local cache/state.

Try this in order:

Fully quit the Codex desktop app.
Find its local folders:
ls ~/Library/Caches | rg -i 'codex|openai'
ls ~/Library/Application\ Support | rg -i 'codex|openai'
ls ~/Library/Saved\ Application\ State | rg -i 'codex|openai'
Remove the matching GUI cache/state dirs (example pattern):
rm -rf ~/Library/Caches/<CodexAppDir>
rm -rf ~/Library/Saved\ Application\ State/<CodexAppDir>.savedState
Reopen the app and sign in again if needed.
I’d avoid deleting the whole Application Support dir until after trying cache + saved state first, since that may remove local preferences/session data.

If you want, I can give you exact delete commands after you paste the output of those ls | rg lines.


10:13 AM

Accurately displayed content in the CLI:

yea please do that.


• Done — I created a clean commit on diagnostic_mode with only the diagnostic
  implementation changes.

  Committed:

  - /Users/cwaite/Documents/nrf-TinyENV/Kconfig
  - /Users/cwaite/Documents/nrf-TinyENV/prj.conf
  - /Users/cwaite/Documents/nrf-TinyENV/src/app_task.cpp
  - /Users/cwaite/Documents/nrf-TinyENV/src/app_task.h
  - /Users/cwaite/Documents/nrf-TinyENV/src/shell_commands.cpp

  Commit:

  - 1ea4654 — Add diagnostic mode telemetry and recovery safeguards

  Left untouched (not in this commit):

  - /Users/cwaite/Documents/nrf-TinyENV/README.md
  - UART-only untracked files (/Users/cwaite/Documents/nrf-TinyENV/boards/
  xiao_ble_uart_console.overlay, /Users/cwaite/Documents/nrf-TinyENV/
  prj_uf2_uart.conf, /Users/cwaite/Documents/nrf-TinyENV/scripts/
  build_uf2_uart.sh)

  ::git-stage{cwd="/Users/cwaite/Documents/nrf-TinyENV"}
  ::git-commit{cwd="/Users/cwaite/Documents/nrf-TinyENV"}


› Thanks. I want to clean up the working directory a bit. Are we using anything
  in these directories:
  '/Users/cwaite/Documents/nrf-TinyENV/ESP32 source'
  '/Users/cwaite/Documents/nrf-TinyENV/sysbuild'
  '/Users/cwaite/Documents/nrf-TinyENV/Library'


• Short answer:

  - /Users/cwaite/Documents/nrf-TinyENV/sysbuild — Yes, used (for main/MCUboot
  sysbuild flow). Keep it.
  - /Users/cwaite/Documents/nrf-TinyENV/ESP32 source — Not used by the nRF
  build. It’s a separate ESP-IDF snapshot/reference tree.
  - /Users/cwaite/Documents/nrf-TinyENV/Library — Not used by firmware build;
  it’s Zephyr toolchain cache data.

  Important caveat:

  - Both ESP32 source and Library are currently tracked in git in this repo.
    So deleting them is a repo content change, not just local cleanup.

  If you want, I can do a safe cleanup plan next:

  1. keep sysbuild,
  2. move ESP32 source out of repo (or prune),
  3. stop tracking Library cache and add ignore rules so it never comes back.


› 1) sounds good, keep it.
  2) this can be deleted, its just a local copy of the code from an existing
  repo here: '/Users/cwaite/Documents/Coding Projects/MiniSensor/
  TinyENV_Sensor-Thread'
  3) This is fine, also do this.


• Done.

  I kept /Users/cwaite/Documents/nrf-TinyENV/sysbuild intact, and cleaned up the
  other two as requested:

  - Removed tracked repo content under:
      - /Users/cwaite/Documents/nrf-TinyENV/ESP32 source
      - /Users/cwaite/Documents/nrf-TinyENV/Library
  - Updated ignore rules in /Users/cwaite/Documents/nrf-TinyENV/.gitignore:
      - /ESP32 source/
      - /Library/

  Committed on diagnostic_mode:

  - 6979a7f — Remove local ESP32 snapshot and cached Library artifacts

  Current leftover working tree changes (not part of this cleanup commit):

  - Modified: /Users/cwaite/Documents/nrf-TinyENV/README.md
  - Untracked:
      - /Users/cwaite/Documents/nrf-TinyENV/boards/xiao_ble_uart_console.overlay
      - /Users/cwaite/Documents/nrf-TinyENV/prj_uf2_uart.conf
      - /Users/cwaite/Documents/nrf-TinyENV/scripts/build_uf2_uart.sh

  ::git-stage{cwd="/Users/cwaite/Documents/nrf-TinyENV"}
  ::git-commit{cwd="/Users/cwaite/Documents/nrf-TinyENV"}


› Are there any other files in the root directory that aren't being used or
  could be moved elsewhere to make the root a bit more organized?


• Yes — a few root-level items are likely cleanup candidates.

  Keep in root (actively used by Zephyr/NCS build):

  - /Users/cwaite/Documents/nrf-TinyENV/CMakeLists.txt
  - /Users/cwaite/Documents/nrf-TinyENV/Kconfig
  - /Users/cwaite/Documents/nrf-TinyENV/prj.conf and the prj_*.conf variants
  - /Users/cwaite/Documents/nrf-TinyENV/sysbuild.conf (and /Users/cwaite/
  Documents/nrf-TinyENV/sysbuild/)

  Likely removable or movable (if you only target XIAO):

  - Template board PM files for non-XIAO boards:
      - /Users/cwaite/Documents/nrf-TinyENV/pm_static_nrf52840dk_nrf52840.yml
      - /Users/cwaite/Documents/nrf-TinyENV/
  pm_static_nrf5340dk_nrf5340_cpuapp.yml
      - /Users/cwaite/Documents/nrf-TinyENV/
  pm_static_nrf54l15dk_nrf54l15_cpuapp.yml
      - /Users/cwaite/Documents/nrf-TinyENV/
  pm_static_nrf54lm20dk_nrf54lm20a_cpuapp.yml
      - /Users/cwaite/Documents/nrf-TinyENV/
  pm_static_nrf54lm20dk_nrf54lm20a_cpuapp_internal.yml
  - Possibly legacy/metadata:
      - /Users/cwaite/Documents/nrf-TinyENV/sample.yaml
      - /Users/cwaite/Documents/nrf-TinyENV/sysbuild_internal.conf
      - /Users/cwaite/Documents/nrf-TinyENV/sysbuild_uf2.conf
  - Doc/admin files could be moved to docs/:
      - /Users/cwaite/Documents/nrf-TinyENV/HANDOFF.md
      - /Users/cwaite/Documents/nrf-TinyENV/AGENTS.md

  One note:

  - /Users/cwaite/Documents/nrf-TinyENV/ESP32 source still exists locally (now
  ignored); it can be physically deleted if you want the tree cleaner.

  If you want, I can do a conservative pass now: move docs to docs/ and remove
  only clearly non-XIAO PM files.


› Are there any other files in the root directory that aren't being used or
  could be moved elsewhere to make the root a bit more organized?


• Yes — beyond what we already discussed, these are the main root-level
  “organization” candidates:

  - /Users/cwaite/Documents/nrf-TinyENV/HANDOFF.md → move to docs/ (or notes/)
  - /Users/cwaite/Documents/nrf-TinyENV/AGENTS.md → move to docs/ (or keep if
  you prefer root)
  - /Users/cwaite/Documents/nrf-TinyENV/resources/ → could be split into docs/
  resources/ if it’s reference-only
  - /Users/cwaite/Documents/nrf-TinyENV/sample.yaml → likely metadata-only; can
  move to docs/ or remove if unused
  - /Users/cwaite/Documents/nrf-TinyENV/VERSION → keep only if you use it for
  release/version tooling
  - /Users/cwaite/Documents/nrf-TinyENV/.DS_Store → safe to delete

  For actual build/runtime, the key root files to keep are still:
  CMakeLists.txt, Kconfig, Kconfig.sysbuild, prj*.conf, sysbuild.conf, and
  board/PM files you actively build against.


› So this thread just lost a VERY large amount of history. What happened?


• Nothing was deleted from your repo history or branch history.

  What happened is the chat context hit size limits, so the system performed a
  context compaction: it replaced a long stretch of earlier messages with a
  summarized block so we could keep working. That’s why the visible thread
  suddenly looks much shorter.

  What this means:

  - Your git history is intact.
  - Commits/branches are intact.
  - Only the conversational transcript in this session got condensed.

  If you want, I can reconstruct a timeline from git (log --oneline --graph) and
  summarize the major milestones so you have a durable record.


› Ok, its odd that it didn't prioritize saving the more recent history. It
  looks more like it just deleted all the recent history going back to early
  work on integrating BSEC2... Why would Codex not inform me of its compacting
  the thread content? I'venever had it do this on other threads. And of course
  I've seen it compact its context window, but thats never really been
  destructive to the contents of the thread/chat history. Are you sure you're
  characterizing this correctly? It really seems like the chat history was just
  wiped.


• You’re right to question it. What I can confirm from my side is:

  - I can see a compacted summary block injected into the conversation stream.
  - That indicates the runtime reduced prior message content available to me and
  replaced it with a summary.
  - I do not control or get notified ahead of that; it’s system-side behavior.

  What I cannot guarantee:

  - Whether your app UI intentionally hid messages vs. an actual display/history
  bug.
  - Why that specific cutoff happened where it did.

  So: I’m confident compaction occurred, but your concern about apparent “wiped
  chat” is valid and could be a UI/history issue on top of compaction.

  If you want, I can immediately generate a “continuity note” in your repo
  (e.g., docs/session-recovery-2026-04-10.md) with:

  1. branch/commit state,
  2. what was done recently,
  3. open tasks,
     so you’re protected even if chat history truncates again.


› Strange, its only in this GUI app. Codex in the CLI shows the history
  properly... Is there a way to clear this app's cache?


• Yep — on macOS you can clear just the GUI app’s local cache/state.

  Try this in order:

  1. Fully quit the Codex desktop app.
  2. Find its local folders:

  ls ~/Library/Caches | rg -i 'codex|openai'
  ls ~/Library/Application\ Support | rg -i 'codex|openai'
  ls ~/Library/Saved\ Application\ State | rg -i 'codex|openai'

  3. Remove the matching GUI cache/state dirs (example pattern):

  rm -rf ~/Library/Caches/<CodexAppDir>
  rm -rf ~/Library/Saved\ Application\ State/<CodexAppDir>.savedState

  4. Reopen the app and sign in again if needed.

  I’d avoid deleting the whole Application Support dir until after trying cache
  + saved state first, since that may remove local preferences/session data.

  If you want, I can give you exact delete commands after you paste the output
  of those ls | rg lines.

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

#Multiple sidebar bugs after workspace directory migration: "56 years ago" timestamps, missing threads, threads vanish on click (macOS) #17317
Desktop project sidebar hides active threads after state DB migration drift and stale temporary sessions #17304
Desktop thread panel hides existing workspace threads after workspace restructuring; backend pagination still returns them #16901
Lost my pinned threads (and multiple chat threads) with latest app update. #17253

Powered by Codex Action

I have the same bug; lost about 8 weeks of recent conversation history with 2 different agents/conversations on two different servers. Rollback to 26.325.31654 fixed it.

I can confirm a very similar regression on macOS, and I found one extra behavior detail that may help narrow it down.

What I observed:

In the desktop app, affected threads look like they lost recent history or open in the middle of the conversation.
The same threads still have the correct history on disk and in CLI.
This is not limited to one specific corrupted thread. I reproduced it both on a long historical thread and on another active thread.
On affected app versions, when I open the thread, the full history is briefly visible for the first second or two, and then after the UI finishes loading/hydrating, the visible history jumps and recent content disappears / the thread lands somewhere in the middle.

That makes this look less like actual data loss and more like an app-side state / hydration / virtualized scroll restoration bug.

Versions I tested:

26.409.20454 -> broken
26.406.31014 -> still broken
rollback to 26.325.31654 -> fixed the problem for me

So in my case, the regression window appears to include at least both 26.406.31014 and 26.409.20454, while 26.325.31654 behaves correctly.

The "history briefly appears correctly and then disappears after loading" symptom feels especially important, because it suggests the raw local rollout can still be read initially, and then some later app-layer state reconciliation is what breaks the visible thread view.

I ran into this bug too. While investigating, I found that the history is still present in the files under ~/.codex/sessions/.... The behavior is the same: the correct history appears for a second and then disappears.

I started using search in the window to look for the latest messages, and after many attempts I was eventually able to reach the supposedly missing latest messages through search. I saw that they were still there, but after the last message, the very first message of the thread appeared.

So my conclusion is that the history is simply being duplicated 1 or N times, eventually stopping at some point along the way, roughly in the middle. It is possible that some maximum limit is being hit.

MacOS - 14.7.6 (23H626). Latest updated version of Codex - Version 26.409.20454 (1462)

^^ Thank you both for explaining in a bit more detail than I was able to.

Another odd behavior, sometimes if you scroll up a bit, then scroll down you get sort of an "infinite" scroll where it scrolls down a bit loads more history (though it appears to not be loading anything new) and then shoots back up to the message that you started scrolling down at. If you scroll slowly this repeats for as long as I had the patience to do it, so maybe 20 times in a row. If you scroll really fast it seems to overcome this loading behavior and scrolls to the "end" of the history, which is very much not the most recent history.

Very odd behavior, its like its getting stuck recursively loading the same old blocks over and over and filling up its cache before it can get close to the latest messages.

Also can confirm I see this behavior on version 26.409.20454 (1462) in MacOS.

I have the same bug; lost about 8 weeks of recent conversation history with 2 different agents/conversations on two different servers. Rollback to 26.325.31654 fixed it.

Thanks, it's work for me.
It was safe for me to rollback even I used threads in version with this bug.
URL to version I rollback - https://persistent.oaistatic.com/codex-app-prod/Codex-darwin-arm64-26.325.31654.zip

I have the same bug; lost about 8 weeks of recent conversation history with 2 different agents/conversations on two different servers. Rollback to 26.325.31654 fixed it.

Thanks, it's work for me. It was safe for me to rollback even I used threads in version with this bug. URL to version I rollback - https://persistent.oaistatic.com/codex-app-prod/Codex-darwin-arm64-26.325.31654.zip

Thanks for that link. Rollback to 26.325.31654 also fixed the issue for me.

Additional reproducible macOS data point.

Environment:

Codex Desktop on macOS 26.2
Codex version 26.409.20454

Observed behavior:

I open an existing working chat and briefly see the latest messages.
Then the UI rolls back and the thread appears as if the last visible message is from February 12.
Roughly two months of more recent history disappear from the UI.
This has happened multiple times and affects multiple pinned working chats.

Why this is severe:

Recent file links, work results, and intermediate decisions become inaccessible in the UI.
Visually this looks like major data loss, even when the underlying data may still exist locally.

Evidence that this may be app/UI-side rather than true data loss:

Recent local rollout files are still present under ~/.codex/sessions/2026/04/12/.
The symptom matches the pattern already described here: latest history is visible first, then disappears after the thread finishes loading/hydrating.

Expected behavior:

Thread history should remain stable after load.
There should be a reliable way to reload full history without losing recent visible messages.

If useful, I can also attach exact local log paths from ~/Library/Logs/com.openai.codex/2026/04/12/ for the affected session.

Additional cross-surface reproducible data point.

This is no longer only a Codex Desktop UI issue on my machine. I now see the same rollback pattern inside Cursor in the Codex chats provided by the openai.chatgpt extension.

What is consistent across both surfaces:

The visible chat history rolls back to the same older point.
In my case, the UI repeatedly falls back to February 12.
This happens across multiple chats, not just one thread.
I do not need to reboot the computer or restart Codex for it to happen.
It is enough to return between normal day sessions: I used the chat yesterday, open it again today, and the whole daily visible session is gone again.
The model still remembers the latest context correctly when asked, so the recent conversation state appears to exist logically, while the UI rendering/history view is broken.

Why this matters:

This is now frequent enough that it disrupts normal daily work.
I lose access in the UI to the latest file links, intermediate decisions, and same-day results.
Because the model still knows the latest state, this looks even more like a history rendering / hydration / thread-state bug rather than real conversational memory loss.

Additional local evidence:

Cursor has the Codex extension installed as openai.chatgpt-26.409.20454-darwin-arm64.
Cursor logs for the extension show repeated warnings such as thread-stream-state-changed and thread-read-state-changed with no configured handler.
Example local log path: ~/Library/Application Support/Cursor/logs/20260413T150406/window1/exthost/openai.chatgpt/Codex.log
Codex Desktop continues to show the same February 12 rollback pattern.

This strongly suggests the problem is in shared thread/history presentation logic used across Codex surfaces, not only in the standalone desktop shell.

Please treat this as urgent. The issue is frequent, cross-surface, and workflow-breaking.

With the recent notice of the Axios breach, and OpenAI's push to cycle code signing materials and have everyone update their apps, I would expect something fairly breaking like this should have a high priority, no? I cannot use the latest versions of the app on my machine in any capacity. Codex CLI works fine as does version 26.325.31654 of Codex.app.

I'd love to see even the faintest hint of prioritization on this. I'd love to not have to abandon the GUI app...

Additional workaround for the visible in CLI, missing in app sidebar case:

If the missing chat still appears in codex resume --all, the thread probably still exists in Codex’s local DB
(~/.codex/state_5.sqlite) and in the raw session logs under ~/.codex/sessions.

What worked for me:

Quit Codex.app completely.
Back up ~/.codex/state_5.sqlite.
In that SQLite DB, find the missing thread’s row in the threads table.
Set that row’s updated_at and updated_at_ms to the current time.
Relaunch Codex.app.

That pushed the missing chats back into the app’s recent-sidebar list for me.

Just updated to Codex.app 26.422.30944 (2080) and this issue appears to be resolved. On MacOS 26.4.1 (25E253).

Codex Desktop Sidebar Regression: Project History Hidden Behind Global Recent Feed

Summary

Codex Desktop on macOS is not showing full per-project chat history in the sidebar.
Older project chats still exist locally on disk and in state_5.sqlite, but the sidebar only shows the subset that happens to land inside the globally loaded recent thread feed.

This is not data loss. It appears to be a sidebar/history loading bug.

Environment

App: Codex 26.422.30944 (CFBundleVersion 2080)
Platform: macOS 26.5
Kernel: Darwin 25.5.0 arm64
Date observed: April 27, 2026

Closest Existing Reports

openai/codex#14751 "Desktop app sidebar only shows loaded recent subset, not full workspace history" (opened March 15, 2026, later closed as duplicate)
openai/codex#17354 "Recent Thread history wiped in app, present in CLI" (opened April 10, 2026)
openai/codex#16549 "Codex threads disappear after a few days on macOS" (opened April 2, 2026)
openai/codex#17540 "Windows app: older local threads disappear from sidebar and sidebar search after restart while still present on disk" (opened April 12, 2026)

What I See

glas shows many chats in the project sidebar.
meta shows only a couple of chats.
primer-v2 shows No chats.
The missing chats still exist locally.

What I Verified Locally

Active thread counts in ~/.codex/state_5.sqlite:

glas: 993
meta: 57
primer-v2: 390

Despite that, the globally newest active threads are dominated by glas:

top 50 active threads overall by updated_at: glas 49, meta 1, primer-v2 0
top 100: glas 98, meta 2, primer-v2 0
first active primer-v2 thread does not appear until global rank 868

That matches the visible sidebar behavior:

glas looks populated
meta looks nearly empty
primer-v2 looks empty

Why This Looks Like an App Bug

Local bundle inspection of the current desktop app suggests:

recent threads are fetched globally, not per project
initial recent-thread refresh uses thread/list(limit = 50 * pageCount, sortKey = updated_at)
project grouping happens after that global fetch
project-level Show more expands only the already loaded items
the normal project sidebar path does not appear to auto-page deeper into global history

That means a project can look empty even when it has hundreds of valid local threads, if those threads are older than the currently loaded global recent window.

Expected Behavior

When a project is expanded in the sidebar, Codex Desktop should either:

show that project's full local thread history, or
fetch additional pages for that specific project until the project history is complete enough to browse

Older project chats should not disappear from the sidebar just because other projects dominate the global recent feed.

Reproduction Pattern

Have multiple local projects with many threads.
Continue using one project heavily so it dominates the most recent updated_at ordering.
Reopen Codex Desktop.
Observe that older threads from less-recent projects are missing from the project sidebar even though they still exist locally.

Evidence Summary

Local DB still contains the missing project threads.
The symptom tracks global recency ranking, not a per-project count.
Existing public reports describe the same class of problem: threads remain present locally or in CLI but disappear from the desktop sidebar.

Reproduced again on Windows/WSL on 2026-08-24.

Environment

Codex Desktop: 26.818.8289.0 (Windows x64)
Core/CLI version recorded in the rollout: 0.146.0
Workspace opened through WSL
CODEX_HOME is already configured to the Windows-side .codex directory

Symptom

Earlier turns disappear from the visible chat after continuing a long thread. The agent still has continuity, and the full turn-by-turn transcript remains present in the local rollout JSONL. This affects the currently open thread, not only an old thread missing from the sidebar.

Local structural checks

No transcript content or logs are attached.

Rollout file: about 11.5 MB / 1,650 JSONL records
Persisted message records: 13 user, 39 assistant
Three compacted events occurred
Every compaction has non-empty encrypted summary/context data (17,612 / 15,268 / 20,836 characters), so this does not appear to be the empty-summary failure described in Auto-compaction silently discards all conversation history since 0.145.0 #36642
The thread is still present in session_index.jsonl
The thread is still present in the sidebar project order and project assignment state

Expected

Context compaction may replace the model's working context, but it should not remove already persisted messages from the UI transcript. If older turns are intentionally collapsed, the UI should show an explicit expandable “compacted history” section.

Actual

The UI makes persisted history look deleted even though the rollout and thread indexes are intact.

This points to a desktop transcript hydration/rendering issue around compacted history rather than data loss. A safe “reload/reindex this thread from rollout” action would also provide a practical recovery path. I can provide additional redacted structural metadata if maintainers need it.

Reproduced again on Windows/WSL on 2026-08-25, one day after my previous report.

Environment

Codex Desktop: 26.818.8289.0 (Windows x64)
Standalone CLI visible in the workspace: codex-cli 0.130.0-alpha.5
Windows build: 10.0.26200.0
Workspace opened through WSL2

Recurrence

During an active, long-running coding task, the chat disappeared from the desktop UI again. The user described it as the chat being deleted and had to ask the agent to reconstruct where the work stopped.

No delete or archive action was requested or performed.

Read-only checks immediately after the disappearance

The underlying data still appears to exist:

The Codex task-list API reports the affected thread as active.
The task is not present in the archived-task list.
Its rollout JSONL is still present under the active .codex/sessions tree, not archived_sessions.
Rollout size: 10,496,403 bytes.
Rollout records: 1,777.
Persisted role records found structurally: 12 user and 33 assistant.
Compaction records: 2.
The agent retained continuity through a compacted summary and could accurately reconstruct the implementation state.

No transcript content, project paths, account identifiers, or raw logs are attached.

Interpretation

This is again consistent with an active-thread transcript/sidebar hydration or rendering failure around compaction, not actual deletion of the underlying session. From the user's perspective it is still destructive because the visible chat disappears and the work context must be reconstructed manually.

Expected behavior

An active thread must not disappear from the UI.
Context compaction must not remove persisted turns from the visible transcript.
If history is intentionally collapsed, the UI should show an explicit expandable compacted-history section.
The desktop app should provide a safe reload/reindex-from-rollout action when its projection disagrees with the active session data.

One practical note for anyone landing here: if codex resume --all or the rollout JSONL still contains the thread, don’t treat the Desktop sidebar as the data authority, and don’t mutate SQLite before making a consistent backup of both the database and rollouts.

I maintain Codex Migrate + Vault, a separate Mac app/CLI that indexes active and archived local Codex threads outside the Desktop sidebar, provides full-text search and export, and keeps encrypted versioned backups in a user-chosen folder. It does not fix Codex’s rendering or hydration bug; it is a safety and access layer for the local data that still exists.

https://migrate.segeren.com/
https://github.com/jsegeren/codex-migrate

Disclosure: I maintain it. The engine and CLI are MIT-licensed; the signed and notarized packaged app is paid.

Recent Thread history wiped in app, present in CLI #17354

Description

What version of the Codex App are you using (From “About Codex” dialog)?

What subscription do you have?

What platform is your computer?

What issue are you seeing?

What steps can reproduce the bug?

What is the expected behavior?

Additional information

Activity

github-actions commented on Apr 10, 2026

Desktop project sidebar hides active threads after state DB migration drift and stale temporary sessions #17304

Desktop thread panel hides existing workspace threads after workspace restructuring; backend pagination still returns them #16901

Lost my pinned threads (and multiple chat threads) with latest app update. #17253

jemcoesl commented on Apr 11, 2026

anton88vlc commented on Apr 11, 2026

ff00ff00 commented on Apr 11, 2026

charles-waite commented on Apr 11, 2026

ff00ff00 commented on Apr 11, 2026

charles-waite commented on Apr 11, 2026

Amigov-Ai commented on Apr 12, 2026

Amigov-Ai commented on Apr 14, 2026

charles-waite commented on Apr 21, 2026

CLRT19 commented on Apr 23, 2026

charles-waite commented on Apr 25, 2026

mjcladir commented on Apr 27, 2026

Codex Desktop Sidebar Regression: Project History Hidden Behind Global Recent Feed

Summary

Environment

Closest Existing Reports

What I See

What I Verified Locally

Why This Looks Like an App Bug

Expected Behavior

Reproduction Pattern

Evidence Summary

StreamVi commented on Aug 24, 2026

Environment

Symptom

Local structural checks

Expected

Actual

StreamVi commented on Aug 25, 2026

Environment

Recurrence

Read-only checks immediately after the disappearance

Interpretation

Expected behavior

jsegeren commented on Sep 19, 2026

Metadata

Metadata

Assignees

Labels

Type

Projects

Milestone

Relationships

Development

Issue actions