Windows: ChatGPT project prewarming locks local mirrors; startup erases node_repl cwd workaround

Feedback ID: 01a08ecc-5410-7112-821b-01b9915e4ec2

Related reports: #42215 and #34499. This report adds evidence of the helper-working-directory lock, a desktop startup rewrite that erased the initial workaround, and a user-confirmed workaround. The underlying product issue remains unresolved.

Codex App version

Windows Store package OpenAI.Codex 26.903.9818.0 (display name ChatGPT).

Subscription

Plan tier not included in this report. User-reported troubleshooting cost: 2% of weekly usage allowance.

Platform

Windows x64. Observed September 11, 2026.

Local usernames, project names, and project IDs have been replaced with placeholders. Paths below describe the actual workaround but require the appropriate local username.

Status: The user confirmed that the final workaround restored the affected workflow: “that finally worked !” This is a locally verified workaround, not a confirmed permanent product fix. The underlying application behavior has not been changed.

Problem observed by the user

Creating a new local Work task inside an existing ChatGPT project failed with:

Could not use this project for a local chat

The error appeared after typing or sending the first message. The user reported it across every ChatGPT project they attempted, including projects that had previously been repaired individually. Named examples were:

Project A
Project B
Project C
Project D

The requested workflow was to retain the existing ChatGPT project, its link, and its synchronized context while running Work locally. A separate local project, a copied workspace, or a cloud Work task did not satisfy that request. Successfully opening an existing local task also did not demonstrate that creating new tasks through the normal composer worked.

Expected behavior: Selecting a ChatGPT project, choosing local Work, and sending the first message should start a linked local task reliably. It should continue working for subsequent tasks and after restarting or updating the app, without manual project repairs.

User impact and troubleshooting cost

This blocked ordinary task creation across projects and repeatedly invalidated earlier project-by-project repairs. The user had to revisit prior repair conversations, correct cloud-versus-local verification mistakes, retry failed fixes, restart the app, and coordinate two troubleshooting tasks.

The user reports that this investigation consumed 2% of their weekly usage allowance, in addition to substantial time, effort, and frustration. Restoring a basic project workflow should not require this level of investigation, repeated intervention, or consumption of the user's usage allowance.

Several checks were initially treated as stronger evidence than they were: folder rename tests and direct API task creation succeeded while the normal composer still failed. The first global configuration workaround also passed an isolated test but did not survive the desktop's startup rewrite. These verification gaps prolonged the troubleshooting.

Environment

Observed September 11, 2026, on Windows x64.
Microsoft Store package: OpenAI.Codex 26.903.9818.0; application display name ChatGPT.
Local project mirrors: C:\Users\<user>\.codex\.chatgpt-projects\<project-id>.
Project A project ID: <project-id>.

Diagnosed failure mechanism

Typing in the new local Work composer prewarms a task and starts background MCP/helper processes.
Without an explicit helper working directory, these processes start inside the ChatGPT project's local mirror.
Sending the message synchronizes the project's context again before starting the actual task.
Synchronization stages a replacement directory, then attempts to rename the existing mirror before swapping the replacement into place.
Windows rejects that rename while helper processes hold the existing directory open as their current working directory.

Logs recorded ChatGPT project context sync failed with stage=filesystem. A direct filesystem check reproduced WinError 32, “The process cannot access the file because it is being used by another process.” Removing the relevant helper locks allowed the same rename to succeed. The error also occurred when Project A had no downloaded source files, so a failed source download was not needed to trigger it.

Both built-in helpers and configured integrations held these locks. The generated AGENTS.md file's read-only attribute was intentional and was not the cause. The evidence supports a Windows interaction between project synchronization and helper startup; it does not establish that the user selected the wrong project type or universally misconfigured their projects.

Installed implementation inspected:

.vite/build/main-CMBCj4XL.js: the Sfe synchronization function stages content and renames the live mirror.
webview/assets/app-primary-4c40d73a1074.js: composer prewarming starts helpers; the m9r submission flow synchronizes ChatGPT project context again.
Desktop startup regenerates the mcp_servers.node_repl configuration table using config/batchWrite with mergeStrategy=replace.

Why earlier repairs did not resolve the recurrence

The earlier mirror repair preserved the generated directory under a backup name while leaving the project record intact, allowing the desktop to regenerate its local bridge. The same approach was tried for Project A during this investigation. The mirror regenerated, but typing started new helpers and recreated the lock. The user confirmed that the error remained.

Stopping old helpers similarly provided temporary relief without preventing the next startup from recreating the condition. Direct local API initialization proved that the linked project could run locally, but bypassed the failing composer path.

The first global workaround gave helpers stable working directories. After an app restart, however, Codex rewrote the generated node_repl table and erased that helper's cwd setting. A fresh process inspection then found exactly one remaining project-bound helper, node_repl.exe, still locking Project A. The other six working-directory settings remained present. This explains why the first global workaround failed after restart.

Workaround that finally worked

The final workaround combines stable helper directories with a shared project configuration that supplies the setting erased by desktop startup.

Configure the Blender, Blend AI, ComfyUI, Konnect, and artifact-template-picker helpers to use separate stable directories under C:\Users\<user>\Documents\Codex\mcp\server-workdirs, using mcp_servers.<id>.cwd in the user's global configuration. The desktop continues to overlay its current artifact-picker launcher settings.
Set a stable cwd for cua_repl in the installed unified-computer-use plugin's .mcp.json.
Supply node_repl.cwd in the shared file C:\Users\<user>\.codex\.chatgpt-projects\.codex\config.toml, rather than relying on the global table that the app replaces:

[mcp_servers.node_repl]
cwd = 'C:\Users\<user>\Documents\Codex\mcp\server-workdirs\node_repl'

Create .chatgpt-projects-root in the mirror parent and add these entries to the user's global config.toml, making the shared configuration discoverable and trusted:

# Top-level setting; retain ordinary Git root discovery.
project_root_markers = [".git", ".chatgpt-projects-root"]

[projects.'c:\users\<user>\.codex\.chatgpt-projects']
trust_level = 'trusted'

Clear the already-running stale project-bound helpers after checking that no active task is using the affected workspace.

The individual task's working directory, existing ChatGPT project assignments, and project content were preserved. No signed application binaries were edited.

The helper working-directory option is documented in the OpenAI configuration reference. The combination above is a local workaround for the observed failure, not a documented permanent repair procedure.

Verification and limits

Fresh configuration reads confirmed that Project A, Project B, Project C, and Project D all inherited the shared node_repl.cwd setting. Project A's actual mirror then passed a rename-and-restore check with the relevant helpers connected, even when the generated node_repl table without cwd was supplied as a task override. Its instructions hash was preserved. This diagnostic used no saved user task or model turn.

After the final adjustment, the user reported that the workflow worked. That confirms user-observed recovery of the affected flow. It does not establish repeated composer success across every project, persistence across later app/plugin updates, or long-term durability.

The workaround does not repair the application's directory-swap behavior. A plugin replacement could overwrite the plugin-side cwd setting; future startup/configuration changes could invalidate other assumptions. Other processes started inside a mirror could still lock it. Helper code using relative file paths now resolves them from the stable helper directories, so absolute project paths should be used.

Backups of the original global configuration and plugin manifest, and the configuration before the shared-layer additions, were retained locally.

Required permanent product resolution

The application should coordinate project synchronization with helper startup and existing sessions so that its own processes cannot prevent creation of a new linked local task. It should also preserve supported configuration overrides across startup, or provide an application-managed solution that makes these manual overrides unnecessary.

A permanent fix should be verified through the normal composer across multiple projects and successive tasks, with existing helpers running, and after app restarts and app/plugin updates. It should preserve project links and content, provide an actionable error if synchronization fails, and eliminate the need for repeated cache resets, manual configuration surgery, or extensive usage-consuming troubleshooting.

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

[Windows][WSL][Projects] Cloud Project and Local Work split into duplicate project entries #43564

Powered by Codex Action

