macOS: delegated tasks created with explicit local project show zero tasks in project sidebar while threads remain readable #53054

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

   app-serverIssues involving app server protocol or interfacesIssues involving app server protocol or interfaces

   on Oct 11, 2026
2. github-actions commented on Oct 11, 2026

   

   github-actionsbot

   on Oct 11, 2026 – with GitHub Actions

   Contributor

   More actions

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

   • [macOS Codex Desktop] Local project create_thread returns a task whose read_thread cwd is '/' and list_threads omits it #52570
   • Windows 26.1002: project chats repeatedly disappear with many projects; incomplete thread assignment migration and confusing same-name projects #52276

   Powered by Codex Action
3. rhuang19 commented on Oct 12, 2026

   

   rhuang19

   on Oct 12, 2026 – with ChatGPT Codex Connector

   More actions

   Adding a related Windows reproduction from October 12, 2026, approximately 09:22–09:59 UTC.

   The closest overlap is explicit project selection, verified local execution, and failure to find the task under the intended desktop project. Our creation/recovery sequence differs from the successful creation in the original report.

   Observed sequence:

   1. The Windows desktop was connected and authorized. Supported project discovery returned the existing project's ID and root directory.
   2. Creation explicitly supplied that environmentId, projectId and matching absolute cwd, with gpt-6.1-sol / ultra. It returned MCP -32603: Internal error.
   3. Listing immediately afterward found a new persisted thread. Reading it returned latestTurn: null and items: []. We did not repeat creation.
   4. Attaching the persisted thread and sending to that same ID succeeded. The executing task verified the expected Windows hostname and exact project-root working directory, and read the project's AGENTS.md.
   5. Subsequent reads and follow-up messages worked. Instructions sent during active execution returned admissionOutcome: steered; later responses and revisions showed that those instructions were applied.
   6. I could not find the requested conversation in the desktop project's sidebar. After being asked to expand the project list and search for its intended title, I reported that I still could not find it.
   7. In a logged-in web browser, the exact same task was accessible through its /local/ task URL. Its actual title was still “新聊天” (“New chat”). Renaming the same task succeeded, and the page title and web Recent list were verified afterward. The task's model selector displayed GPT-6.1 Sol Ultra.

   Limits:

   • The original missing title explains why a title-based lookup could fail, but we have not verified that renaming restored desktop project visibility. It does not prove successful project association.
   • Actual host/cwd and task communication are verified; saved native project membership and final sidebar grouping are not. We did not obtain a projectId readback and do not claim it was null or lost.
   • Native app queries failed or timed out; the local UI inspection tool failed with “cannot locate required Windows platform directory: HRESULT 0x80070003”. The desktop app build was not captured.
   • No database edits, reinstallation, project moves or security-setting changes were attempted. The existing task and its work were preserved.

   Our earlier Windows partial-creation report describes a related create-error/recovery sequence, but that earlier test did not use the correct working directory and did not verify sidebar placement. This October 12 case explicitly supplies cwd and verifies execution in the intended root.

   #53326 also usefully distinguishes saved membership from visible grouping. We have not established that its background-read denial or any common root cause applies here.

   Could you clarify how callers can verify desktop project membership after partial creation, and provide a supported way to make the original task discoverable under that project while preserving its ID, history and execution environment?

   Private project names, local paths, task/project/environment IDs, research contents, screenshots and raw logs are omitted. Prepared with AI assistance at my request.