Activity

1. github-actions

   added

   bugSomething isn't workingSomething isn't working

   appIssues related to the Codex desktop appIssues related to the Codex desktop app

   windows-osIssues related to Codex on Windows systemsIssues related to Codex on Windows systems

   on Sep 28, 2026
2. github-actions commented on Sep 28, 2026

   

   github-actionsBot

   on Sep 28, 2026 – with GitHub Actions

   Contributor

   More actions

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

   • [Windows][Desktop] Local Work fix is invalidated by app/plugin updates because cua_repl cwd is stored in versioned plugin cache #48534

   Powered by Codex Action
3. artemrizhov commented on Oct 1, 2026

   

   artemrizhov

   on Oct 1, 2026 – with ChatGPT Codex Connector

   More actions

   I can reproduce this, with one useful distinction: it happens for a ChatGPT Project that was created on my phone (iOS) and exists as a cloud project. In ChatGPT Desktop on Windows, trying to start/add a Work session in that project gives “Could not use this project for a local chat”. The chat either is not created, or is created outside the project.

   By contrast, a project created locally in ChatGPT Desktop and linked to a local folder works normally for Work sessions.

   So in my case the issue appears specific to the cloud/mobile-created project rather than Work sessions in general.
4. artemrizhov commented on Oct 2, 2026

   

   artemrizhov

   on Oct 2, 2026

   Last edited by artemrizhov

   More actions

   Windows: Work session creation fails with a directory sharing violation during ChatGPT project synchronization

   Description

   Creating a local Work session from a ChatGPT project fails with:

   Could not use this project for a local chat

   The application may first ask the user to trust its local project directory under:

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

   Confirming trust does not resolve the error.

   The problem initially occurred with a project created on a phone. It also reproduced with a newly created project and persisted after signing out of Windows and signing back in.

   Environment

   • Windows

   • Installed application package: OpenAI.Codex_26.928.4866.0_x64

   • Application log build number: 12694

   • Configured local MCP servers: Node REPL, two Chrome DevTools servers, and OpenCode through WSL

   Steps to reproduce

   1. Open a ChatGPT project in the desktop application.

   2. Attempt to create a local Work session.

   3. If prompted, confirm “Trust folder.”

   4. Observe the session creation error.

   The failure is not fully deterministic: an earlier attempt failed, while a subsequent attempt for the same project succeeded.

   Expected behavior

   The application prepares the local project context and creates the Work session successfully.

   Observed filesystem activity

   A filtered Process Monitor capture recorded the following sequence for a fresh project. Times are local, Europe/Prague.

   Time | Activity | Result -- | -- | -- 02:13:03.1181140 | Rename the initial staging directory to the project directory | SUCCESS 02:13:10–02:13:13 | Node, Node REPL, and WSL processes open the project directory | SUCCESS, with ShareMode: Read, Write 02:13:18.1429297 | ChatGPT.exe opens the existing project directory with Read Attributes, Delete, Synchronize access | SHARING VIOLATION 02:13:18.148 | Application logs project context synchronization failure | stage=filesystem

   Several successful directory opens by these helper processes have no subsequent CloseFile event in the saved capture. Their sharing modes omit Delete, making them incompatible with the access requested during directory replacement.

   The second staging directory is subsequently removed during cleanup.

   Application log:

   2026-10-02T00:13:18.148Z error [electron-message-handler]
   ChatGPT project context sync failed
   fileOrdinal=null
   projectSaveCount=0
   sourceCount=0
   stage=filesystem
   status=null
   syncFileCount=0

   Relevant implementation behavior

   Read-only inspection of the installed application code shows that project synchronization:

   1. Creates a staging directory.

   2. Writes the project context.

   3. Renames the existing project directory to a temporary “previous” directory.

   4. Renames staging to the project directory.

   The failed directory open is consistent with step 3.

   Folder trust is handled separately through the application's trust_level configuration. It does not modify Windows filesystem permissions.

   Likely cause

   The trace indicates a conflict between repeated project synchronization and helper processes that have already opened the project directory, possibly as their working directory.

   This suggests an ordering or lifecycle issue: the application attempts to replace the project directory after starting processes that prevent its renaming.

   The sharing violation is confirmed. The exact blocking handle, the reason for the second synchronization, and its relationship to the trust confirmation have not been conclusively established.

   Additional findings

   • The original project directory has full-control permissions for the current user.

   • No reparse points were found in the checked parent directories.

   • An earlier capture showed ACCESS DENIED during staging-to-project rename, followed by a successful retry approximately eight seconds later. This is a separate observed failure and should not be assumed to have the same cause.

   • The available evidence does not establish antivirus involvement.

   • Temporarily disabling MCP servers has been proposed as a diagnostic experiment but has not yet been tested.

   Suggested investigation

   Check why project synchronization runs again after helper processes start, and ensure directory replacement cannot conflict with processes using that directory.

   Including the underlying filesystem error code and operation in application logs would also make this failure easier to diagnose.

   Available diagnostic files

   • full-trace.pml: filtered to local project paths

   • new-project-trace.pml: selected directory-open and failure events

   • Application log containing the corresponding synchronization failure

   trace.zip