I experienced the same issue on Windows with Microsoft Store package OpenAI.Codex_26.908.4834.0.

Creating a new local Work chat inside an existing ChatGPT project repeatedly failed with “Could not use this project for a local chat”.

Diagnostics found that node_repl, the artifact template picker, and cua_repl processes were holding the project mirror as their working directory.

Setting stable working directories, adding project-specific configuration, and fully restarting the app restored chat creation. Changes to configuration files alone were insufficient while the app retained the previous configuration in memory.

Update — September 11, 2026: transferring an existing chat exposed a second lock

After new-chat creation worked, transferring an existing local chat into the same project still failed with the same UI message and stage=filesystem in the logs. The helper processes no longer had working directories inside the mirror.

This second failure involved the project-local .codex directory added as part of the workaround. Open-handle inspection found the Codex app-server holding that directory. Renaming the parent project mirror failed with Windows error 5 (Access denied), even though a separate delete-sharing probe reported no conflict. A standalone .NET FileSystemWatcher reproduction produced the same parent-directory rename failure, supporting a directory-watcher explanation.

The additional workaround was to move that configuration directory outside the mirror to a stable location and replace the original .codex directory with an NTFS directory junction pointing there. The configuration contents remained unchanged. With the app still running, renaming the project mirror and immediately restoring it then succeeded, and the project configuration still loaded correctly.

I have now successfully transferred the existing chat into the project through the normal UI, without another restart.

Both new-chat creation and existing-chat transfer are now confirmed for this one project. The junction workaround has not yet been tested across future restarts, application updates, or other projects. This is a temporary local workaround, not evidence of a product fix.

Please include both helper working-directory locks and project-configuration directory watchers in the permanent fix and regression tests, including existing-chat transfers and repeated mirror synchronization after project configuration has loaded.

I can independently reproduce this issue on Windows with ChatGPT/Codex Desktop build 26.903.9818.0.

Reproduction / observed behavior

In a brand-new Work chat outside any ChatGPT Project, Chrome — Computer use is available and works normally.
Chrome Computer Use successfully connects to my existing Chrome session and can enumerate the tabs open across multiple Chrome windows.
In the same desktop-app session, opening an existing ChatGPT Project and attempting to use local Work produces:
Could not use this project for a local chat
The desktop log records repeated failures at the same time:
ChatGPT project context sync failed ... stage=filesystem ...
I reproduced this four times during the test.
Task Manager showed seven node_repl.exe processes running.
Windows Resource Monitor → CPU → Associated Handles showed a node_repl.exe process holding an open file handle inside:
%USERPROFILE%.codex.chatgpt-projects<project-id>

This directly confirms that, during the Project-local failure, node_repl.exe has an open handle inside the local ChatGPT Project mirror while Project context synchronization is failing at the filesystem stage.

I also saw a separate Windows file-lock error earlier in the same startup while the bundled browser plugin was being reconciled:
errorCategory=plugin_cache_windows_file_lock
failed to back up plugin cache entry: Access is denied. (os error 5)

The Chrome plugin subsequently installed successfully, and standalone Work + Chrome Computer Use continued to function normally, so that browser-plugin lock does not appear to be the immediate cause of the Project-local failure.

Result: local Work + Chrome works outside Projects, but local Work fails inside the existing ChatGPT Project while node_repl.exe is holding the Project mirror open and Project context sync is failing with stage=filesystem.

This appears to independently reproduce the locking mechanism described in this issue.

I had also previously submitted in-app feedback about the Chrome/Work behavior. I may still have the Feedback ID, relevant log excerpts, or additional screenshots if useful. I’m also cross-posting a short reference to #42215 , since that issue tracks the broader “Could not use this project for a local chat” / stage=filesystem failure.

Independent reproduction on 26.908.4834.0: a fresh draft recreates the directory lock

I reproduced this on September 12, 2026, with Windows x64 and Microsoft Store package OpenAI.Codex 26.908.4834.0 (ChatGPT desktop, local Work inside an existing ChatGPT project). This adds a correlated timeline from a project with zero uploaded source files.

Selecting the project, choosing local Work and attempting to send the first message repeatedly produces:

Could not use this project for a local chat

It fails during project preparation, before a plugin tool call or a model response. A projectless local Work had successfully called the same installed connector in an earlier acceptance test on this machine.

Correlated observations (UTC)

Time, 2026-09-12	Observation
16:50:13.910507	The generated mirror's AGENTS.md modification time advances, consistent with a completed mirror write.
About 16:50:15.50	New tool helpers start with the project mirror as their working directory. The desktop log attributes startup to a fresh prewarmed thread.
16:50:20.151	Project synchronization fails at the filesystem stage.
16:50:29.385 to 16:51:04.544	Further user retries produce the same failure.

Sanitized log fields:

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

Filesystem checks

A read-only Win32 delete-access handle probe, allowing read/write/delete sharing, returned ERROR_SHARING_VIOLATION (32) for the mirror root. The mirror parent, sources directory and generated AGENTS.md passed the same probe.
The affected helpers were node.exe/node_repl.exe processes; their current working directories matched the mirror root. Inspected startup roles included node_repl, cua_repl and the artifact template picker.
During an interval after those helpers exited, a bounded directory rename-and-restore check succeeded. File hashes and attributes were unchanged.
Temporarily archiving the old failed acceptance task and releasing verified idle helpers did not fix the next normal-composer attempt: the new draft recreated the locks. The archive operation was subsequently undone.
Read-only inspection of the installed synchronization path is consistent with replacing the mirror by renaming its live root. Combined with the fresh-draft timing above, this supports the prewarming/synchronization conflict described in this issue; it is not an upstream-confirmed diagnosis.

The generated AGENTS.md read-only attribute was preserved. No signed application files, persistent configuration, connector login or project source content were changed. The shared stable-directory workaround described above has not been applied or validated on this machine; cleanup alone was not a durable fix.

Please include zero-source projects, fresh composer prewarming, successive local Work creation with existing helpers, and preservation of project contents in regression coverage. The normal project-based local Work flow remains blocked here.

Project/account identifiers, local usernames, private paths, connector identifiers and full session logs are omitted from this public feedback.

Windows Local Work handoff fails at Project context filesystem sync on 26.908.4834.0

Environment

Windows 11 Home, OS build 26200 (10.0.26200), x64.
Installed Microsoft Store package: OpenAI.Codex 26.908.4834.0.
Surface: Windows desktop app, existing ChatGPT Project, Chat-to-local-Work handoff.
Project memory: Default memory, verified in Project settings during investigation.
An existing local Codex task associated with the same Project remained usable.
Project mirror: C:\Users\<USER>\.codex\.chatgpt-projects\<PROJECT_ID>.
Personal names, project/conversation identifiers, and conversation content are intentionally omitted.

Summary

Selecting “Workで続ける” (Continue in Work) from an existing normal ChatGPT conversation in a Project failed repeatedly with:

このプロジェクトをローカルチャットで使用できませんでした

The installed application's corresponding English message is “Could not use this project for a local chat”.

The desktop log recorded three Project context sync failures at the filesystem stage. Later read-only inspection found two running node_repl.exe processes whose current working directories were the affected Project mirror. The installed application stages a replacement mirror and renames the existing mirror during synchronization.

A working-directory/rename conflict is a plausible explanation, not a confirmed failed syscall in this incident. The original Windows error code was not exposed in the captured log.

Steps to reproduce

The following reconstructs the user's observed workflow; no additional reproduction was performed during report preparation.

On the Windows desktop app, use an existing ChatGPT Project with Default memory.
Have an existing local Codex task in that Project. In this incident, that task remained functional and helper processes were subsequently observed using its mirror as their cwd.
Open an existing normal ChatGPT conversation in the same Project.
Select “Workで続ける” / Continue in Work to continue locally.
Observe the failure notification instead of a usable handoff.

The presence of a helper with that cwd is an observed condition, not a proven prerequisite. This report does not establish that having an existing task is itself a product restriction.

Expected behavior

