Repository navigation
Dot-created chats lose project organization and cannot be moved into projects afterward #52489
Description
Two related problems are making it difficult to find work and conversation history in the macOS desktop app.
Assistant workflow
The dot creates unnecessary new/replacement chats, sometimes continues unrelated new work inside an existing chat, and leaves chats ungrouped even when it knows which project the work belongs to. Creating a new task directly inside the correct project is supported and has succeeded, so this is not simply a missing creation capability.
Expected behavior:
- Create one separate chat for each new task, in the known or reasonably identifiable project.
- Continue an existing chat only for that same task.
- Investigate an unclear project first and ask the user only if it remains ambiguous.
- Leave genuinely general work ungrouped; avoid redundant replacement chats.
Existing-chat moves
Attempts to move existing ungrouped dot-created tasks into a local sidebar project fail with: "The task's source project could not be safely determined."
The supported task list identifies those tasks as ungrouped. The user also tried drag-and-drop into the project and could not move them. The underlying cause has not been established.
Observed sequence:
- A dot creates project-related tasks without assigning the existing project.
- The tasks become scattered in recent history instead of appearing under that project.
- Attempt to move an existing affected task into the intended project.
- The move operation returns the source-project validation error; user drag-and-drop also fails.
- Creating a new task with an explicit project assignment succeeds, while existing affected chats remain misplaced.
Expected: allow eligible chats, including dot-created cloud/durable tasks, to move into a chosen project while preserving messages, history, IDs and links. If there is an unmet access prerequisite, show an actionable explanation instead of leaving the user unable to organize history.
Please investigate the assistant's project/task selection behavior separately from the product's move failure. No private conversation contents, logs, task/project identifiers, local paths, source code or account details are attached. Exact application build has not been verified for this report.
Activity
github-actions commentedon Oct 9, 2026
Potential duplicates detected. Please review them and close your issue if it is a duplicate.
Powered by Codex Action
houmark commentedon Oct 9, 2026
Additional verified observation: explicit project assignment at creation can also be lost or not reflected in membership.
Several new tasks were created with an explicit existing project ID and the matching working directory. Creation returned success. A subsequent supported task-list read reported null project membership for two of those tasks, while another task created with the same destination retained the intended project. The user also saw the affected tasks outside the project.
This is distinct from the earlier assistant omission. The evidence does not identify whether creation, persistence, listing or sidebar synchronization is responsible. Please verify that an explicit project selection is retained and reflected consistently, and make creation results expose or verify final membership. No private task IDs, project IDs, paths or logs are included.
houmark commentedon Oct 9, 2026
Clarification on evidence and attribution: the creation/membership observation comes from recorded assistant tool calls and a subsequent supported task-list read, not an independently reproduced minimal test. The recorded create request supplied a non-null projectId obtained from the same desktop's project list, plus that desktop's environment selector and the project's working directory. The create result reported success but did not echo final project membership. The later task list reported null membership for the returned task. Another task created with the same project selection retained membership.
Please investigate caller/integration handling as well as creation, persistence, listing and sidebar synchronization. This does not establish a backend/tool defect or rule out a consumer-side problem. Separately confirmed assistant mistakes were inconsistent project assignment for earlier tasks, mixing unrelated work into existing chats, and claiming successful placement without verifying membership.
Aristoddle commentedon Oct 15, 2026
Additional local-chat evidence: source-attribution refusal and membership false success
This follow-up concerns existing top-level local CLI-origin and legacy GUI chats, rather than dot-created cloud/durable chats. The error text matches this issue; that alone does not establish a shared root cause.
Environment
up_to_dateon the configured production channel. No channel change was attempted.Case A — existing local chats cannot be assigned
Observed sequence in an existing installation (not a clean-install minimal reproduction):
move_thread_to_projectrejects them with:The task's source project could not be safely determined.read_threadfollowed by another move does not resolve source attribution.This distinguishes native metadata persistence from adoption by the active application/tool membership model. Inspection suggested a native/legacy membership reconciliation boundary, but the live rollout value was not established or changed. Please investigate that boundary rather than assuming the native update is an adequate repair.
Case B — displayed grouping can produce false move success
An archived local chat was displayed in the destination project group without explicit saved membership. After unarchiving, assigning it to that displayed project reported success but did not persist membership. An ordinary supported remove-and-reassign cycle did persist membership; rearchiving retained it. This suggests displayed group containment is being treated as sufficient where actual membership persistence is required.
Requested resolution
Please provide a corrected first-party source-resolution/persistence implementation, or a documented supported reconciliation procedure that preserves existing chat IDs, history, archive states, working directories, permissions, and active worker ownership. Do not require recreating chats or bypassing access/migration gates.
Suggested regression cases: imported local CLI chats without markers; legacy GUI chats without markers; native/legacy project-ID mapping; compatibility across migration states; displayed grouping without persisted assignment; archived-chat moves; foreign-host/account ambiguity; source-access confirmation.
This is a text-only, sanitized report. No chat/project IDs, personal paths, conversation contents, logs, screenshots, session attachments, credentials, or proprietary source excerpts are included. No signed-app patch, private-state rewrite, rollout-flag change, or worker interruption was used as a repair.
MassiveMassimo commentedon Oct 20, 2026
Additional observations from tests on October 20, 2026:
The currently exposed task-creation interface describes project assignment as supported for desktop tasks and unavailable for cloud containers. A durable host label alone also does not establish where a task executes.
Please provide a supported way to keep tasks executing in a saved Codex cloud environment while organizing their conversations under the intended sidebar project, without moving execution to the local computer or requiring a personal VM. These observations do not establish the root cause or show that every creation route is affected. No private task/project IDs, paths, logs, or conversation contents are included.