5. greatpal88 commented on Oct 5, 2026

   

   greatpal88

   on Oct 5, 2026

   More actions

   Title: ChatGPT Desktop — “Could not use this project for local chat” when selecting Continue in Work

   Date observed: October 5, 2026

   Platform: Windows 11 Pro
   Application: ChatGPT Desktop for Windows
   ChatGPT plan/workspace: [PLAN / WORKSPACE NAME]
   ChatGPT Desktop version: [VERSION, IF KNOWN]

   Summary

   I am unable to open an existing ChatGPT Project in local Work mode.

   When I am inside my existing Project and select Continue in Work, ChatGPT attempts to create or transfer the conversation to a local Work chat but fails with the following error:

   “Could not use this project for local chat.”

   The problem is reproducible and prevents me from using Work with an established Project that contains important project context and history.

   Project affected

   Project name: JARVIS — JDRC AI Command Center Final

   This is an existing, active ChatGPT Project. Normal ChatGPT conversations within the Project continue to work.

   The Project is being used for development and documentation of a local software project. I am attempting to use Work specifically because it needs access to local project files.

   Steps to reproduce

   1. Open ChatGPT Desktop on Windows 11 Pro.
   2. Open the existing Project:
      JARVIS — JDRC AI Command Center Final
   3. Open a conversation within that Project.
   4. Request a task requiring access to local files.
   5. Select Continue in Work when prompted.
   6. ChatGPT attempts to start a local Work chat associated with the existing Project.
   7. The operation fails.

   Actual result

   ChatGPT displays:

   “Could not use this project for local chat.”

   The Work session is not created or connected to the Project.

   Expected result

   Selecting Continue in Work from an existing Project should create or open a Work session associated with that same Project, preserving the Project context while allowing Work to access authorized local files.

   Local project location involved

   The ChatGPT Project has a local project directory similar to:

   C:\Users\mrsim.codex.chatgpt-projects\g-p-6aa9938d54f48191a5546050613bc800\

   One file Work needs to read is:

   C:\Users\mrsim.codex.chatgpt-projects\g-p-6aa9938d54f48191a5546050613bc800\outputs\handoff\MILESTONE-2-HANDOFF-20261005.md

   The requested operation was read-only. No software installation, server launch, or file modification was requested.

   Troubleshooting already attempted

   • Retried Continue in Work from the existing Project.
   • Confirmed that the regular ChatGPT conversation inside the Project is still functioning.
   • Repeated the handoff request and received the same local-chat error.
   • No JARVIS files or configuration were modified as part of troubleshooting.
   • No project folders were deleted, renamed, or manually repaired.

   Impact

   This blocks a core workflow in which an established ChatGPT Project contains the authoritative project history and Work needs to inspect local files associated with that Project.

   Creating an unrelated Work chat outside the Project is not equivalent because it loses the normal Project association and creates a risk of fragmenting the project record.

   Requested investigation

   Please determine why an existing ChatGPT Project cannot be used for a local Work chat on Windows.

   In particular, please check whether this is related to:

   • synchronization of the local ChatGPT Project directory;
   • file or directory locking by a ChatGPT/Desktop helper process;
   • permissions on the .codex.chatgpt-projects directory;
   • Project-to-Work handoff metadata;
   • local Work initialization for existing Projects; or
   • a Windows-specific ChatGPT Desktop regression.

   Please also advise whether there is an official, non-destructive workaround that preserves the existing Project and its history.

   Important constraint

   I do not want to delete, recreate, rename, or manually alter the existing Project or its local files unless OpenAI confirms that doing so is safe and supported.

   I can provide screenshots, application version information, timestamps, or diagnostic logs if needed.
6. Dwap-D commented on Oct 7, 2026

   

   Dwap-D

   on Oct 7, 2026

   More actions

   I can reproduce a very similar issue on ChatGPT Desktop for Windows after the recent Work/Codex incidents.

   Environment:

   • ChatGPT Desktop for Windows
   • App version: 26.930.61225
   • Published: October 5, 2026
   • Reproduced in new Work chats, including outside any ChatGPT Project

   Observed behavior:

   • A standalone Work chat can be created successfully.
   • When I associate an existing ChatGPT Project with the new Work chat, the app fails with:
     Could not use this project for a local chat

   Important detail:

   • I can reproduce the same error when Cloud is selected, not only Local.
   • The UI correctly offers to add the ChatGPT Project context, instructions, and sources to the Work chat.
   • The failure occurs immediately after confirming the project association.

   This suggests the problem is in the Project → Work context synchronization step, before the actual Cloud/Local execution mode is established.

   Comparison:

   • Standalone Work Local works and can read attached files and local folders.
   • The ChatGPT Project remains usable in regular ChatGPT / web workflows.
   • The failure is specifically triggered when trying to use that Project context inside Work on Windows Desktop.

   Troubleshooting already tried:

   • Restarted ChatGPT Desktop
   • Rebooted Windows
   • Updated ChatGPT Desktop
   • Retried with a new Work chat
   • Retried with both Cloud and Local selected

   I also submitted an in-app bug report describing the same behavior.