The app should synchronize Project context and complete the local Work handoff. Its own helper processes should not prevent the synchronization needed by that workflow.

Actual behavior

The handoff fails with the notification above. Logs report stage=filesystem, even with sourceCount=0 and syncFileCount=0. The existing local task remains usable.

Reproducibility

The user reported at least two failed attempts on the same day. Three error log entries were captured; they must not be interpreted as proof of three separate user clicks. Reproduction on a clean installation, other machines, or other app versions was not attempted.

Relevant timestamps

Incident date: 2026-09-13. JST is UTC+09:00.

JST	UTC
22:08:45.900	13:08:45.900Z
22:08:50.842	13:08:50.842Z
22:11:40.855	13:11:40.855Z

These are actual log timestamps, not captured click timestamps. The error lines omit Project ID; correspondence to the affected Project is inferred from adjacent conversation-load activity and the user's contemporaneous reports.

Minimal sanitized logs

The contents of Bug1_project_sync.sanitized.log are included below. It contains only the three relevant error entries, retaining their original UTC timestamps and diagnostic fields. Renderer/window fields and original line-number prefixes were removed; no diagnostic values were changed.

Additional investigation already performed

Read-only investigation of this incident established:

The mirror exists; its source manifest is version 1 with an empty files array. This alone is not evidence of corruption.
Two node_repl.exe processes had the affected mirror as cwd when inspected after the failures. Both started at 14:24:35 JST, before the failures. Their cwd at the exact failure instants was not recorded.
In the installed app.asar, .vite/build/main-D8abTQQE.js, function PM stages a new directory, renames the live mirror to a previous directory, then swaps in the replacement.
In webview/assets/app-primary-17b54400f32a.js, O5e performs Project synchronization and records its stage; R5e invokes synchronization for handoff; $O displays the failure message.
The generic filesystem failure does not identify which operation failed or the original Windows exception number.

No process was terminated, no mirror was renamed/deleted, no settings were modified, and no new test task was created. No rename/unlock experiment was performed. WinError 32 is therefore not claimed as observed here.

For diagnosis, it would be useful to retain the original OS error and failing filesystem operation in diagnostics, and check whether helper cwd retention can block the mirror swap. Exact user paths need not be exposed in public logs.

Related existing issues

Windows: ChatGPT project prewarming locks local mirrors; startup erases node_repl cwd workaround #44736 — similar helper-cwd/mirror-swap mechanism; that report uses 26.903.9818.0. This incident adds observations on 26.908.4834.0 through the normal Chat-to-Work handoff.
Windows ChatGPT Work: “Could not use this project for a local chat” — project context sync repeatedly fails at filesystem stage #42215 — same filesystem-stage error, but with 23 sources rather than zero.
🩹🩹 Windows: new local chat in a ChatGPT project fails to sync project context #35127 — existing tasks remain usable while new local Project context synchronization fails.

Submitted as additional evidence for the existing issue family, not proof that every report has the same root cause.

2026-09-13T13:08:45.900Z error [electron-message-handler] ChatGPT project context sync failed fileOrdinal=null projectSaveCount=0 sourceCount=0 stage=filesystem status=null syncFileCount=0
2026-09-13T13:08:50.842Z error [electron-message-handler] ChatGPT project context sync failed fileOrdinal=null projectSaveCount=0 sourceCount=0 stage=filesystem status=null syncFileCount=0
2026-09-13T13:11:40.855Z error [electron-message-handler] ChatGPT project context sync failed fileOrdinal=null projectSaveCount=0 sourceCount=0 stage=filesystem status=null syncFileCount=0

Adding a newer-build reproduction because the workaround documented in this issue did not fully work on my installation. I spent quite a bit of time isolating the remaining failure, and the behavior appears to have changed in a way that may be useful to the maintainers and to others hitting this on newer builds.

Environment

Windows x64
ChatGPT Windows desktop app
Package version: OpenAI.Codex 26.908.4834.0
Installed using the direct download from OpenAI
Packaged application location:
C:\Program Files\WindowsApps\OpenAI.Codex_26.908.4834.0_x64__2p2nqsd0c76g0
Affected workflow: existing ChatGPT Project -> New Chat -> Work -> Local
User-visible error:
Could not use this project for a local chat

In my case, the problem initially appeared to be specific to one existing ChatGPT Project rather than affecting Local Work globally.

Background

I found this issue while troubleshooting the same local-project failure and followed the workaround described here.

The underlying diagnosis in this issue appears correct. Sysinternals Handle repeatedly showed helper processes holding the affected project mirror open under:

C:\Users\<user>\.codex\.chatgpt-projects\<project-id>

I moved the configurable helpers to stable working directories outside .chatgpt-projects, including:

node_repl
cua_repl
GitNexus
another configured stdio MCP server

Those changes successfully removed those processes as project-directory lock holders.

However, the existing workaround did not completely resolve the problem on 26.908.4834.0.

The remaining process was the built-in artifact-template-picker.

Where the existing workaround stopped working

The workaround in this issue describes giving artifact-template-picker a stable mcp_servers.<id>.cwd, with Desktop overlaying that onto its current launcher configuration.

I tried that.

I created a complete artifact-template-picker MCP definition using the actual command and arguments that Desktop was launching, plus a stable working directory outside .chatgpt-projects.

codex mcp list --json accepted the configuration and reported the expected stable cwd.

Despite that, ChatGPT Desktop continued spawning:

node.exe "...app\resources\artifact-template-picker\server.mjs"

with the ChatGPT Project mirror as its working directory.

The observed process tree was:

ChatGPT.exe
-> Desktop-owned codex.exe ... app-server
-> node.exe ...\artifact-template-picker\server.mjs

Sysinternals Handle showed that final node.exe process holding an open handle to the affected .chatgpt-projects\<project-id> directory.

I then set the configured artifact-template-picker MCP server to:

enabled = false

and confirmed with codex mcp list --json that Codex considered it disabled.

ChatGPT Desktop nevertheless continued launching the packaged artifact-template-picker\server.mjs during Local Work initialization/submission.

That suggests that, on 26.908.4834.0, the artifact-template-picker instance launched by the Desktop app-server is not honoring the normal user MCP cwd or enabled configuration.

Controlled reproduction

I was able to reproduce the following sequence repeatedly:

Before creating the Local Work chat, the affected project mirror had no helper-process handles.
Creating or submitting the Local Work chat caused Desktop to launch:

node.exe ...\artifact-template-picker\server.mjs
That process acquired the affected project mirror as its working directory.
Local Work then failed with:

Could not use this project for a local chat
Killing only the artifact-template-picker process removed the project-directory handle.

There was an additional timing detail:

If the Local composer had already initialized successfully and the failure occurred on first-message submission, killing artifact-template-picker and retrying the same submission could succeed.
If creation of the new Local chat itself had already failed, killing the picker afterward was too late. That chat initialization was already in a failed state.

So the process needed to be prevented from retaining the project mirror before the Local Work initialization/submission operation reached the directory replacement step.

Workaround that restored repeated Local Work task creation

As a diagnostic workaround, I used a narrowly scoped polling guard that repeatedly inspects node.exe processes and immediately terminates only those whose command line matches:

artifact-template-picker\server.mjs

Simplified logic:

while ($true) {
    $nodes = Get-CimInstance Win32_Process -Filter "Name='node.exe'"

    foreach ($proc in $nodes) {
        if (
            $proc.CommandLine -match
            '[\\/]artifact-template-picker[\\/]server\.mjs'
        ) {
            Stop-Process -Id $proc.ProcessId -Force
        }
    }

    Start-Sleep -Milliseconds 10
}

Before testing this against ChatGPT, I verified the guard against a harmless dummy server.mjs process using the same bundled Node runtime. The guard successfully detected and terminated the dummy process.

I then tested it against the actual Desktop application.

The guard repeatedly detected and terminated the real packaged picker process. Example observed timings were roughly 40 to 50 ms between detection and confirmed termination.

With the polling guard active:

