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

1. Typing in the new local Work composer prewarms a task and starts background MCP/helper processes.
2. Without an explicit helper working directory, these processes start inside the ChatGPT project's local mirror.
3. Sending the message synchronizes the project's context again before starting the actual task.
4. Synchronization stages a replacement directory, then attempts to rename the existing mirror before swapping the replacement into place.
5. 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.

1. 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.
2. Set a stable cwd for cua_repl in the installed unified-computer-use plugin's .mcp.json.
3. 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'

4. 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'

5. 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.

Start by reproducing the failure through the normal local Work composer with helpers running, then inspect the synchronization function in .vite/build/main-CMBCj4XL.js and the prewarming and submission flow in webview/assets/app-primary-4c40d73a1074.js. Trace the desktop config/batchWrite startup rewrite and verify that linked local tasks still start across multiple projects after restarts and updates without locking their mirrors.