🩹🩹 Windows: new local chat in a ChatGPT project fails to sync project context

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

• #34499
• #34589

Powered by Codex Action

Additional confirmed reproduction on a newer Windows desktop build.

Environment

• ChatGPT/Codex desktop app: 26.810.4967.0
• Windows 11 Pro 10.0.26200, x64
• This has happened repeatedly across many attempts, not as a one-off failure.
• Fully quitting with File → Exit and relaunching did not resolve it.

Observed behavior

• Selecting an existing ChatGPT Project for a local/Work chat shows: Could not use this project for a local chat.
• The local project mirror was present and readable, including AGENTS.md, two source files, and its metadata.
• Each failed attempt logged:

``text
ChatGPT project context sync failed
stage=filesystem
sourceCount=2
syncFileCount=2
projectSaveCount=0
``

• A read-only handle inspection showed one or two app-owned node_repl.exe processes from the bundled Codex runtime holding an open directory handle on:

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

• Stopping only those worker processes immediately released the directory handle. Reopening/reselecting a prior local chat associated with the same Project recreated the handles, after which project-context sync failed again.
• A later attempt succeeded only after returning to a non-project local chat, releasing the stale app-owned handles, and selecting the ChatGPT Project from the composer. This workaround is fragile and the failure has recurred multiple times.

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.

I am experiencing the same problem on Windows.

Environment:

• ChatGPT/Codex Windows app: 26.820.60940
• ChatGPT Chrome extension: 1.2.27268.51612
• Feedback ID: no-active-thread-01a0416b-5f71-7df2-bf81-e26c5d612ca9

Reproduction and observations:

1. I open an existing ChatGPT Project in the Windows app.
2. Selecting “Create new chat” or “New local chat” produces: “Could not use this project for a local chat.”
3. On one attempt, the app created a chat entry inside the project, but submitting the prompt still produced the same error.
4. A standalone Work/Codex chat outside the project can attach @Chrome and see my open LinkedIn tab, so the Chrome connection itself can work.
5. After fully closing and reopening the Windows app, the Chrome extension could find two newly created standalone chats, but it still could not find the project chat or the pre-existing project conversation through “Search recent chats.”
6. Renaming a side-panel-created chat in the Windows app did not update the title shown by the Chrome extension.
7. Full Access is disabled and Chrome Computer Use permissions are set to Ask First. This does not prevent standalone Work/Codex chats from seeing an explicitly attached Chrome tab.
8. I did not restart Chrome. Restarting only the Windows app refreshed some standalone-chat listings but did not resolve the project workflow.

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 @Chrome tab.

Please let me know if the Chrome extension indexing/title behavior should be reported separately.

Additional confirmed reproduction with a newer Windows desktop build and process/CWD correlation.

Environment

• ChatGPT/Codex Windows desktop app: 26.820.9563.0
• Windows 11 Pro, x64
• Project type confirmed by desktop metadata as a cloud-backed ChatGPT Project (projectKind=chatgpt, no local path/host binding)
• Project context contains three source files
• Cloud Work / web tasks for the same Project work normally; Local Work fails

Observed behavior

• UI error:

``text
Could not use this project for a local chat
``

• Five failures were recorded across two separate desktop process sessions on 2026-08-27. The relevant sanitized event is:

``text
ChatGPT project context sync failed
stage=filesystem
sourceCount=3
syncFileCount=3
``

• The same cloud-backed Project had successfully run a local chat/handoff earlier that day using the same mirror. This argues against permanent Project corruption or complete lack of Local Work permission.
• The mirror existed, was readable, was owned by the current user with inherited FullControl, and was not read-only.

Process/CWD timeline (UTC+08:00)

• 20:36:49: app-owned node_repl.exe process A started with its CurrentDirectory set to:

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

• 20:38:04 and 20:38:59: project-context sync failed at stage=filesystem.
• 20:44:06: app-owned node_repl.exe process 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:

1. Ordering between node_repl.exe startup/resume and ChatGPT Project mirror synchronization.
2. Ensuring helper processes do not retain a CWD inside a mirror that may be atomically refreshed.
3. Logging the underlying Windows filesystem error and locked path instead of only the generic UI message.

Additional isolation: codex.exe holds the project mirror open during sync

I was able to isolate a reproducible Windows filesystem lock that appears directly related to this issue.

Environment

• Windows x64
• Microsoft Store package: OpenAI.Codex_26.825.3734.0_x64
• Desktop release reported in logs: 26.825.31414
• Local ChatGPT Project mirror: %USERPROFILE%\.codex\.chatgpt-projects\<project-id>

Failure signature

ChatGPT project context sync failed
fileOrdinal=null
projectSaveCount=0
sourceCount=8
stage=filesystem
status=null
syncFileCount=8

All project sources had already synchronized when the filesystem stage failed.

Filesystem checks

• The active mirror was fully readable/traversable: 962 directories, 7,810 files, 0 failures.
• The previous mirror was also fully readable/traversable after ACL repair: 68 directories, 702 files, 0 failures.
• The exact same stage=filesystem error 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:

RENAME_OK

With ChatGPT/Codex open, the exact same rename failed:

The process cannot access the file because it is being used by another process.

Killing node_repl.exe alone did not release the lock.

Terminating the main codex.exe app-server process while leaving the ChatGPT desktop app running immediately changed the same rename test to:

RENAME_OK

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

Stop-Process -Name codex -Force -ErrorAction SilentlyContinue

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:

1. Desktop prepares/materializes the local project mirror.
2. codex.exe (or a child whose lifetime is tied to it) retains a handle on the project directory.
3. Project-context sync attempts to rotate/rename the mirror.
4. Windows rejects the rename because the directory is still in use.
5. The UI surfaces the generic stage=filesystem error.

Evidence supporting this:

• project contents are fully readable;
• source sync completes before the failure;
• killing node_repl.exe alone does not help;
• with the app open, the project directory cannot be renamed;
• terminating codex.exe immediately makes the rename succeed;
• retrying project sync then succeeds;
• the app subsequently respawns codex.exe normally.

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.