Unified desktop app: Chat cannot reference Work tasks in the same Project
Nobody has claimed this yet.
Assessment
- Difficulty
- 5/5
- Estimated time
- Over a week
- Newbie friendliness
- 25/100
- Issue type
- Feature
- Clarity
- Needs clarification
- Activity status
- Quiet
- Domain
- desktop
Research direction
No repository files, tests, or entry points are named; first determine whether unified desktop Project, Chat, and Work integration exists in this repository. Done would require an agreed, permission-aware cross-surface reference design or documented clarification of the current behavior and Continue in Chat transfer scope.
Written by the indexing model from the issue text.
Description
Summary
In the unified ChatGPT desktop app, Chat and Work can appear inside the same ChatGPT Project while still using separate task and conversation context.
A new Chat created through Continue in Chat remains correctly associated with the same Project. However, that Chat cannot list, reference, or access the other Work tasks associated with the Project.
This is not a missing-task or lost-project-selection problem. The Work tasks remain available in Work, and the Chat remains in the correct Project. The problem is that the shared Project UI does not provide shared task visibility or a reliable cross-surface reference mechanism.
Environment
- ChatGPT desktop app: 26.715.31251
- macOS 26.5.2
- Apple silicon
Steps to reproduce
- Open an existing ChatGPT Project in the unified desktop app.
- Create or use multiple Work tasks associated with that Project.
- From one Work task, choose Continue in Chat, or switch to Chat within the same Project.
- Confirm that the new Chat remains assigned to the same Project.
- Try to view or reference the other Work tasks from Chat.
Actual behavior
- The Chat stays inside the correct Project.
- Existing Work tasks remain visible in Work.
- Chat cannot discover, list, mention, or reference those Work tasks.
- The user must manually copy or summarize context between the two surfaces.
- A matching Project name implies more continuity than the product actually provides.
Expected behavior
At minimum, Chat should provide a project-scoped way to reference a Work task, such as a task picker or reliable @ reference.
Ideally, the Project should own a shared, permission-aware context layer containing:
- task titles and status;
- explicit handoff summaries;
- decisions and active constraints;
- user-selected artifacts or attachments;
- clear provenance showing which context came from Chat and which came from Work.
This should not silently grant Chat access to local files or execution capabilities. Any transfer of local artifacts or sensitive context should remain explicit and permission-controlled.
If full cross-surface access is not intended, the UI should clearly state that Chat and Work share only Project organization—not task history or working context—and explain exactly what Continue in Chat transfers.
Why this is distinct from related reports
- #33723 reports losing the cloud Project association when switching to Chat. Here, the Project association is preserved.
- #32130 requests broad unification and full Project access. This report focuses specifically on same-Project task visibility between Chat and Work.
- #33716 describes the mixed organization models.
- #31862 covers broader unified-desktop regressions.
Related OpenAI Community discussions
- Chat references of Codex inside ChatGPT
- [macOS] Web Project hierarchy missing in the desktop app, while hidden Work chats remain partially discoverable via @
- The unified ChatGPT app needs shared project state between Work and Codex
Requested clarification
Please document:
- Whether same-Project Chat and Work tasks are intended to share any context.
- Exactly what Continue in Chat transfers.
- Whether Chat will gain a supported way to reference Work tasks.
- Whether the current separation is temporary migration behavior or the intended architecture.
- Dominant language
- Rust
- Stars
- 125k
- Forks
- 19.5k
- Avg merge
- 1m
- Merged PRs (30d)
- 1k
Contributor guide
First steps
- Read the whole issue, then the project's contributing guide.
- Comment on the issue to say you are picking it up — it saves two people doing the same work.
- Fork the repository and make your change on a branch.
- Open a pull request that references the issue number.
More from openai/codex
-
enhancement remote
Difficulty 2/5 1-3 hours Newbie friendliness 68/100
-
bug CLI windows-os
Difficulty 2/5 1-3 hours Newbie friendliness 76/100
-
macOS sandbox blocks hw.optional.arm64 sysctl, causing Flutter to misdetect Apple Silicon as x64 Openbug CLI sandbox
Difficulty 2/5 1-3 hours Newbie friendliness 78/100
-
bug CLI TUI
Difficulty 2/5 1-3 hours Newbie friendliness 90/100
-
CLI config enhancement skills
Difficulty 2/5 1-3 hours Newbie friendliness 84/100
Similar issues
-
Difficulty 2/5 1-3 hours Newbie friendliness 86/100
kwakseongjae/auto-hwp#319 ·
-
area:cli bug filter-quality good first issue priority:medium
Difficulty 2/5 1-3 hours Newbie friendliness 84/100
-
Difficulty 1/5 Under an hour Newbie friendliness 72/100
bevyengine/bevy#25861 ·
-
comp-datalake
Difficulty 2/5 1-3 hours Newbie friendliness 88/100
ClickHouse/ClickHouse#121222 ·
-
A-linter
Difficulty 2/5 1-3 hours Newbie friendliness 72/100
oxc-project/oxc#26863 ·