Recent Thread history wiped in app, present in CLI

[charles-waite]

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.

[github-actions]

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

[jemcoesl]

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.

[anton88vlc]

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.

[ff00ff00]

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)

[charles-waite]

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

[ff00ff00]

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

[charles-waite]

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.

[Amigov-Ai]

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.

[Amigov-Ai]

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.