Codex - Could not use this project for a local chat - Repair

ChatGPT Bugs
, ,
1

I was getting a bug in the Windows desktop app this morning when trying to create a work chat under a project folder. It returned “could not use this project for a local chat”

I had ChatGPT itself look at the project folder.

The error appears to be in Windows: local Work chat creation fails because node_repl.exe locks the ChatGPT project mirror.

If anyone encounters the same problem they can look at this. Other processes may cause the same issue.

Summary

On Codex desktop for Windows, creating a local Work chat from an existing ChatGPT project repeatedly failed with:

Could not use this project for a local chat

The desktop log recorded:

ChatGPT project context sync failed
stage=filesystem
sourceCount=0
syncFileCount=0

The project data was not corrupt. The bundled node_repl.exe MCP process held an open Windows directory handle to the project’s local mirror:

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

Codex synchronizes project context by building a staging directory and rotating the active mirror using directory renames. Windows rejected that rename while node_repl.exe had inherited the project mirror as its working directory.

Environment

  • Windows 10 Pro 22H2, build 19045.6466

  • Codex desktop production Win32 release 26.820.71523

  • Bundled Node runtime v24.19.0

  • Browser and Computer Use bundled capabilities enabled

  • Existing ChatGPT project with zero synchronized source files

Reproduction

  1. Open Codex desktop on Windows.

  2. Select an existing ChatGPT project.

  3. Attempt to create a new local Work chat.

  4. Allow the task runtime and bundled MCP helpers to initialize.

  5. Codex attempts to synchronize and rotate the project mirror.

  6. The UI reports “Could not use this project for a local chat.”

  7. The log reports stage=filesystem without the failing path, operation, Windows error code, or lock-holder information.

The failure survived project-cache rebuilding and application restarts.

Expected behavior

Codex should synchronize the ChatGPT project and create the local Work chat. Bundled helper processes should not prevent replacement of the local project mirror.

Actual behavior

The active mirror could not be renamed:

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

Codex then displayed the generic local-chat error.

Confirmed findings

Windows Resource Monitor identified node_repl.exe as holding the project-mirror path. This recurred under different PIDs after retries and restarts, including PIDs 16328, 15660, 16512, and 27876.

The result was isolated repeatedly:

  • With the identified process running, a reversible rename of the mirror root failed with System.IO.IOException.

  • Stopping only the identified PID caused the same rename to pass immediately.

  • Other node_repl.exe instances that were not using this mirror could remain running.

  • Restarting Codex created another lock-holding instance and reproduced the failure.

The generated configuration contained:

[mcp_servers.node_repl]
args = []
command = '...\cua_node\...\bin\node_repl.exe'
startup_timeout_sec = 120

It did not specify a working directory, so the helper inherited the task/project directory.

Codex officially supports mcp_servers.<id>.cwd for setting an MCP stdio server’s working directory. However, manually adding it was not persistent: Codex regenerated the node_repl section during restart and removed the setting.

Successful diagnostic mitigation

After Codex had started:

  1. Add a stable working directory outside all project mirrors:
[mcp_servers.node_repl]
args = []
command = '...\node_repl.exe'
cwd = 'C:\stable\codex-node-repl'
startup_timeout_sec = 120

  1. Stop only the existing node_repl.exe instance holding the affected project mirror.

  2. Retry creating the Work chat without restarting Codex.

After applying this mitigation:

  • The project cache and metadata refreshed successfully.

  • The new local task was created.

  • New helper processes started without blocking creation.

  • No subsequent project-context sync failure was recorded.

This is only a diagnostic workaround because Codex removes the manual cwd setting during restart.

Likely root cause

The bundled Browser/Computer Use configuration launches node_repl.exe without a stable process working directory. On Windows, it inherits the rotatable ChatGPT-project mirror and keeps a directory handle open.

A later project-context synchronization attempts to rename the same mirror and fails with a Windows sharing violation.

There may also be a sequencing race:

  1. Project selection refreshes the mirror.

  2. The task and MCP helper start against that mirror.

  3. Chat creation triggers another synchronization.

  4. The second synchronization cannot rotate the now-locked mirror.

