Cant use Work in Projects could no use project for local chat

What version of the Codex App are you using (From “About Codex” dialog)?

Powered by Codex & OWL Version 26.908.70816

What subscription do you have?

Pro

What platform is your computer?

Microsoft Windows NT 10.0.26200.0 x64

What issue are you seeing?

Work project sync failure — diagnostic report

Date: 15 September 2026
Application package: OpenAI.Codex 26.908.9136.0 (Windows)

Reproduction

Opening Work in multiple ChatGPT projects displays “Could not use this project for a local chat”. An empty project also reproduced it.

Verified findings

• App logs at 09:05:38.821 UTC record project context sync failure, stage=filesystem, sourceCount=0, syncFileCount=0.
• The empty project mirror was created at 09:05:34 UTC, before the later sync failure.
• Installed app sync implementation creates a staging directory, renames the existing project root to a previous directory, and replaces it with staging.
• A non-mutating Windows handle probe requesting DELETE access with full sharing returned error 32 (sharing violation) for test, Work Project, and Obsidian Brain. The inactive backup directory passed.
• Read-only process working-directory inspection found app-spawned node.exe and node_repl.exe helpers using those project roots as their working directories.
• A disposable create/write/rename probe in the parent directory passed. Current user has full control of that directory.

Recovery performed

Stopped identified helpers for the empty test project and idle Work Project. Repeated handle probes then passed for both project roots. No project files were modified or deleted.
Obsidian Brain remains locked; its task “Build read-only Brain V1” is actively running and was left uninterrupted.

Remaining validation and limitation

User needs to retry opening Work to validate the full UI flow. Releasing helper locks is a temporary recovery, not an application code fix. The same root-directory replacement can fail again while helpers hold the project directory open.

Suggested engineering investigation

Avoid replacing/renaming a project root while child processes use it as their current directory. Consider updating managed reference files within a stable root, or coordinating helper shutdown/restart around refresh. Preserve user-created project files. Include underlying filesystem error code and failed operation in diagnostics.

Follow-up: recurrence confirmed

The user successfully opened and received a reply in the test task after the helper shutdown, then reported the same error again in both test and Work Project. Fresh log entries at 09:32:36.202, 09:33:30.587 and 09:33:39.228 UTC show the filesystem-stage failure recurring. The last two had zero source files.

The official Microsoft Store package query identified ChatGPT package 9PLM9XGG6VKS, version 26.908.9136.0. An update attempt returned: “No available upgrade found. No newer package versions are available from the configured sources.”

The temporary recovery is not durable. No permanent repair has been applied. Escalation to application support/engineering is required for a supported durable fix.

Final retry result

A second targeted recovery stopped recreated helpers for test and Work Project only. Both directories passed the immediate Windows rename-access probe afterward. The user retried and reported that Work still did not open.

Conclusion: directory locking was verified, but clearing the observed locks did not reliably restore the user flow. The underlying cause of the latest failed attempt is not established; do not treat locking as the sole proven cause. Further application-level diagnostics are needed. No permanent fix has been applied.

What steps can reproduce the bug?

Feedback ID: 01a0a44a-a5b2-7c80-b313-29a98eef4301

What is the expected behavior?

No response

Additional information

No response

Start by reproducing the Work and test project flow while collecting fresh logs, then trace the filesystem-stage sync operation that stages, renames, and replaces the project root. Check the app-spawned node.exe and node_repl.exe working directories and capture the underlying Windows error and failed operation. Done means the UI flow works durably, including while helpers are active, with project files preserved and useful diagnostics for failures.