Skip to content

Unified desktop app: Chat cannot reference Work tasks in the same Project #33942

Open
Open
Unified desktop app: Chat cannot reference Work tasks in the same Project#33942
Labels
appIssues related to the Codex desktop appenhancementNew feature or requestsessionIssues involving session (thread) management, resuming, forking, naming, archiving

Description

@omarpinarecords
omarpinarecords
opened on Jul 18, 2026

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

  1. Open an existing ChatGPT Project in the unified desktop app.
  2. Create or use multiple Work tasks associated with that Project.
  3. From one Work task, choose Continue in Chat, or switch to Chat within the same Project.
  4. Confirm that the new Chat remains assigned to the same Project.
  5. 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

Related OpenAI Community discussions

Requested clarification

Please document:

  1. Whether same-Project Chat and Work tasks are intended to share any context.
  2. Exactly what Continue in Chat transfers.
  3. Whether Chat will gain a supported way to reference Work tasks.
  4. Whether the current separation is temporary migration behavior or the intended architecture.

Activity

  1. github-actions
    added
    enhancementNew feature or request
    appIssues related to the Codex desktop app
    sessionIssues involving session (thread) management, resuming, forking, naming, archiving
    on Jul 18, 2026

  2. github-actions commented on Jul 18, 2026

    @github-actions
    github-actionsBot
    on Jul 18, 2026 – with GitHub Actions
    Contributor

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

    Powered by Codex Action

  3. omarpinarecords commented on Jul 18, 2026

    @omarpinarecords
    omarpinarecords
    on Jul 18, 2026 – with ChatGPT Codex Connector
    Author

    Thanks for flagging #33249. I reviewed it, and this report is not a duplicate.

    #33249 requests real-time supervision of active Codex tasks: monitoring progress, inspecting intermediate output, interrupting execution, and sending corrections.

    This issue concerns project-scoped task visibility before or after execution. Chat remains correctly associated with the same Project, but cannot discover, list, or reference the Project’s existing Work tasks. It does not require live monitoring or execution control.

    The two requests are complementary, but they describe separate missing capabilities.

  4. omarpinarecords commented on Oct 5, 2026

    @omarpinarecords
    omarpinarecords
    on Oct 5, 2026 – with ChatGPT Codex Connector
    Author

    Follow-up: Work entry provenance and the current shared-Recents documentation

    On October 4, 2026, I inspected a desktop UI state while trying to identify an unexpected Work entry:

    • Recents showed an existing working conversation and an entry titled New chat separately.
    • With New chat selected, the main pane showed familiar conversation content together with Work with ChatGPT and work-duration/progress labels.
    • The visible state did not explain when or how that entry was created or whether it represented a continuation, a delegated task, or a separately started Work conversation.

    This is a related visibility/provenance observation. It does not establish that messages were copied between distinct thread IDs, that a duplicate task was created, or that an agent created the entry. The initiating event and native identity mapping have not been verified.

    The current ChatGPT Work and Codex documentation explicitly says that Chat and Work chats appear together in Recents and that cloud Work chats sync across web, mobile, and desktop. That explains a mixed sidebar, but it does not tell an owner the origin or execution status of a particular entry.

    This adds a practical requirement to the task-reference and handoff clarification requested above. Please provide a way to inspect:

    1. The conversation's stable identity, Chat/Work mode, and relationship to an originating conversation, if any.
    2. Its creation time and initiating action or actor, distinguishing a user's new chat, an explicit continuation, and agent delegation.
    3. Its actual active/paused/completed status and where to stop any separately running work.
    4. The source of its model/effort setting, including whether it was inherited or explicitly changed.

    I archived the entry because I was concerned about ongoing usage. I have not established that it continued executing after archive or that any extra usage occurred. Projects and chats describes archiving as organization of finished work; Long-running work separately describes goal pause/resume controls. Please clarify whether archive affects execution on each surface, and make the supported stop action visible when relevant.

    The original request here—what Continue in Chat transfers and how Chat can reference Work in the same project—remains pertinent. This follow-up does not claim that Continue in Chat caused the observed entry.

    Only the generic UI observations are included. Screenshots, conversation text, private task identifiers, and internal diagnostic records are omitted.

Sign up for free to join this conversation on GitHub. Already have an account? Sign in to comment

Metadata

Metadata

Assignees

No one assigned

    Labels

    appIssues related to the Codex desktop appenhancementNew feature or requestsessionIssues involving session (thread) management, resuming, forking, naming, archiving

    Type

    No type

    Projects

    No projects

      Milestone

      No milestone

      Relationships

      None yet

      Development

      No branches or pull requests

      Issue actions