Recommended fixes

  1. Give bundled MCP servers, especially node_repl, an explicit app-owned working directory outside project mirrors.

  2. Do not rely on working-directory inheritance for bundled helpers.

  3. Preserve an existing supported mcp_servers.node_repl.cwd value when regenerating configuration.

  4. Complete all project synchronization before launching task processes or MCP servers.

  5. Consider immutable/versioned mirrors with indirection instead of renaming directories used by active tasks.

  6. Detect ERROR_SHARING_VIOLATION, identify known bundled child processes holding the mirror, safely rebase or restart them, and retry.

  7. Improve logging to include the failing operation, source and destination paths, native Windows error code, and lock-holder information.

  8. Replace the generic UI error with an actionable local-folder-lock message.

Suggested regression test

On Windows:

  1. Create an active ChatGPT-project mirror.

  2. Start the bundled node_repl MCP server for a task associated with that mirror.

  3. Trigger project-context synchronization and mirror rotation.

  4. Verify synchronization succeeds.

  5. Verify no bundled helper uses the rotatable mirror as its operating-system working directory.

  6. Repeat while selecting the project and immediately creating a Work chat to exercise the race condition.

Useful log signature

[electron-message-handler] ChatGPT project context sync failed
fileOrdinal=null
projectSaveCount=0
sourceCount=0
stage=filesystem
status=null
syncFileCount=0

The zero file counts are significant: the failure occurred before project content processing and was caused by local filesystem state.

2

Hi Barry,

I have now reproduced what appears to be the same underlying issue on ChatGPT Desktop for Windows, and I have managed to narrow it down further.

My case strongly suggests a race condition / filesystem-locking problem affecting the local mirror of ChatGPT Projects under .codex\.chatgpt-projects.

Environment

  • OS: Windows 11

  • ChatGPT Desktop: 26.908.4834

  • Use case: existing ChatGPT Project created on the web → start a new Work conversation → run it locally on the PC

  • Visible error:

Could not use this project for a local chat

This functionality worked normally for me very recently. I also already have older Work threads inside web-created Projects that still show:

  • the ChatGPT Project context

  • Work mode

  • local execution on the computer

Those existing local Work threads continue to work correctly.

The failure only affects the creation of new local Work conversations from ChatGPT Projects.

1. The logs show a filesystem-stage failure

Searching the ChatGPT Desktop logs produces repeated entries such as:

[electron-message-handler] ChatGPT project context sync failed
fileOrdinal=null
projectSaveCount=0
sourceCount=0
stage=filesystem
status=null
syncFileCount=0

I also reproduced the same failure with a Project containing many sources:

sourceCount=23
syncFileCount=23
stage=filesystem

This appears important because it means the problem is not caused by a particular uploaded file.

I reproduced it with:

  • an existing Project containing files and Project instructions

  • a newly created empty Project

  • a Project containing multiple sources

All of them can fail at:

stage=filesystem

2. The local Project mirror exists and is being updated

The Project mirrors are present under:

C:\Users\<username>\.codex\.chatgpt-projects\

with per-Project directories underneath.

ChatGPT is clearly creating and updating these directories, so the sync mechanism is not completely broken.

The failure seems to occur later, while ChatGPT is preparing or refreshing the Project context for a new local Work thread.

3. Resource Monitor shows processes holding handles on the Project directory

Using:

Resource Monitor → CPU → Associated Handles

and searching for:

chatgpt-projects

I can see several processes holding handles directly on the Project directory.

At different times these have included:

ChatGPT.exe
node.exe
node_repl.exe
python.exe

pointing to:

C:\Users\<username>\.codex\.chatgpt-projects\<project-directory>

In some cases I have seen multiple node_repl.exe processes holding the same Project directory simultaneously.

This appears very similar to what you described.

4. Third-party MCP processes can contribute to the problem, but they are not the root cause

I use Headroom as an MCP server.

At one point, Resource Monitor showed the Python process used by Headroom holding the ChatGPT Project directory open.

When I terminated the Headroom process tree, that handle disappeared and I was immediately able to create a local Work conversation successfully.

