[macOS Remote Control] Existing task missing from project; dragging does not repair placement, client restart restores projectId

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

ChatGPT/Codex desktop for macOS 26.915.31945, build 9922, read from the installed app bundle's Info.plist rather than the About dialog. Remote host app version was not collected.

What subscription do you have?

Not collected for this report.

What platform is your computer?

Client: macOS 27.0, build 26A428.
Remote host: another Mac, connected through Remote Control.

What issue are you seeing?

An existing remote task appeared under its intended saved project on the host Mac, but outside that project on the client Mac. The client still appeared to recognize that the task belonged to that project. Dragging the task into the project did not restore its placement.

The task history remained readable. Another task in the same project displayed correctly.

Read-only diagnostics before restarting the client showed:

• list_projects returned the intended remote project and connected host.
• list_threads returned the affected task with projectId: null; the other task returned the intended project ID. Both reported the same remote working directory.
• The client's saved sidebar-project-thread-orders already contained both task IDs under the intended project.
• Neither task had an entry in the client's legacy thread-project-assignments map or thread-workspace-root-hints map, and neither was in projectless-thread-ids. These are observations, not a claim that the legacy maps are authoritative.
• Direct reading of the affected task succeeded. Reading it and repeating task enumeration did not repair the null project ID.
• No unavailable hosts or sources were reported.

There was also a path discrepancy: the saved remote project's path and a cached summary for the correctly grouped task used one folder name, while live task enumeration used another folder name. The relationship between those paths, and whether it contributed to the failure, were not established.

What steps can reproduce the bug?

The original trigger is unknown; these are the observed failure and recovery steps, not a deterministic clean-install reproduction:

1. Connect a Mac desktop client to another Mac through Remote Control.
2. Compare an existing task's placement under a saved project on the host and client.
3. In the affected state, the host shows the expected project placement while the client does not.
4. Drag the task into its intended project on the client. The task remains outside the project.
5. Check task enumeration: the affected task reports projectId: null even though its ID is already in that project's saved sidebar order.
6. Close and reopen the desktop app on the client.
7. The user confirms the sidebar is fixed. A subsequent list_threads check returns the intended project ID for the same task, with the same working directory and task update timestamp.

No task recreation, Git operation, or manual state/database edit was performed during troubleshooting.

What is the expected behavior?

The client sidebar and task-list project association should converge with the remote host without requiring an application restart. Dragging an existing task into its intended project should reconcile inconsistent placement or display an actionable error.

Additional information

The restart result suggests stale client-side state or a project-association projection problem; the root cause is unconfirmed. Please investigate consistency between remote task enumeration, sidebar membership/order, path-based project matching, and the drag handler's already-in-project behavior.

Related reports:

• #39764: a newly created local worktree task reports a null project ID until restart. This case involves an existing remote task and unsuccessful drag-based repair.
• #37021: task-list project identity disagrees with a direct local assignment on Windows. Here, the client-side legacy assignment entry was absent.
• #41214: multi-host sidebar consistency problems across restarts. In this case, restarting the client repaired the mismatch.

Observed 20 September 2026. Project names, task titles/IDs, host identifiers, absolute user paths, conversation contents, and raw logs are omitted.

Start by tracing the list_threads and list_projects entry points, the sidebar-project-thread-orders state, and the drag handler's behavior for an existing remote task. Compare project IDs, sidebar membership, path matching, and restart behavior using the observations in the report. Done means the client converges without restart, or dragging reports an actionable failure.