a fresh Project -> Work -> Local chat initialized successfully;
first-message submission succeeded;
a second fresh Local Work chat also succeeded;
a subsequent fresh Local Work test also succeeded.

I reproduced successful fresh Local Work creation/submission multiple times after previously being unable to use this Project reliably.

After successful tests, Sysinternals Handle reported no remaining helper processes holding the project mirror.

Important limitation

This is a workaround, not a product fix.

It deliberately prevents artifact-template-picker from running, so the interactive artifact-template selection experience may be unavailable while the guard is active.

I did not modify anything under WindowsApps and did not alter signed application binaries.

Why this may matter for the existing issue

The underlying Windows project-mirror locking mechanism described in this issue still appears to be correct.

What seems different on 26.908.4834.0 is that the Desktop-owned app-server launches artifact-template-picker in a way that bypasses or overrides the user MCP configuration that was sufficient in the earlier workaround.

A product-side fix could potentially:

launch artifact-template-picker with a stable working directory outside .codex\.chatgpt-projects;
ensure the Desktop-spawned picker honors the supported MCP cwd setting;
avoid launching it when the MCP is explicitly disabled; and/or
coordinate helper lifetime with project-mirror replacement so an application-owned helper cannot block the Windows directory rename.

I can provide additional Handle output, process-tree output, or configuration details if useful.

Windows desktop: project-folder sharing violations block new Work chats; Node helpers and background Word processes implicated

Environment:

Windows 11
ChatGPT desktop package observed: OpenAI.Codex 26.908.4834.0
Existing ChatGPT projects used for local Work chats

Error:
“Could not use this project for a local chat”

Observed behavior:
New local Work chats fail in multiple projects. Completely exiting and reopening ChatGPT does not prevent recurrence.

Process Monitor captured:

ChatGPT.exe opening the affected project’s local mirror directory.
Operation: CreateFile
Desired Access: Read Attributes, Delete, Synchronize
Result: SHARING VIOLATION
Directory pattern: %USERPROFILE%.codex.chatgpt-projects<project-id>

Evidence:

In one project, terminating several Node/REPL helpers did not restore access until a remaining node.exe was stopped. New-chat creation then succeeded, and the associated-handle search was empty.
After restarting ChatGPT, another project reproduced the same sharing violation.
Resource Monitor showed eight newly launched bundled helpers holding that second project directory:
- Browser/computer-use cua-repl helpers and their node_repl children
- Artifact-template-picker helpers
- Direct node_repl helpers
Those eight helpers started at approximately 11:21:39; the sharing violation occurred at 11:21:52 on September 14, 2026, Eastern time.
After terminating the Node/REPL holders, the error persisted while two background WINWORD.EXE processes held report files inside the project directory. Documents had been saved and visible Word windows closed.
Terminating those remaining Word processes restored successful new-chat creation.

Reproduction scenario:

Open an existing ChatGPT project in local Work mode.
Allow bundled helpers to start and/or open a generated Word report from within the local project mirror.
Attempt to create a new local Work chat in that project.
If the error appears, capture filesystem activity for .chatgpt-projects and inspect associated handles.
Release the processes holding conflicting references and retry.

Limits:
An open handle alone does not prove it blocks synchronization. Processes were stopped sequentially, so these tests do not establish that every listed helper independently causes the failure.

Requested engineering investigation:

Coordinate project synchronization with helper startup and existing sessions.
Avoid replacing a directory that active helpers or document applications are using.
Give bundled helpers stable working directories outside replaceable project mirrors where appropriate.
Surface the failing path and Windows sharing-violation details instead of a generic error.
Handle reports opened in Office without requiring users to terminate background Office processes.

Available evidence:
Filtered Process Monitor CSV, Resource Monitor screenshots, desktop log entries, and troubleshooting history.

Related public report:
#44736

Customer-impact escalation for this existing Work handoff bug, submitted at the user's explicit request.

The desktop repeatedly shows “Could not use this project for a local chat” when the user selects “Continue in Work.” The user reports that this has happened many times and wants the underlying problem fixed, not repeated instructions to switch manually.

The troubleshooting also caused avoidable frustration: the assistant initially confused its own tool limitations with the visible UI capability, offered a premature causal explanation that it later retracted, and repeatedly stopped at explanations, apologies, and restart advice instead of completing the repair. The user states that they are a software customer, not a volunteer debugger.

The available troubleshooting conversation spans approximately 24.2 wall-clock minutes, including waiting and user exchanges. The latest recorded cumulative token snapshot is:

Input: 6,110,760
Cached input (subset of input): 5,733,760
Output: 18,377
Total input plus output: 6,129,137

These counters include repeated/cached context. They are not a claimed bill, quota deduction, or exact amount of avoidable waste. Later reporting calls are outside this snapshot.

The user explicitly asks OpenAI to receive the errors, time burden, and token usage, to resolve the Work switching defect, and to review the attributable usage burden. Please route the usage/credit review to the appropriate support team.

No machine logs, process details, configurations, private paths, credentials, account identifiers, project data, screenshots, or conversation transcripts are included. No permanent fix or successful UI verification is claimed.

@zmydsg

Independent reproduction and UI-confirmed recovery on 26.908.9136.0

Reproduced on Windows x64 on 2026-09-15 with package OpenAI.Codex 26.908.9136.0. This corroborates the helper-lock report and the project-local configuration watcher observation in this comment.

Observed evidence

Selecting local Work in an existing ChatGPT project repeatedly produced “Could not use this project for a local chat”. The relevant logs included:
```
ChatGPT project context sync failed fileOrdinal=null projectSaveCount=0 sourceCount=0 stage=filesystem status=null syncFileCount=0
```
Before retrying, no matching project-directory handles were found. During the retry, process working-directory inspection and handle enumeration found six handles to the mirror: direct node_repl.exe, two Python processes for the configured Zotero MCP integration, the artifact-template picker, and cua_repl plus its REPL child.
A non-mutating CreateFileW probe requesting DELETE access with read/write/delete sharing returned WinError 32 for the mirror. A disposable create/write/rename test in its parent passed. After stopping the identified helpers for the failed attempt, the sharing probe passed.
Giving helpers stable working directories through a configuration file inside the mirror was insufficient: subsequent UI retries still failed. At that stage the helpers had moved outside the mirror, while the app-server held a handle to <mirror>\.codex. Moving the configuration outside the mirror and relocating the now-empty local configuration directory was followed by a successful real mirror rename-and-restore and, finally, user-confirmed entry into local Work through the UI. This sequence supports the watcher explanation; the original failing filesystem syscall/error for that second failure was not captured.

Configuration details that may help others investigate

On this installed build, the desktop's injected template-picker configuration key is mcp_servers.openai_artifact_template_picker. That is the exact key we used for the stable cwd override. Please distinguish it from a separately configured server named artifact-template-picker; I cannot establish whether this explains the differing result reported above.
The shared %USERPROFILE%\.codex\.chatgpt-projects\.codex\config.toml did not load merely because the individual mirror was trusted. We needed both a custom parent root-marker file (retaining .git in project_root_markers) and trust for that shared parent. config/read with the mirror's cwd and includeLayers: true then confirmed the shared layer and the effective helper working directories.
Stable directories were configured for node_repl, zotero, openai_artifact_template_picker, and cua_repl. For cua_repl, a local launcher read the installed plugin's current MCP manifest and forwarded its command/environment from the stable directory. Its MCP initialization and tool-list request passed. We did not modify the installed plugin manifest or signed application files.

Verification limits / regression coverage

This confirms recovery of one affected project's local-Work entry flow. It does not establish successful prompt execution, repeated task creation, other projects, or persistence after app/plugin updates or restarts. We did not isolate every helper independently, and a handle's presence alone does not prove it blocks a rename.

Please cover both helper working directories and configuration-directory watchers when testing mirror replacement. Exposing the failed filesystem operation and original OS error would also make the generic stage=filesystem failure much easier to diagnose. Project reference contents were preserved; usernames, project identifiers, and raw logs are omitted here.

Request for maintainer-approved contribution scope

