ChatGPT Project context sync silently deletes generated workspace files on Windows

Open 💬 2 comments Opened Jul 22, 2026 by kpadams94
💡 Likely answer: A maintainer (github-actions[bot], contributor) responded on this thread — see the highlighted reply below.

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

Incident version: 26.715.8383.0

The app has since automatically updated to 26.715.9868.0.

Embedded Codex app-server/CLI during the incident: 0.145.0-alpha.27.

What subscription do you have?

ChatGPT Plus

What platform is your computer?

Microsoft Windows NT 10.0.19045.0 x64

Hardware:

  • Intel Core i7-6700K @ 4.00 GHz
  • 32 GB RAM
  • NVIDIA GeForce RTX 2070

What issue are you seeing?

A ChatGPT Project opened in the new Windows desktop app was treated by Codex as a writable local workspace under:

%USERPROFILE%\.codex\.chatgpt-projects\<project-id>

Codex successfully created and used persistent teaching artifacts there across multiple chats. When another local Work/Codex chat was started in the same Project, the composer repeatedly failed with:

Could not sync ChatGPT project context

After the sync failures and an app relaunch, the generated workspace files were silently removed. The directory was reduced to a newly created AGENTS.md plus an empty sources directory.

Existing chats still display links to the generated HTML files, but the links point to missing local files and open a “This site can't be reached” page.

There was no deletion confirmation, warning, Recycle Bin recovery, agent message, or chat-visible deletion event.

At minimum, the missing artifacts were:

  • 5 interactive lesson HTML files
  • 4 HTML reference pages
  • 8 Markdown learning records
  • shared CSS and JavaScript assets
  • MISSION.md, NOTES.md, and RESOURCES.md

The retained Codex session logs contain the file creation, updates, reads, validation, and successful rendering immediately before the sync error. They contain no Remove-Item, rm, unlink, delete patch, or other deletion tool call for the lost files.

This appears to be destructive re-materialization of a ChatGPT Project context directory that Codex had previously exposed and used as a durable writable workspace.

Related sync-error report: #34499. That issue does not describe the subsequent local file deletion/data loss.

What steps can reproduce the bug?

  1. In the new ChatGPT desktop app, create or load a ChatGPT Project through the New Project flow.
  2. Open the Project in local Work/Codex mode, allowing it to materialize under %USERPROFILE%\.codex\.chatgpt-projects\<project-id>.
  3. Use multiple chats and a local skill to create/update files inside that workspace. In this case there were two substantial prior chats, each reportedly near 100,000 tokens of context.
  4. Start or submit another local Work/Codex chat in the same ChatGPT Project.
  5. Observe Could not sync ChatGPT project context.
  6. Relaunch the desktop app or reopen the Project.
  7. Inspect the materialized Project directory and open file links retained in the earlier chats.

Observed timeline, America/New_York (UTC-04:00), July 21, 2026:

  • 8:21–8:26 PM: Codex read the existing artifacts, created a fifth lesson and fourth reference page, validated all local links, and rendered the new lesson successfully.
  • 8:40 PM: Codex successfully enumerated the learning records, confirming the workspace still existed.
  • 8:42:21 PM: First Could not sync ChatGPT project context failure.
  • 8:43:44 PM and 8:44:20 PM: Same sync failure repeated.
  • 8:52:21 PM: Desktop app relaunched.
  • 8:52:50 PM: App logged fs/readFile failure: The system cannot find the file specified. (os error 2).
  • 8:53:27 PM: The surviving AGENTS.md creation time. The rest of the generated workspace was gone.
  • 8:53:39 PM: Another fs/readFile failure with os error 2.
  • 8:54:14 PM: Project-context sync failure repeated.
  • 8:59:11 PM: The embedded browser attempted to open a previously generated lesson file.
  • 8:59:12 PM: It changed to a “This site can't be reached” error page.

Relevant local session IDs:

  • 019f86d8-d069-7241-98e3-77d3ca71a233
  • 019f8732-363b-7231-b582-ba99c6e62a59

Raw logs are retained privately. They may contain local paths and conversation content, so they are not attached publicly, but sanitized excerpts can be provided.

What is the expected behavior?

Files created in a directory presented to Codex as a writable local project workspace must survive new chats, project-context synchronization, and app restarts.

If .codex\.chatgpt-projects\<project-id> is a disposable cache rather than durable storage, Codex must not expose it as a persistent writable workspace. Generated work should instead be stored in a user-owned project directory, or the user must receive an explicit warning before work begins.

A project sync must never silently delete locally generated files. Any destructive reconciliation should require confirmation and provide a recovery path.

Additional information

Current filesystem state:

  • The affected Project directory still exists.
  • Only AGENTS.md remains.
  • Only the empty sources directory remains.
  • The retained thread logs preserve patch/content history for many deleted artifacts, so partial reconstruction may be possible.

Requested investigation:

  1. Confirm whether ChatGPT Project context sync destructively re-materializes .codex\.chatgpt-projects\<project-id>.
  2. Determine why Codex was allowed to write persistent artifacts into a directory later treated as disposable.
  3. Check whether server-side Project context or another local cache can restore the deleted files.
  4. Make Project context synchronization non-destructive, or prevent durable work from being written to disposable context directories.
  5. Add an explicit warning and recovery path before any synchronization can remove local files.

View original on GitHub ↗

2 Comments

github-actions[bot] contributor · 1 month ago

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

  • #34499

Powered by Codex Action

Legitao · 16 days ago

Same issue for the macOS app.
Similar issue