Repository navigation
[Desktop] Assistant-created tasks do not preserve requested Local Project destination and reasoning effort #49586
Description
App version, subscription, and model
The original September 30 observation did not collect the exact app version or model. The affected subscription is ChatGPT Pro personal, not Business or Enterprise (confirmed by the account owner on October 4).
Current environment checked on October 4, 2026: ChatGPT/Codex desktop 26.930.31730, build 12947, macOS 27.0.1, build 26A434. These are current diagnostic values, not retroactive measurements of the original occurrence. The original project-placement and reasoning-effort reproduction has not been rerun on this build.
Scope clarification — October 4, 2026
The visible Cloud icon alone does not establish that filesystem work ran in the cloud. OpenAI's dot computer documentation expressly allows cloud coordination with execution on a connected computer. Please distinguish saved Project association, actual execution location, displayed task type, and effective reasoning effort.
This issue remains focused on the originally requested Project destination and reasoning effort. The separately observed inability of the parent dot to address an existing Local task, and differing native tool availability between callers, overlap with #49729 and #49925 and are being reported there. They do not prove the cause of this issue's placement/effort symptoms.
What issue are you seeing?
I explicitly requested that assistant-created tasks use the Local task type, belong to the project I selected for the current work, and use Extra High reasoning effort.
I repeatedly observed two mismatches:
- New tasks appeared outside the required Local Project and displayed a cloud icon. I could not move them into the intended local project through the app.
- New tasks displayed Light reasoning effort, requiring manual correction to Extra High.
A cropped screenshot was reviewed and confirms the visible cloud icon; it is not attached. The assistant acknowledged that it had not explicitly ensured the requested effort and Project association before creating the tasks. Selecting a connected computer is not sufficient evidence that a task belongs to the requested Local Project.
This report does not establish a particular UI or backend defect. The actual saved Project association and effective execution effort have not been independently verified.
Steps to investigate
Suggested minimal reproduction using non-sensitive placeholder content:
- Select a Local Project as the destination for the current work.
- Explicitly ask the assistant to create a Local task inside that Project, with Extra High effort and the already-selected model.
- Ask for a harmless task, such as summarizing a short public paragraph.
- Open the created task and compare its Project placement, displayed task type/icon, and reasoning setting with the request.
This sanitized reproduction has not been independently run.
Expected behavior
Honor and verify the requested Project destination, Local task type, and reasoning effort while preserving the selected model. If that combination cannot be created or verified, explain the limitation before substituting a Cloud task or another destination. The selected Project should be specific to the current request, not permanently fixed for unrelated future work.
Additional information
No private Project names, filesystem paths, task/conversation identifiers, private content, screenshots, or logs are included. No in-app feedback ID is available; feedback was not submitted because a privacy-safe submission could not be completed.
Activity
github-actions commentedon Sep 30, 2026
Potential duplicates detected. Please review them and close your issue if it is a duplicate.
Powered by Codex Action
MassiveMassimo commentedon Oct 2, 2026
I can confirm the project-folder limitation with assistant-created tasks. My intended setup differs from the original report: I want tasks to run in a saved cloud environment and still be organized in my existing local project folders.
Two assistant-created cloud tasks accepted follow-up messages and returned acknowledgments, but I couldn't move them into those existing folders. The web UI also showed neither my existing local projects nor a move-to-project action.
I added a separate read-succeeds/send-fails observation in #49676. I haven't established whether the messaging and project-folder limitations share a cause.
sdy623 commentedon Oct 4, 2026
Additional Windows report focused on the Cloud task label, reported on 2026-10-04.
dot sent a task to a connected Windows local executor with a local project working directory. The task performed local work and verified that the relevant project files existed on that computer. The user reports that the resulting task still displays Cloud in the app.
This is evidence about the displayed task type/location, distinct from the reasoning-effort mismatch in the original report. The visible label is user-reported; an independent screenshot capture and clean-install reproduction were not collected for this occurrence. The desktop app build is not yet established, and a CLI version is not being substituted for it.
Please investigate this flow:
Expected: the UI should clearly identify the connected local computer as the execution location and show the relevant local project context. If Cloud intentionally describes conversation coordination, it should be distinguished from where commands and filesystem work actually run. The current label leaves the user unable to reliably tell these apart. This report does not assert that local commands secretly executed in a cloud filesystem.
Related project-association report: #49646. Working directory, saved Project association, and displayed execution location should be checked separately rather than treating any one as proof of the others.
There is also a separate file-opening symptom: clicking local-file links directly in the app fails. That occurrence is recorded at #50676 (comment). The extra slash in a generated Windows link is not established as the cause of the Cloud task label, and no shared root cause is claimed.
Original local paths, usernames, project names, task/account IDs, document contents, and raw logs are omitted.
omarpinarecords commentedon Oct 9, 2026
October 9 follow-up: saved Project assignments exist despite association warnings
The owner continues to encounter assistant messages saying that tasks have no Project association. One conversation reported that a task was active in the intended Local folder while native Project association remained unconfirmed, citing
projectId: null.A subsequent read-only Local check found a non-null saved native Local Project assignment for both the originally reported task and a diagnostic task created with explicit Project selection. Neither was explicitly marked projectless in the inspected saved app state. The earlier null readback was not reproduced.
This establishes saved assignments in that app state. Canonical durable-host membership and the current sidebar presentation remain independently unverified.
Please distinguish:
Current diagnostic environment: desktop app 26.1007.21159 (build 20052), macOS 27.0.1, bundled CLI protocol 0.162.0. The inspected protocol supports
Thread.projectIdand explicit Project selection for durable-task creation. Those controls do not establish which inputs were used for an earlier task or guarantee consistent readback afterward.Please investigate why assistants report missing association when saved assignments exist, including whether the discrepancy comes from incomplete readback, host-specific membership resolution, synchronization or assistant interpretation. Related reports #51477 and #48728 also distinguish null API membership from saved assignments; a shared cause is unconfirmed.
Expected: consistent Project membership across supported interfaces and sidebar views, clear reporting of unverified state, and any necessary recovery preserving task IDs and history.
No new reasoning-effort regression is asserted. In-product feedback was not submitted for this follow-up. Private project names, paths, task/project identifiers, conversation contents, screenshots and logs are omitted.