[Windows][Desktop] ChatGPT project mirror sync fails after Work helpers occupy mirror directory

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

26.908.9136.0

What subscription do you have?

Pro

What platform is your computer?

Microsoft Windows NT 10.0.26200.0 x64

What issue are you seeing?

A ChatGPT project in Work can successfully create and run one local conversation, but creating another conversation in the same project subsequently fails with:

Could not use this project for a local chat

What steps can reproduce the bug?

1. Open an existing ChatGPT project in Work.
2. Immediately submit test.
3. A local Work conversation is successfully created and completes normally.
4. Without restarting the Codex App, create another new Work chat in the same project.
5. The second attempt fails with Could not use this project for a local chat.

Investigation

I performed a read-only investigation of the Desktop logs, app-server logs, project mirrors, running helper processes, Windows directory handles, and the installed application code.

The evidence strongly indicates a Windows directory-sharing conflict:

• Project synchronization successfully replaces the local project mirror.
• Work/prewarming then starts helper processes that use that mirror directory as their working directory.
• A subsequent project synchronization attempts to replace the same mirror.
• The helpers still occupy the directory.
• A handle-only rename-access probe on the affected mirror returns Windows error 32 (sharing violation).
• Desktop then logs project synchronization failure at stage=filesystem.
• The user-visible error is Could not use this project for a local chat.

A Windows reboot does not permanently resolve the issue because Desktop can recreate the locking condition during the fresh session.

The affected project itself does not appear corrupt: its mirror, metadata, permissions and mappings are valid, and it successfully created and completed a Work conversation during the controlled test.

The exact failing filesystem syscall is inferred rather than directly logged because the original native filesystem exception is not preserved in the Desktop log.

I have a sanitized diagnostic package containing the full technical report, reproduction steps, evidence index, and minimal relevant log extracts.

What is the expected behavior?

Should be able to start a new chat

Additional information

codex-desktop-bug-report.zip

Start by tracing Windows project synchronization and the Work/prewarming helper lifecycle described in the report, then reproduce the second-chat failure on Windows while checking the Desktop and app-server logs. Done means a project can create multiple local Work chats in one session without the mirror replacement encountering a sharing violation.