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

<details>
<summary>
Incorrectly displayed thread content in App:
</summary>

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

</details>

<details>
<summary>
Accurately displayed content in the CLI:
</summary>

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.

</details>