Thread disappeared that was inside a Project and on a Worktree

Please make sure you're on the latest version of the app. Let us know if you're still seeing this.

@etraut-openai I am. Checked for updates:

"You're up to date! Codex 260205.1301 is currently the newest version available."

Exact same issue. Lost important work because of this bug. Thread was partially deleted. It appears that work done within last several hours was not "committed" and restart for update deleted that part of the thread.

Just today, I lost all my threads suddenly. I just updated to the latest version.

I found some archived threads. Unarchiving them removed them from the list of archived threads, but they are not visible at all in the project sidebar. So now they are effectively gone.

@kaiengelhardt
I had the same problem with archived thread and I managed to get them back :)

I think the problem relates to the original worktrees being cleaned up when archiving. Unfortunately unarchiving doesn't seem to recreate that worktree, it just moves the session from ~/.codex/archived_sessions/** into the ~/.codex/sessions/<yyyy>/<mm>/<dd>/folder.

Here is my recipe to restore succesfully:

• ask Codex to dig into the recent ~/.codex/sessions (or archived_sessions), give it some of the keyword you have been working on, I am sure it will uncover it
• ask to restore the original worktree (the reference is somewhere in that JSON file)
• restart

(It goes without saying: you don't need codex to do it, just have to do all the worktree restoring youself, the gist is: things are not lost, it's just JSON files needing to be "hydrated" into the expected git folder structure.)

Good luck and Happy coding.

I am also hitting this on the macOS Desktop app in Version 26.212.1823 (661). During an app upgrade, Codex deleted git worktrees across multiple projects and erased uncommitted work in those worktrees. This is severe data loss, not just thread visibility. It happened immediately after upgrading. Please treat this as high severity; I can share repro details/logs if helpful.

@devinbarry, to clarify, did you see threads disappear or worktrees? This issue is about threads disappearing. If you're seeing a different behavior, please open a separate bug report.

@etraut-openai Confirming: I lost both. The app upgrade deleted git worktrees across multiple projects, and the threads associated with those deleted worktrees were also gone/inaccessible afterward. This included uncommitted work in those worktrees.

Same here. Only have one from 1w ago now and i had tons.. 26.217.1959. yeesh just lost a lot of work

The way to get these back for me seems to be to sort chronologically and pin them to the top so I can go back to project-grouped.

Still really annoying.
Version 26.217.1959 (669)

@kaiengelhardt I had the same problem with archived thread and I managed to get them back :) I think the problem relates to the original worktrees being cleaned up when archiving. Unfortunately unarchiving doesn't seem to recreate that worktree, it just moves the session from ~/.codex/archived_sessions/** into the ~/.codex/sessions/<yyyy>/<mm>/<dd>/folder. Here is my recipe to restore succesfully: ask Codex to dig into the recent ~/.codex/sessions (or archived_sessions), give it some of the keyword you have been working on, I am sure it will uncover it ask to restore the original worktree (the reference is somewhere in that JSON file) * restart (It goes without saying: you don't need codex to do it, just have to do all the worktree restoring youself, the gist is: things are not lost, it's just JSON files needing to be "hydrated" into the expected git folder structure.) Good luck and Happy coding.

Based on the paths from above, Codex is able to get the missing threads for me.

Just tell Codex to check the local + UI thread index per repo.

Edited: it still unable to show the threads on the UI sidebar....

<img width="818" height="598" alt="Image" src="https://github.com/user-attachments/assets/569f6463-1e14-4dc3-81ac-05f4e1bc9142" />

This has happened to me too:
~5 worktrees and their conversations have been deleted (the folders have been deleted on disk). Unsure which version this happened on, but my current version is 26.224.1209 (697)

I have had many threads disappear now inside of projects. Sometimes they will come back after restarting the app completely or closing the project and reopening it using Finder on Mac. Cannot get them to come back reliably.

Same here all threads gone. After updating to Version 26.228.1430 (760)

This just happened to me. Logged in and updated yesterday, threads are gone.

Just ran into the same issue, work worth 33% of my weekly usage had disappeared.

Asked codex to find it, luckily it was still on disk and I was able to recover it.

Current version: 26.311.21342, not sure if the Codex App updated before this error happened. (Windows)

<img width="791" height="854" alt="Image" src="https://github.com/user-attachments/assets/dfbec590-e7c8-41dd-9a13-b5abe9124f10" />

I think it has something to do with unmatched version of Codex app and codex CLI. I uninstalled both. Deleted ~/.codex and installed just the desktop app. ~It seems to work fine now~. See https://github.com/openai/codex/issues/10917#issuecomment-4065609688

It broke again. I made it fix itself. Here's the prompt and the script it wrote. Quit Codex.app before running the script. restore_threads.ts

# Prompt
The threads inside codex app disappeared. The worktrees exist on disk but I don't see the associated codex threads in the app. Write a Bun script in ~/.codex/restore_threads.ts. You can use built-in sqlite helper and the bun shell thingy.

# Shell
bun run ~/.codex/restore_threads.ts

@tnfssc thanks for recovery script, I tried using it and unfortunately it didn't help :( But I tried opening the database in SQLite browser and it seems threads are in database but codex desktop app doesn't see them.

Does it read from threads table or from somewhere else?

@klinki I'm not sure. Maybe the prompting Codex to fix itself will help

It seems that the current behavior isolates indexes based on the provider. I'm not entirely clear on how the indexing mechanism works, but when switching between API and subscription modes—i.e., removing or adding model_provider in config.toml—the indexes between the two become inconsistent.

Additionally, a newly observed behavior is that if a new task is dispatched as a worktree, it completely disappears from the sidebar. It only shows up briefly at creation and then vanishes. The only way to access it is through Settings → Worktree, where you can locate it and switch back to that thread.