Repository navigation
🩹🩹 Windows: new local chat in a ChatGPT project fails to sync project context #35127
Description
What version of the Codex App are you using (From “About Codex” dialog)?
26.721.3996.0 (Microsoft Store package OpenAI.Codex_26.721.3996.0_x64)
What subscription do you have?
ChatGPT subscription; exact tier omitted
What platform is your computer?
Microsoft Windows NT 10.0.26200.0 x64
What issue are you seeing?
On the combined ChatGPT/Codex Windows desktop app, creating a new local/Work chat from a ChatGPT project fails consistently with two UI errors:
Error creating chat
Could not sync ChatGPT project context
Could not use this project for a local chat
Creating the ChatGPT project succeeds, and existing chats in that project can still be continued. Starting a new chat outside a ChatGPT project also works. The failure is specific to creating a new local chat with ChatGPT project context.
Local diagnostics show that the app successfully creates a redacted mirror at %USERPROFILE%\.codex\.chatgpt-projects\<project-id>, including AGENTS.md, sources\, and metadata, but the subsequent composer submission still fails with Could not sync ChatGPT project context.
A fresh attempt also logged this warning before the submission failed (PII and IDs redacted):
[git-init-watcher] Failed to watch workspace root for git init
cwd=%USERPROFILE%\.codex\.chatgpt-projects\<project-id>
errorCode=ENOENT
errorMessage=ENOENT: no such file or directory, watch '<redacted-project-mirror>'
[electron-message-handler] [Composer] submit failed
cwd=%USERPROFILE%\.codex\.chatgpt-projects\<project-id>
errorMessage=Could not sync ChatGPT project context
mode=local
What steps can reproduce the bug?
- Install/open the combined ChatGPT/Codex desktop app on Windows.
- Create a ChatGPT project, or select an existing ChatGPT project in the Projects sidebar.
- Choose the local/Work chat mode.
- Enter any non-sensitive prompt and submit it.
- Observe both project-context synchronization errors and no usable new project chat.
Reproduces across multiple ChatGPT projects. Fully quitting and reopening the app does not resolve it. Moving the generated local project-mirror cache aside and allowing the app to rebuild it also does not resolve it.
What is the expected behavior?
A new local/Work chat should be created inside the selected ChatGPT project and should receive that project's instructions and source files. The new chat should then appear in the project's Chats section.
Additional information
The issue began after upgrading to the combined app. Existing chats remain usable, so this does not appear to be chat-data loss.
The generated mirror is created successfully on a clean attempt, but a later sync during composer submission fails. This suggests a Windows-specific ordering, watcher, or directory-locking race in the project-context synchronization path; that diagnosis is an inference from local behavior, not a confirmed root cause.
No raw logs are attached because they contain local identifiers. All excerpts above are manually redacted. Similar exact-error user reports appeared publicly after the same app update.
Impact
July 15–28, 2026
- Affected reporting users: Not established; feedback pieces and User Ops cases are not unique people.
- Estimated matching feedback: 0; User Ops cases: 0; cancellation surveys: 0.
Activity
github-actions commentedon Jul 24, 2026
Potential duplicates detected. Please review them and close your issue if it is a duplicate.
Powered by Codex Action
[-]Windows: new local chat in a ChatGPT project fails to sync project context[/-][+][M] Windows: new local chat in a ChatGPT project fails to sync project context[/+][-][M] Windows: new local chat in a ChatGPT project fails to sync project context[/-][+]đź©ąđź©ą Windows: new local chat in a ChatGPT project fails to sync project context[/+]sky0eyes commentedon Aug 14, 2026
Additional confirmed reproduction on a newer Windows desktop build.
Environment
26.810.4967.010.0.26200, x64Observed behavior
Could not use this project for a local chat.AGENTS.md, two source files, and its metadata.node_repl.exeprocesses from the bundled Codex runtime holding an open directory handle on:This looks consistent with a Windows sync-ordering / atomic-directory-replacement race where an app-owned runtime opens the existing project mirror before the sync tries to replace it. That is an evidence-based inference, not a confirmed root cause.
No raw logs, local identifiers, project names, or user paths are attached. Please investigate the ordering between local chat resume/runtime startup and ChatGPT Project mirror refresh on Windows.
dklepp commentedon Aug 27, 2026
I am experiencing the same problem on Windows.
Environment:
no-active-thread-01a0416b-5f71-7df2-bf81-e26c5d612ca9Reproduction and observations:
@Chromeand see my open LinkedIn tab, so the Chrome connection itself can work.Expected behavior:
A Work/Codex chat should be usable inside an existing ChatGPT Project, inherit that project’s context, appear in Chrome extension chat search, and accept an explicitly attached
@Chrometab.Please let me know if the Chrome extension indexing/title behavior should be reported separately.
ranzuozhou commentedon Aug 27, 2026
Additional confirmed reproduction with a newer Windows desktop build and process/CWD correlation.
Environment
26.820.9563.0projectKind=chatgpt, no local path/host binding)Observed behavior
Process/CWD timeline (UTC+08:00)
20:36:49: app-ownednode_repl.exeprocess A started with its CurrentDirectory set to:20:38:04and20:38:59: project-context sync failed atstage=filesystem.20:44:06: app-ownednode_repl.exeprocess B started with the same mirror as its CurrentDirectory.20:45:47: the filesystem-stage sync failed again.This is consistent with an app-owned helper retaining the Project mirror as its CWD while Desktop attempts to refresh or replace that mirror on Windows. The evidence establishes the filesystem-stage failure and the process/CWD timing correlation; it does not prove the exact internal rename operation or Win32 error code, because the underlying filesystem exception was not retained in the available logs.
No processes were terminated and no mirror/configuration files were modified during this reproduction. Raw logs, the Project name/ID, local usernames, absolute paths, prompts, and source filenames are intentionally omitted.
Suggested areas to inspect:
node_repl.exestartup/resume and ChatGPT Project mirror synchronization.fiona-toonygamy commentedon Aug 28, 2026
Additional isolation:
codex.exeholds the project mirror open during syncI was able to isolate a reproducible Windows filesystem lock that appears directly related to this issue.
Environment
OpenAI.Codex_26.825.3734.0_x6426.825.31414%USERPROFILE%\.codex\.chatgpt-projects\<project-id>Failure signature
All project sources had already synchronized when the filesystem stage failed.
Filesystem checks
stage=filesystemerror still reproduced after ACLs were clean, so ACLs were not the remaining cause.Directory-lock isolation
With ChatGPT/Codex fully closed, renaming the project mirror directory succeeded:
With ChatGPT/Codex open, the exact same rename failed:
Killing
node_repl.exealone did not release the lock.Terminating the main
codex.exeapp-server process while leaving the ChatGPT desktop app running immediately changed the same rename test to:User-visible result
Without closing the ChatGPT desktop app, I immediately retried opening the same ChatGPT Project in Work/local mode.
The project opened successfully.
After the successful sync, the desktop app automatically spawned a new
codex.exe, and the project continued working normally.Reproducible workaround
Then immediately retry opening/using the ChatGPT Project without closing the desktop app.
Likely failure mode
This strongly suggests a Windows directory-handle / lifecycle ordering race:
codex.exe(or a child whose lifetime is tied to it) retains a handle on the project directory.stage=filesystemerror.Evidence supporting this:
node_repl.exealone does not help;codex.exeimmediately makes the rename succeed;codex.exenormally.It may be worth auditing directory handles / process CWD inheritance and ensuring all project-directory handles are released before local ChatGPT Project mirror rotation on Windows.
No raw logs, usernames, SIDs, project IDs, project names, source filenames, prompts, or private local paths are included.
MichaelKai88 commentedon Aug 29, 2026
Additional independent Windows reproduction with a diagnostic event ID that OpenAI may be able to correlate internally.
Environment
26.818.4150910.0.26200, x64User-visible behavior
Diagnostic evidence
The same attempt generated:
Diagnostic event ID:
This matches the issue's existing failure signature and may provide a current internal telemetry record for investigation.
No project names or IDs, account details, prompts, source filenames, private file contents, or raw logs are included.
dtravex-art commentedon Aug 31, 2026
Additional confirmed recurrence on the current Windows desktop build, with longitudinal log evidence.
Environment
OpenAI.Codex 26.825.6671.00.151.0-alpha.7.210.0.26200/26200Repeated failure evidence
The exact
ChatGPT project context sync failedsignature occurs 29 times in the available desktop logs on four separate UTC dates:It persisted across at least these app-server versions:
0.148.0-alpha.210.150.0-alpha.12.20.151.0-alpha.7.10.151.0-alpha.7.2Latest failure:
A local task was started shortly before that failure:
The
projectSaveCount=3entries are intentionally excluded project-save resources; ten normal sources remained for sync.fileOrdinal=nullandstatus=nullagain show that the failure is not tied to an individual download.Recovery result
Current packaged implementation
Read-only inspection of the packaged desktop JavaScript in
26.825.6671.0shows that the sync implementation still:.<project>-staging-<uuid>directory;rename(activeRoot, previousRoot);rename(stagingRoot, activeRoot);The active root is also used as the working directory for local tasks. On Windows, this whole-root rotation can fail while an app-server process, task runtime, watcher, or inherited CWD retains the directory. The per-root promise map serializes concurrent sync calls, but the rename operations have no visible retry/backoff and are not coordinated with task processes using the root. The original filesystem exception is then reduced to the generic telemetry shown above.
This independently reinforces the directory-lock/root-replacement diagnosis already documented in this issue.
Suggested fix direction
g-p-*task root stable and transactionally refresh only application-managed context children.EPERM,EBUSY,EACCES,ENOTEMPTY).code,errno,syscall,path, anddest).wurf777 commentedon Aug 31, 2026
Additional independent reproduction on Windows 11. This is currently blocking my normal ChatGPT Work workflow.
Environment
User-visible error
English:
Reproduction
I can reproduce the same failure through two different entry points:
The Project has worked successfully with ChatGPT Work many times in the past, so this appears to be a regression rather than a project setup/configuration issue.
Impact
This is not a cosmetic or minor Projects issue for me. My normal Work tasks rely on the existing ChatGPT Project as context. Because the Project cannot be used from either direction — Project → Work handoff or direct selection inside Work — I am effectively unable to use ChatGPT Work for this workflow at all.
I can provide a screenshot of the user-visible error separately if useful.
wurf777 commentedon Aug 31, 2026
Follow-up to my reproduction above: I also submitted feedback directly from the ChatGPT/Codex Windows app with session logs included.
Feedback ID:
no-active-thread-01a05828-891b-7f53-b4e8-9877c8887bb0This should allow the report to be correlated with the app diagnostics from the affected session.
Maciej26code commentedon Sep 3, 2026
Additional isolation: multiple bundled Node helpers can hold the same project mirror
I reproduced this issue repeatedly across more than one existing ChatGPT Project on Windows. This comment adds one detail I have not seen isolated elsewhere in the thread: in a later recurrence, the exact mirror-directory handles were held concurrently by several different bundled helper runtimes, not only by
node_repl.exeor the main app-server process.The information below is sanitized. Account details, project IDs/names, Windows usernames, absolute user paths, PIDs, thread/session IDs, exact timestamps, prompts, source filenames, and raw logs are intentionally omitted.
Confirmed observations
Could not sync ChatGPT project contextfollowed byCould not use this project for a local chatbefore a usable local Work task could be created.stage=filesystem. The issue recurred in different ChatGPT Projects and with different source counts; one recent event hadprojectSaveCount=1,sourceCount=4, andsyncFileCount=3.%USERPROFILE%\.codex\.chatgpt-projects\<project-id>mirror.node_repl.exeruntimes;launch.mjs);server.mjs).Safety controls used during isolation:
node.exe,node_repl.exe,codex.exe, or the desktop app.Interpretation — inference, not a product-source finding
For these reproduced cases, the causal holder/rename test makes a Windows directory-lock explanation high confidence: bundled helpers appear to inherit or otherwise retain the rotatable ChatGPT Project mirror as their working directory; a later context sync attempts to rotate/replace the same directory; Windows rejects the operation; and the app reduces the underlying exception to the generic
stage=filesystemerror.This does not establish that every
stage=filesystemreport has the same cause. It does show that a fix limited tonode_repl.exewould be incomplete, because other bundled Node helpers can retain the same mirror concurrently. The occasional community workaround of changing model or reasoning effort may simply perturb helper startup timing, but that remains speculation.Suggested fix direction
.codex\.chatgpt-projects; do not rely on inherited CWD.ERROR_SHARING_VIOLATION, preserve the last known-good mirror, identify app-owned holder categories, safely release/rebase them, and perform a bounded retry.stage=filesystem.Regression-test proposal
On Windows 10 and 11, enable all bundled helpers and create at least 20 consecutive local Work tasks in each of two ChatGPT Projects, covering 0, 1, several, and 20+ sources; immediate submission after project selection; app restart; and recovery after a previous failed sync. A passing run should require no process termination, preserve every draft/source, create no duplicate environments, emit no
stage=filesystemfailure, and verify that no bundled helper uses a rotatable project mirror as its OS working directory.Related reports: #34499, #35680, #42215. The data-safety concern in #34698 is also relevant because a re-materialized mirror should not be treated as durable storage for unique user-created files.
I can provide additional sanitized fields if maintainers specify what would be useful, but I would prefer not to post raw desktop logs publicly.
Alabyebye commentedon Sep 15, 2026
Additional evidence: native sharing violation during project-root rotation (26.908.4834.0)
Reproduced on Windows x64, Microsoft Store package
OpenAI.Codex 26.908.4834.0. Ordinary chats work, but creating a local/Work chat in an affected ChatGPT Project fails withCould not use this project for a local chat.This adds native filesystem evidence to the directory-handle reports above. All paths and process identifiers below are redacted;
<project-root>means%USERPROFILE%\.codex\.chatgpt-projects\<project-id>.Startup capture with Process Monitor:
Read-only process inspection confirmed that all four bundled helpers retained this exact root as their CurrentDirectory. Their process ancestry belonged to the Codex app-server/runtime. The conflicting directory opens omit delete sharing. A separate transient exclusive open by ChatGPT.exe had already closed well before the failure; its mere presence in the trace is not evidence that it caused this failure.
Read-only inspection of this installed desktop build shows the synchronization sequence still creates a sibling staging directory, then calls
rename(activeRoot, previousRoot)beforerename(stagingRoot, activeRoot). The trace records failure while opening the root with DELETE access, before a rename can complete. DELETE access here is also needed for renaming; it does not establish an attempted destructive deletion.The app reports only
stage=filesystem, withsourceCount=2,projectSaveCount=2,syncFileCount=0,fileOrdinal=null,status=null. There were no ordinary source-file downloads in this attempt.Independent minimal mechanism test: an isolated empty directory could not be renamed while a child process used it as its working directory (Win32 error 32). After the child exited normally, the same rename succeeded. Project size is therefore not required for this locking mechanism.
This establishes a concrete blocking mechanism for this captured reproduction, not necessarily every failure covered by this issue. It agrees with Windows documentation for SetCurrentDirectory and FILE_SHARE_DELETE.
Please consider keeping the active workspace root stable while refreshing managed context, or coordinating mirror rotation with all helper lifetimes/CWDs. Logging the original filesystem exception/native error would also make diagnosis much easier. Raw logs, private project identifiers and contents are intentionally not attached.
PG-GITC commentedon Sep 16, 2026
I’m seeing a closely related issue on the current Windows desktop build.
Environment
I’ve isolated the problem specifically to Projects created with a local folder attached.
Reproduction:
As a control, I created another Project without attaching a local folder. That Project behaves normally and appears under Move to Project.
So the issue appears specific to local-folder Projects / Project membership synchronization, rather than Projects generally.
I submitted feedback from the affected client with diagnostics attached.
Feedback ID:
no-active-thread-01a0a92d-6eea-76d1-afb8-75005abd83a0
spy2520 commentedon Sep 29, 2026
Additional reproduction on September 29, 2026, using Windows desktop package 26.924.2738.0.
Creating a local Work chat inside one existing ChatGPT project fails with “Could not use this project for a local chat.” Another ChatGPT project works on the same installation.
Two failed attempts logged:
ChatGPT project context sync failed
The local project mirror contains AGENTS.md and all six cached source files. No new local chat was created for the affected project.
The exact failing filesystem operation and whether directory locking is involved remain unverified here. This appears related to #34499.
Is a fix available or planned? Including the underlying filesystem operation and native error in diagnostics would help identify the cause.