However, the problem later returned even with Headroom disabled.

So third-party MCP processes can apparently aggravate the issue, but they are not the underlying cause.

5. node_repl also keeps the Project directory open

I then disabled node_repl from the MCP settings in ChatGPT Desktop.

Despite this, once Work had initialised, internal node_repl.exe processes still appeared and held handles on the Project directory.

For example:

node_repl.exe → .codex\.chatgpt-projects\<project-directory>
node_repl.exe → .codex\.chatgpt-projects\<project-directory>

This suggests that Work / Computer Use may also start internal helper runtimes independently of the MCP toggle shown in Settings.

6. The most important finding: there is a reproducible timing window

This is the part that made the behaviour much clearer.

After fully closing and reopening ChatGPT:

  1. I open a ChatGPT Project.

  2. I switch to Work.

  3. If I paste a prompt and send it immediately, the local Work conversation is created successfully.

  4. Once created, the conversation behaves normally:

    • it runs locally

    • it can access local files

    • it can use local tools

    • it remains associated with the original ChatGPT Project

  5. Roughly 10 seconds later, node.exe / node_repl.exe processes begin holding handles on the Project mirror.

  6. After that point, trying to create another local Work conversation fails with:

Could not use this project for a local chat

This makes the issue look very much like a race condition.

The sequence appears to be approximately:

Project selected
    ↓
ChatGPT prepares/synchronises .codex\.chatgpt-projects\<project>
    ↓
short window where the directory is not yet locked
    ↓
local Work thread can be created successfully
    ↓
node / node_repl helper processes start
    ↓
they inherit or open the Project directory
    ↓
ChatGPT later tries to refresh, rotate, rename or replace the Project mirror
    ↓
Windows filesystem operation fails
    ↓
stage=filesystem
    ↓
Could not use this project for a local chat

7. I tested a fixed cwd for node_repl

I also tried adding a stable working directory to:

C:\Users\<username>\.codex\config.toml

For example:

[mcp_servers.node_repl]
cwd = 'C:\CodexStable\node_repl'

Before launching ChatGPT, the cwd entry is present.

After launching ChatGPT, the application regenerates that section and removes the manually added cwd.

So this workaround does not persist.

That behaviour also suggests that ChatGPT Desktop is dynamically regenerating the node_repl configuration.

8. Current workaround

The only reliable workaround I have found is:

  1. prepare the prompt beforehand

  2. copy it to the clipboard

  3. fully close ChatGPT

  4. reopen ChatGPT

  5. immediately enter the Project

  6. switch to Work

  7. paste and send the prompt before the helper processes appear

If I am fast enough, the local Work thread is created successfully.

Once the thread has been created, it continues to work normally.

That timing-dependent behaviour is, in my view, the strongest indication that this is not a Project permissions problem, a Project-content problem or an account-provisioning problem.

9. Why I think this is the same bug family

The main similarities with your report are:

  • same visible error

  • same ChatGPT project context sync failed

  • same stage=filesystem

  • same .codex\.chatgpt-projects directory

  • same Windows handle behaviour

  • node_repl.exe involvement

  • Project directories remaining open

  • successful creation when the locking process is removed or when the thread is created before the helpers initialise

The additional behaviour I can reproduce is that the problem is clearly time-dependent.

A newly launched ChatGPT instance has a short window in which a local Work thread can still be created successfully. Once the helper processes start holding the Project directory, new local Work threads fail.

At this point, the likely robust fix seems to be on the ChatGPT Desktop side.

3

There is also a new lock on the latest version.

I have created a script to work around it, you need to exit the app, run the script to unlock. It takes a few tries sometimes and is very annoying.

Might need to share it with the devs so they can apply a permanent fix.

File

This can repair your chat, it needs to be updated for each new desktop version. ChatGPT can modify it so it will work. Just add it to a local work chat and tell chatGPT what the issue is. Keep that chat available.

4

I am seeing exactly this persist between reinstallations; I have been looking at it all day and have found the same timing issue. It also prevents responding in work/codex jobs.

5