I have read the current contribution policy, including the restriction on external code contributions and PRs. Before preparing an upstream patch, would the maintainers be willing to authorize a narrowly scoped Windows regression-test contribution for this issue?

The proposed scope is a minimal reproduction using disposable directories and dummy helpers, covering:

a helper retaining the mirror as its working directory;
an active configuration-directory watcher beneath the mirror;
synchronization after helpers/watchers have started, with user-created files preserved.

The initial deliverable would distinguish the Windows filesystem behavior from the app-specific failure; an integrated regression test would need to exercise the actual synchronization path. I would follow the maintainers' chosen implementation rather than submit the machine-specific workaround as a product fix.

If such a contribution can be accepted, could you identify the appropriate public component and preferred test location? My aim is to submit an attributable test or fix commit under @zmydsg, with credit retained for the earlier reports of the underlying mechanism. I will wait for explicit maintainer agreement before opening a PR. If this must remain an internal desktop change under the current policy, please let me know.

Independent reproduction: Windows 10 Home 22H2 build 19045, ChatGPT Desktop / OpenAI.Codex 26.908.9136.0, Windows-native agent. Creating Local Work inside a ChatGPT Project repeatedly fails with “Could not use this project for a local chat”, while standalone Local Work works. Windows Resource Monitor shows node_repl.exe and the artifact template picker holding the project mirror open during the failure. A temporary diagnostic workaround that prevented those helper processes from retaining the mirror allowed Local Work to start successfully in both a new test project and an existing project. WSL is not configured on this machine, so I could not compare behavior under WSL.

OpenAI Support diagnostic references:

Feedback/session ID: no-active-thread-01a0a628-cd65-73e0-b110-1842f1f5288e
Session transcript ID: 01a0a614-2868-7f51-afb6-325764f26d85
%USERPROFILE%\.codex\.sandbox\sandbox.log is not present on this machine.
Project mirror is on the local Windows filesystem under %USERPROFILE%\.codex\.chatgpt-projects\....

Additional occurrence on Windows 10 Pro (10.0.19045), installed desktop package OpenAI.Codex 26.915.4065.0, bundled Codex 0.155.0-alpha.9.2, observed 2026-09-20.

The user repeatedly sees the German message “Dieses Projekt konnte nicht für einen lokalen Chat verwendet werden” both when submitting a prompt with a ChatGPT project selected and when trying to move an existing local task into that project. These UI triggers are user-reported; the investigation independently verified the following log evidence.

Three desktop log entries:

2026-09-20T19:18:18.423Z error ChatGPT project context sync failed fileOrdinal=null projectSaveCount=0 sourceCount=0 stage=filesystem status=null syncFileCount=0
2026-09-20T19:18:57.989Z error ChatGPT project context sync failed fileOrdinal=null projectSaveCount=0 sourceCount=0 stage=filesystem status=null syncFileCount=0
2026-09-20T19:22:07.552Z error ChatGPT project context sync failed fileOrdinal=null projectSaveCount=0 sourceCount=0 stage=filesystem status=null syncFileCount=0

These are UTC timestamps. Nonessential renderer/window fields have been omitted. Zero source files were involved in these failures.

The preceding day's desktop log contains 281 occurrences of:

Failed to prewarm local conversation errorMessage="Unknown local project" errorName=Error errorStack="Error: Unknown local project"

between 2026-09-19T07:12:34.192Z and 07:16:49.677Z. Whether these warnings share the filesystem failure's root cause is unconfirmed.

Read-only inspection of the installed bundle associates the exact German message with chatgptConversations.localProjectSync.error. In the failing flow, the project fetch has completed and execution is inside the filesystem synchronization call. The underlying filesystem exception/code is absent from the desktop log.

Additional project-state observation: the desktop legacy project mappings and app-server project records use different IDs, with an explicit ID mapping present. Migration state reports projectsMigrated=true, threadAssignmentsMigrated=false and pending thread assignments. A specifically requested task was projectless in both stores. A supported thread/metadata/update request using the existing local project ID succeeded, but the legacy desktop assignment list remained unchanged immediately afterward. This is an observation about the attempted recovery, not evidence that it caused the original sync failure.

The directory-lock explanation in this issue is plausible, but no handle/rename probe was performed on this machine, so a sharing violation is NOT independently confirmed here. No project mirrors were deleted or renamed, and no active tasks were terminated.

Please retain the original filesystem error details in diagnostic logs and verify both new-task creation and assigning an existing task to a ChatGPT project on Windows, including empty-source projects and incomplete legacy-to-app-server assignment migration.

New reproduction on Windows desktop 26.917.6896.0 (2026-09-23)

A user again could not send a new local Work message inside an existing ChatGPT Project. The desktop showed “Could not use this project for a local chat” (Russian UI). This recurred after many prior app restarts and cost the user substantial time troubleshooting a paid product.

Environment: Windows 11 Pro 10.0.26200; Microsoft Store package OpenAI.Codex_26.917.6896.0_x64; bundled Codex CLI 0.155.0-alpha.16.

Observed:

Desktop log: ChatGPT project context sync failed ... stage=filesystem ... sourceCount=0 syncFileCount=0 projectSaveCount=0. The failure occurred before source-file handling.
Microsoft Sysinternals Handle found two app-spawned node_repl.exe processes holding the project's local mirror directory open. Windows refused a reversible rename of that root with sharing violation (error 32). Stopping only those idle helpers allowed the same rename-and-restore check to pass.
Another attempt recreated a project-bound node_repl.exe child of cua_repl and the same sync error. This showed that stopping helpers alone was temporary.
We configured stable helper working directories for node_repl (through a trusted shared project config, because desktop startup rewrites the global table) and cua_repl (plugin manifest). A fresh configuration read resolved both to directories outside the project mirror. The still-running desktop process continued to use cached helper configuration, so attempts still failed.
After fully exiting and reopening the app after the configuration change, the user confirmed that the local Work message was sent and the task began running from the project's mirror directory. Project files and conversation names were not deleted or renamed.

The user asks for a product fix. Please coordinate project-context synchronization with helper prewarming, avoid swapping a project root while app-owned processes use it as a working directory, and reload helper configuration predictably. Regression tests should cover typing before submission, repeated new Work chats, a zero-source project, and restart/update behavior. The workaround is machine-local and may be overwritten by plugin updates.

Follow-up: update reverted the workaround (same day)

After the desktop app updated to OpenAI.Codex_26.917.8451.0_x64 (bundled unified-computer-use plugin 26.917.62051), the user reported failure when moving an existing local Work task into the same ChatGPT Project. The new plugin manifest lacked the prior explicit mcpServers.cua_repl.cwd setting. Sysinternals Handle identified an app-spawned node_repl.exe child of cua_repl with an open handle to the project mirror root. A read-only Windows CreateFileW probe requesting DELETE access to the root returned sharing violation (32); the child sources directory remained accessible. I restored the stable cua_repl.cwd in the updated manifest and stopped only that identified helper/launcher pair. The same root access probe then succeeded, and remained successful after a fresh CUA tool invocation. User verification: after the lock was released, the user repeated the move and confirmed that the existing Work task “ТЕНДЕРЫ - внедрение” appeared inside the “ТЕНДЕРЫ” ChatGPT Project. This confirms successful project assignment in the UI for this recurrence; it does not prove the workaround will survive another plugin update. This shows the workaround is erased by plugin updates and the project-root lock returns. Please test existing-task moves after desktop/plugin updates as well as new-task creation.

I am experiencing the same error on Windows with ChatGPT/Codex app version 26.917.8451.0.

Error
“Could not use this project for a local chat”
Spanish UI: “No se ha podido usar este proyecto para un chat local”

Reproduction and behavior

Uninstall and reinstall the Windows desktop app.
Open a ChatGPT Project and start Work in Local mode. It works initially.
After using Local Work, try to start another local chat from a Project.
The error returns and prevents new local chats across all my ChatGPT Projects.

Reinstalling only fixes the problem temporarily. Restarting Windows and renaming Projects do not resolve it.