Additional finding: I discovered that ChatGPT/Codex can still create a new local Work thread inside the same web-created Project if I ask an existing Work task to create/run the request in a new local task within that Project. This works reliably even when manually creating a new local Work chat from the Project UI fails with stage=filesystem.

This suggests the underlying local Project/Work capability is still functional and that the bug may be specific to the UI/manual chat-creation path or to the filesystem sync sequence used by that path.

6

I can reproduce what appears to be the same issue on a completely fresh Cloud Project, including on a newer ChatGPT Desktop build.

Environment

  • Windows 11 Pro 25H2
  • ChatGPT Desktop for Windows 26.924.22138
  • App release date: 2026-09-26
  • Reproduced: 2026-09-29 JST

Fresh-project reproduction

  1. Create a brand-new normal Cloud Project.
  2. Do not attach a local source folder.
  3. Leave Project memory set to Open/default.
  4. Confirm that a normal Chat can be created inside the Project.
  5. Add a Project Source and confirm that the Chat can read it normally.
  6. From that same Project, switch to Work and attempt to create a new local Work chat.

Actual result
The app displays:

“Could not use this project for a local chat”

The Work chat is not successfully attached to the selected Cloud Project.

In earlier reproductions of the same failure mode on another Project, the desktop logs contained:

ChatGPT project context sync failed
submit_failed
stage=filesystem

with project/source/sync save counts at 0.

Expected result
A new local Work chat should be created inside the selected Cloud Project and inherit that Project’s context.

Additional isolation

  • Creating a local Work chat outside any Project works normally.
  • Existing local Work chats continue to work.
  • Normal Chat works correctly inside the fresh Cloud Project.
  • Project Sources can be added and read correctly.
  • Project memory remains Open.
  • The problem reproduces on a completely fresh Project, so it does not appear to depend on the size, age, or history of the original Project.
  • Attaching a local source folder creates a Local Project, but Local Projects currently do not support normal Chat in my desktop build, so that is not an equivalent workaround.

This makes the failure look specific to the Cloud Project → local Work creation / project-context sync path on Windows.

I have removed project names, local paths, account information, IP addresses, and unrelated filenames from this report.

7

This fresh-Project control is useful because it removes several explanations that were still possible in the older reports:

  • the Cloud Project is new;
  • normal Chat works inside it;
  • Project Sources can be added and read;
  • local Work works outside a Project;
  • existing local Work tasks still work;
  • the failure stays specifically on Cloud Project → new local Work creation.

One evidence boundary I would keep, though: the matching stage=filesystem / zero-count signature does not by itself prove this new occurrence has the same node_repl.exe directory-lock cause isolated in #1.

#1 had a much stronger causal chain:

  • a specific node_repl.exe process held the Project mirror;
  • a reversible rename failed while that process held the directory;
  • stopping only that PID made the same rename succeed;
  • restarting Codex recreated the lock and the failure.

So for the Sep 29 fresh-Project occurrence, I would currently call this the same visible failure class / filesystem-sync stage, with the underlying lock-holder mechanism still unconfirmed.

If your existing logs or diagnostics already captured any of these, they would bridge the two cases cleanly:

  • the exact failing filesystem operation/path;
  • native Windows sharing-violation/error code;
  • a process/handle holding the Project mirror;
  • or a rename-before/after result tied to that process.

No need to reproduce it again just for those fields. The controls you already posted are valuable on their own, especially because they make old/corrupt/oversized Project state a much weaker explanation.

8

Thanks — I agree with that evidence boundary.

For the Sep 29 fresh-Project reproduction, I have not confirmed a node_repl.exe directory lock or any other specific lock-holder mechanism. The overlap I can currently establish is limited to the same visible failure class and the earlier stage=filesystem / zero-count signature.

I’ll avoid treating the node_repl.exe cause from #1 as established for this occurrence. If I find any existing diagnostics that captured the failing path, native Windows error code, or a process/handle holding the Project mirror, I’ll add them here without forcing another reproduction.

9

Different versions of the chat have introduced new locking mechanisms. I have created another unlock tool for version 26.930.31730

https://filebin.net/m16nouwiobypzpx1/ChatGPTUnlocker.zip