Observed handles
Windows Resource Monitor shows node.exe and node_repl.exe holding open handles to project mirror directories under:

C:\Users\<user>\.codex\.chatgpt-projects\g-p-...

The handles disappear after completely closing ChatGPT and terminating the remaining processes. However, reopening the app and attempting Local Work starts those processes again, and they hold the project directories open again.

These observations appear consistent with the locking problem described in this issue, although I have not independently confirmed the internal cause.

Expected behavior
Creating local Work chats should continue to work across all Projects and subsequent sessions without reinstalling the app or manually terminating helper processes.

Additional reproduction on Windows desktop 26.917.9434.0 (2026-09-24)

I am seeing the same failure on a newer Windows desktop build.

Environment

Windows 11 ARM64 under Parallels Desktop 27.0.2
Microsoft Store package: OpenAI.Codex_26.917.9434.0_arm64
Desktop log release field: 26.917.71314

Observed behavior

Starting a local chat inside an existing ChatGPT Project fails with “Could not use this project for a local chat.”
The folder trust prompt was accepted, and the project configuration shows trust_level = "trusted".
Logs contain ChatGPT project context sync failed with stage=filesystem.
The failure also occurred with a project containing zero synced source files.
Multiple node_repl.exe processes were observed using directories under %USERPROFILE%\.codex\.chatgpt-projects\g-p-....
A non-destructive filesystem access check reproduced Windows sharing violation error 32 while those helpers were attached to the project mirrors.
Terminating only the affected helper processes released the locks; the same diagnostic then succeeded, and one retry of the local-chat workflow succeeded.
The problem later reproduced when newly spawned helper processes again used the project mirror directories.
Adding a dedicated cwd for node_repl helped some launch paths, but did not prevent recurrence. After restart, processes using the dedicated workdir and other node_repl processes using project mirrors were both present.
The unified-computer-use / cua_repl launch configuration appears to be another possible helper-launch path; no plugin files were modified during this test.
After a second targeted cleanup of project-bound node_repl processes, the user still observed a send failure, and new project-bound helpers appeared again shortly afterward.

This makes the current workaround non-durable on 26.917.9434.0 and appears consistent with the helper working-directory / project-mirror locking mechanism described in this issue.

I have also observed the same user-facing error on a separate native Windows machine, not only under Parallels. I have not yet collected equivalent logs/handle evidence on that second machine, so I am not claiming the same root cause there yet.

No project mirrors, project content, or trust settings were deleted during this investigation.

Confirmed on Windows x64 with ChatGPT/Codex Desktop build 26.917.71314.

Creating a new local Work/Codex chat inside an existing ChatGPT Project failed with:

Could not use this project for a local chat

Control tests:

Local Work outside the ChatGPT Project: works
Cloud Work inside the same ChatGPT Project: works
Local Work inside the ChatGPT Project: fails

The workaround from this issue restored Local Work:

set mcp_servers.node_repl.cwd to a stable directory outside the .chatgpt-projects mirror
add the .chatgpt-projects-root marker
include .chatgpt-projects-root in project_root_markers
trust the .codex/.chatgpt-projects root
fully restart Desktop

After that, new Local Work sessions inside ChatGPT Projects worked again.

I also observed:

session-flags: features.thread_tools is ignored

while thread_tools was absent from the user config.toml. No change to that flag was required to restore Local Work.

So this is another independently reproduced case where moving the helper CWD out of the rotating ChatGPT Project mirror resolves the failure.

— Prisme🌈軸

Reproducible Windows ChatGPT Work issue: second local handoff in same Project fails after first task
I can reproduce this consistently in the ChatGPT Windows desktop app when using local Work inside the same ChatGPT Project.
Steps to reproduce

Open an existing ChatGPT Project in the Windows desktop app.
Start a Work handoff/local Work chat.
Let that Work task complete.
Try to start a second Work handoff in the same Project.
The second handoff fails.
Fully restarting the ChatGPT desktop app restores the ability to start a Work handoff again.
Process Explorer findings
After the first Work task completed, I searched the affected project mirror with Microsoft Process Explorer:
C:\Users<username>.codex.chatgpt-projects<project-id>
I found multiple node_repl.exe processes holding handles inside that project directory. In one reproduction there were also node.exe and codex.exe processes attached to the project mirror.
I tested killing only the stale project-specific node_repl.exe processes after confirming no Work task was running.
In one case, clearing those processes allowed another Work handoff to succeed without restarting ChatGPT.
In another case, after killing the node_repl.exe processes, only codex.exe remained attached to the project directory and the second handoff still failed. Restarting the ChatGPT desktop app then restored the handoff.
I reproduced the sequence multiple times:
restart app → first Work handoff succeeds → task completes → second handoff fails
The local helper processes appear to remain associated with the Project after task completion.
Expected behavior
Once a Work task finishes, its local runtime/helper processes should release the Project mirror so another Work handoff can start immediately.
Observed workaround

Full ChatGPT desktop restart reliably restores one successful Work handoff.
Killing stale project-specific node_repl.exe processes sometimes restores the next handoff without restarting.
Possible failure mode
This looks consistent with a stale local runtime/project-mirror state on Windows. A completed Work task appears to leave handles open under .codex.chatgpt-projects<project-id>, and the next local-chat initialization/sync then fails.
I have Process Explorer screenshots showing the relevant node_repl.exe, node.exe, and codex.exe handles and can provide them if useful.
In-app Feedback ID: no-active-thread-01a0d568-3c21-7f13-b8b9-23a8a670617f

Follow-up evidence: #48534 documents that the working node_repl.cwd + cua_repl.cwd workaround restores Local Work repeatedly, but subsequent desktop/plugin updates recreate the versioned unified-computer-use/<version>/.mcp.json without cua_repl.cwd, causing the same stage=filesystem failure to return. The workaround has been re-applied successfully approximately four times in the reported environment.

Additional reproduction on Windows desktop 26.924.22138 (2026-09-28)

The same problem is reproducible on Windows x64 with ChatGPT/Codex Desktop 26.924.22138, build 11645 (Windows package 26.924.2738.0). The app's update check reported up_to_date for its configured release channel.

Reproduction: Select an existing ChatGPT Project, start a new local Work chat, type the first prompt, and attempt to send. The UI repeatedly reports 无法将此项目用于本地聊天 (“Could not use this project for a local chat”). The original local business directory and its instructions/context files still exist and are readable.

Sanitized desktop log fields:

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

Direct observations

A node_repl.exe process had the affected %USERPROFILE%\.codex\.chatgpt-projects\<project-id> mirror as its current working directory.
A nonmutating Win32 directory-handle probe requesting DELETE access with OPEN_EXISTING, read/write/delete sharing, and FILE_FLAG_BACKUP_SEMANTICS returned ERROR_SHARING_VIOLATION (32) for the mirror root. The parent directory and sources subdirectory passed. This test did not rename, delete, or write anything.
After stopping only the verified owning process, the same probe succeeded. Hashes of the checked local business instructions/context and mirrored source/instructions were unchanged.
On the next attempt, the mirror regenerated; about one second later a new node_repl.exe started with that mirror CWD. The probe again returned error 32, and repeated submissions again failed at the filesystem stage. Stopping the old helper therefore did not restore reliable normal creation.

Interpretation and limits

Read-only inspection of the installed JavaScript indicates that project synchronization stages a new directory and renames the existing mirror before replacement. The new-chat composer can prewarm a thread, while submission synchronizes project context again. This is consistent with the prewarming/directory-swap conflict reported here; the logs do not expose the exact failing filesystem syscall.

Creating a same-directory fork from an existing local task succeeded, preserving its original local workspace and ChatGPT project assignment. This bypass does not demonstrate that normal creation of a fresh, empty local Work chat is fixed. No application binaries, helper configuration, trust settings, or project sources were modified as a repair.

Please cover the fresh-composer prewarm → send sequence on Windows in a permanent fix. Users should be able to create successive local Work chats through the normal project entry point without terminating helpers or repeatedly forking old conversations.

Private project names, account/thread/project IDs, screenshots, business content, and full logs are omitted from this public report.

Recurrence on 2026-09-30: existing project with 17 source files

This is a further occurrence from the same user who reported and confirmed recovery on September 23 (#44736 (comment)).

Environment: Windows desktop package OpenAI.Codex_26.924.2738.0_x64; bundled unified-computer-use plugin 26.924.22138.

The user again could not create a local Work chat inside an existing ChatGPT Project whose working materials were already uploaded.

Fresh desktop logs (UTC):

2026-09-30T05:00:29.067Z
2026-09-30T05:01:04.535Z
2026-09-30T05:01:25.006Z
ChatGPT project context sync failed
fileOrdinal=null projectSaveCount=0 sourceCount=17
stage=filesystem status=null syncFileCount=17

Independent checks:

All 17 mirrored source-file SHA-256 values match the saved project metadata.
A nonmutating CreateFileW probe requesting DELETE access to the mirror root returned ERROR_SHARING_VIOLATION (32).
Sysinternals Handle identified a node_repl.exe child of the app's cua_repl launcher holding that exact mirror root.
The currently installed plugin manifest again had no mcpServers.cua_repl.cwd override; the previous workaround was in the prior plugin version.
After backing up the manifest, restoring a stable cwd outside the mirror, and stopping only the identified helper and launcher, the same root-access probe succeeded.
Project sources and names were not changed. End-to-end retest failed: after the lock was released, the user tried the desktop composer again and received the same error; the project still had no newly created local chat. Therefore, the successful handle probe did not restore this workflow. We have not established whether the retest used cached helper configuration or encountered another filesystem failure. The user has now chosen to migrate the project materials to a separate ordinary local folder to regain a working chat. This fallback does not fix or resolve the original product defect.

Please escalate this as a recurring product defect. We need an engineering owner or internal tracking reference, a supported mitigation that survives updates, and the planned fixed release or a clear next diagnostic step. Please cover prewarm → first send, repeated new local chats, projects with uploaded files, and app/plugin upgrades in regression testing. Restarting or reapplying a per-version manifest patch is not a durable resolution.

Private project identifiers, filenames, document contents, usernames, and raw logs are omitted.

Still reproducible on Windows package 26.928.4866.0 — fresh read-only evidence (2026-10-02)

Follow-up to the September 28 report. Creating a fresh local Work chat inside an existing ChatGPT Project still fails with 无法将此项目用于本地聊天 (“Could not use this project for a local chat”). Existing local chats can run. The user reports that fully exiting and reopening the app did not resolve the failure.

Environment: Windows x64; the running app executable belongs to Microsoft Store package OpenAI.Codex_26.928.4866.0_x64. This is the observed installed package version, not a claim that it is the latest available release.

Fresh desktop logs (UTC):

Seven matching failures occurred between 2026-10-02T15:22:50.227Z and 2026-10-02T15:23:16.524Z. The final failure records:

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

The next performance record reports outcome=failure reason=submit_failed submissionKind=new_thread.

Independent live checks:

The affected project's local mirror is under %USERPROFILE%\.codex\.chatgpt-projects\<project-id>.
A nonmutating CreateFileW probe on the mirror root, requesting DELETE access with OPEN_EXISTING, read/write/delete sharing and FILE_FLAG_BACKUP_SEMANTICS, returned ERROR_SHARING_VIOLATION (32). No rename or deletion was attempted.
At approximately 15:42 UTC (a later snapshot, not a trace taken at the 15:23 failures), 24 readable processes were confirmed to hold that exact mirror root as their current directory: 11 node_repl.exe, 10 node.exe, 2 codex.exe, and 1 pwsh.exe.
This was checked by reading each process's current-directory descriptor, duplicating its existing current-directory handle into the diagnostic process, and resolving the duplicated handle with GetFinalPathNameByHandleW. Only the diagnostic copies were closed; no target process or original handle was terminated or closed. This is a snapshot of confirmed holders, not an exhaustive system-wide handle enumeration or a claim that every holder independently blocks replacement.

Installed implementation inspected read-only:

In app.asar, .vite/build/main-DzkezlCV.js, the wC() synchronization function creates a staging directory, then attempts to rename the existing mirror to a previous-directory name before renaming staging into the live mirror path. A failure renaming the old root, other than ENOENT, aborts the operation and is wrapped as a filesystem-stage project-sync error. Even when source files are reused from the cache, this sync path still attempts to rename/swap the project mirror root.

This is consistent with live current-directory handles preventing the directory swap. The logs do not include the failed syscall, project path/ID, or owning PID, so they do not by themselves prove which process caused a particular submission failure. The current directory-lock observation and code path make this a strong explanation, not a captured syscall trace.

This investigation did not change project content, application binaries, helper settings or trust settings; it did not stop processes, close their original handles, or rename/delete directories. No end-to-end repair is claimed.

Please include the following in the product fix/regression tests:

Repeated creation of new local Work chats in the same ChatGPT Project while existing local chats/helpers are open.
The composer prewarm → first-send path, app restarts, and app/plugin updates.
Project synchronization that remains usable without forcing users to stop existing tasks, kill helper processes, or fork an old chat every time.
Actionable diagnostics identifying the failing filesystem operation and affected resource, with privacy controls.

Private usernames, project names/IDs, chat IDs, full local paths, individual PIDs, screenshots, business files, and full logs are intentionally omitted.

Independent confirmation: project-mirror lock prevents local Work chat creation on Windows

I independently reproduced the issue described here.

Starting a new local Work conversation inside an existing ChatGPT project fails with:

Could not use this project for a local chat

Desktop logs report:

ChatGPT project context sync failed
stage=filesystem

Evidence

A filtered Process Monitor capture showed this sequence:

The desktop app successfully rotated the local project mirror.
A bundled node_repl.exe process opened the replacement project directory with ShareMode: Read, Write, without delete sharing.
Approximately ten seconds later, ChatGPT.exe attempted to open the same directory with delete access and received SHARING VIOLATION.
The app logged the project-context synchronization failure immediately afterward.

Controlled recovery test

The helper process remained running. After terminating only the identified node_repl.exe process, creating a new local Work conversation in the same project succeeded.

No project files, filesystem permissions, or configuration settings were changed during this test.

This confirms recovery after releasing the identified helper process. It does not establish a permanent fix or persistence across restarts and updates.

Expected behavior

Bundled helpers should use a stable working directory outside the project mirror that the app replaces during synchronization.

Starting a local Work conversation should not require users to identify and terminate helper processes.

Diagnostic improvement requested

The current UI error and synchronization log omit the failing operation, path, and native Windows error. Including these details would substantially reduce troubleshooting time.

This comment intentionally omits personal information, hardware details, actual filesystem paths, project identifiers, filenames, process IDs, and exact timestamps.

Is anyone working on this? Paid accounts should have a functional desktop app. In my particular situation, I need to use the desktop app for co-browsing with the Chrome extension and I'm getting pretty tired of having to copy and paste screenshots to use an existing Work project. There are now multiple documented cases across operating systems and app versions. Additionally, there is at least one other thread going with similar reports under #42215. Unacceptable.

For anyone still hitting “Could not use this project for a local chat” on Desktop:

There is now fairly strong independent evidence for one specific Windows failure mode documented in this issue.

In confirmed cases, the sequence is roughly:

ChatGPT Desktop prepares / prewarms a local Work thread.
A helper process such as node_repl.exe starts with the ChatGPT Project mirror as its working directory:
%USERPROFILE%\.codex\.chatgpt-projects\<project-id>
When the message is submitted, Desktop synchronizes the Project context again and attempts to replace/rotate that mirror.
Windows refuses the operation because the directory is still held open.
Desktop reports:
ChatGPT project context sync failed
stage=filesystem

A recent independent Process Monitor reproduction strengthened this considerably: the helper opened the mirror without delete sharing, ChatGPT later attempted delete access and received SHARING VIOLATION, and stopping only that identified helper allowed a new Local Work conversation to start successfully.

That said, the same UI error does not prove the same root cause.

Before applying any workaround, I would suggest checking:

OS and exact Desktop/package version
whether Local Work works outside ChatGPT Projects
whether the log contains stage=filesystem
whether a process actually holds the affected .chatgpt-projects\<project-id> mirror
ideally, whether Windows reports a sharing violation at the time of failure

If the lock is confirmed, the least destructive recovery test is to identify the exact idle helper holding that mirror and release only that process — not delete the Project cache or terminate every Node process indiscriminately.

For recurring confirmed cases, using a stable cwd outside the rotating Project mirror for the relevant helper(s) remains the most successful mitigation reported so far.

This is still a workaround, not a product fix. Desktop/plugin updates can recreate helper configuration and reintroduce the failure.

For cases showing the same UI error but no confirmed directory lock, please keep reporting them separately. #42215 appears to contain a broader family of Project → Local Work failures, and conflating them would make diagnosis harder.

The most useful additional reports are not just “same here”, but:

exact version
exact reproduction sequence
relevant stage=filesystem log lines
the process holding the mirror, if confirmed
native Windows error / Process Monitor evidence where available
whether releasing that specific process changes the outcome

That gives engineering something much more discriminating to work with.

— Prisme🌈軸

@scoldiSF

@scoldiSF Your earlier reproduction is particularly useful because you already established an important control:

Local Work + Chrome / Computer Use works outside the ChatGPT Project
the same Desktop session fails when Local Work is started inside the existing Project
the logs show stage=filesystem
node_repl.exe was observed holding the affected Project mirror

So I would not treat your case as a generic Chrome-extension or account problem. It is strongly consistent with the Project-mirror locking failure documented in #44736.

Unfortunately, I have not seen evidence yet that the underlying product defect has been permanently fixed.

If you want the least destructive recovery path, I would avoid deleting .codex\.chatgpt-projects, rebuilding the Project, or killing every Node process.

Instead:

Reproduce the failure once.
Identify which process is holding the exact affected mirror:
%USERPROFILE%\.codex\.chatgpt-projects\<project-id>
Make sure that helper is not serving an active local task.
Stop only the identified idle holder.
Retry creating the Local Work conversation.

That has restored creation in independently reproduced cases.

If it immediately returns on the next task, that points back to the helper working-directory problem rather than stale cache alone. In that case, the more durable mitigation has been to give the relevant helper a stable cwd outside .chatgpt-projects.

I would still call that a workaround, not a fix: app/plugin updates have been reported to overwrite parts of the helper configuration and cause the failure to return.

Given that your workflow specifically depends on Desktop co-browsing, your reproduction is also a good regression case for OpenAI: Local Work + Computer Use outside Projects should not work while the equivalent Project-linked workflow fails because Desktop’s own helper processes prevent Project synchronization.

— Prisme🌈軸

Additional Windows reproduction and recurring failure — October 16, 2026

Reporting another affected installation with the user's authorization. Successive local Work chats inside a ChatGPT Project remain unreliable. The user needs approximately 50 new task chats daily; creating unrelated chats and manually moving them is not a practical replacement.

Environment / reproduction

Inspected running Windows Store package: OpenAI.Codex_26.930.4958.0_x64.
Select a ChatGPT Project, choose local Work, enter a prompt and send: Could not use this project for a local chat (localized in Russian).
A newly created replacement project also failed. Sidebar regrouping did not resolve initialization. Temporary recovery was followed by recurrence.

Diagnostic observations

A read-only directory-open probe requesting DELETE access with read/write/delete sharing returned ERROR_SHARING_VIOLATION (32) for %USERPROFILE%\.codex\.chatgpt-projects\<project-id>. Equivalent probes on generated AGENTS.md and sources succeeded.
Bundled node_repl.exe processes had the project mirror as their OS current working directory. Stopping one verified idle holder changed the root probe to success; later helper startup recreated the condition.
Read-only inspection of the installed synchronization code showed staging followed by replacement of the existing mirror through directory renames, including with no synchronized sources, consistent with the Windows lock conflict.
An earlier global node_repl.cwd mitigation was absent at recurrence. Which writer removed it on this installation was not established.
A stable cua_repl.cwd in the current plugin manifest was still present. A local launcher mitigation also remained, but later browser-helper sandbox/command-runner processes were observed using a project mirror as their OS working directory. Testing only MCP initialization/tool listing had not exercised those later processes.

This supports a synchronization/helper-lifecycle failure, not proof that one helper is the sole possible holder. Existing mirrors contain user-created work, making destructive mirror resets unsuitable.

Requested product fix
Please prevent mirror synchronization from conflicting with prewarmed helpers and existing local sessions. Regression coverage should include successive chats through the normal composer, later browser/helper initialization, active sessions, restart, and app/plugin updates. Preserve supported working-directory overrides and report the failing filesystem operation/native Windows error.

Related: #48534 and #49047. No permanent fix is claimed here. Private project names/IDs, usernames, chat contents, screenshots and raw logs are omitted.

Windows: ChatGPT project prewarming locks local mirrors; startup erases node_repl cwd workaround #44736

Description

Codex App version

Subscription

Platform

Problem observed by the user

User impact and troubleshooting cost

Environment

Diagnosed failure mechanism

Why earlier repairs did not resolve the recurrence

Workaround that finally worked

Verification and limits

Required permanent product resolution

Activity

github-actions commented on Sep 11, 2026

ErnestoCampese commented on Sep 11, 2026

scoldiSF commented on Sep 12, 2026

saigyujikingyo-png commented on Sep 12, 2026

Independent reproduction on 26.908.4834.0: a fresh draft recreates the directory lock

Correlated observations (UTC)

Filesystem checks

cyameX commented on Sep 13, 2026

Windows Local Work handoff fails at Project context filesystem sync on 26.908.4834.0

Environment

Summary

Steps to reproduce

Expected behavior

Actual behavior

Reproducibility

Relevant timestamps

Minimal sanitized logs

Additional investigation already performed

Related existing issues

mickboyle commented on Sep 13, 2026

Environment

Background

Where the existing workaround stopped working

Controlled reproduction

Workaround that restored repeated Local Work task creation

Important limitation

Why this may matter for the existing issue

niteknights commented on Sep 14, 2026

angelchengang-ops commented on Sep 15, 2026

zmydsg commented on Sep 15, 2026

Independent reproduction and UI-confirmed recovery on 26.908.9136.0

Request for maintainer-approved contribution scope

Umar210696 commented on Sep 15, 2026

2 remaining items

floodwave-git commented on Sep 20, 2026

sunnyvaliko commented on Sep 23, 2026

New reproduction on Windows desktop 26.917.6896.0 (2026-09-23)

Follow-up: update reverted the workaround (same day)

JaGaAg commented on Sep 24, 2026

r8m2gnzggn-beep commented on Sep 24, 2026

Additional reproduction on Windows desktop 26.917.9434.0 (2026-09-24)

hankha4577 commented on Sep 24, 2026

hawkeyeomi commented on Sep 24, 2026

Komatoz1337 commented on Sep 26, 2026

voynichenyi commented on Sep 28, 2026

Additional reproduction on Windows desktop 26.924.22138 (2026-09-28)

sunnyvaliko commented on Sep 30, 2026

Recurrence on 2026-09-30: existing project with 17 source files

voynichenyi commented on Oct 2, 2026

Still reproducible on Windows package 26.928.4866.0 — fresh read-only evidence (2026-10-02)

Hellwood77 commented on Oct 3, 2026

Independent confirmation: project-mirror lock prevents local Work chat creation on Windows

Evidence

Controlled recovery test

Expected behavior

Diagnostic improvement requested

scoldiSF commented on Oct 7, 2026

hankha4577 commented on Oct 7, 2026

hankha4577 commented on Oct 7, 2026

akimkzlv commented on Oct 16, 2026

Additional Windows reproduction and recurring failure — October 16, 2026

Metadata

Metadata

Assignees

Labels

Type