Chats can't be started in Projects (only as Work), or moved to Projects (only Work can)

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

• #33723

Powered by Codex Action

Confirmed still reproducible on ChatGPT Desktop for macOS version 26.730.61639 (build 6234), observed 2026-08-07.

Reproduction: open an existing in-app ChatGPT Project (in this case, “Elden Ring”) and attempt to create a new conversation from inside the project.

Actual: a new conversation cannot be created while inside the project.

Expected: the project should allow a new conversation to be created and retain that project’s context.

The existing conversation remains usable. Recent desktop logs around the attempt contain workspace/project scanning activity but no explicit new-chat exception or thread/start timeout, so this appears closer to the project-specific desktop behavior reported here than the general timeout in #30348.

Additional implementation analysis from the shipped macOS bundle (26.730.61639):

The sidebar ChatGPT-project component computes the project New chat action visibility from a predicate equivalent to:

showAction = isWorkLocalTaskAvailable || isPinned || isChatFilteredOrMode

The control is otherwise rendered as null. This couples whether a cloud project can start a chat to unrelated sidebar/UI state (global Work-vs-Chat mode, pin state, and conversation filter). That explains why a user can be inside a valid cloud project and still have no usable new-conversation path.

When visible, the ordinary-chat branch clears the current selection and navigates home with the project ID only in transient route state (equivalent to navigate('/', { state: { chatGptProjectId: projectId } })). The mode-switch implementation separately snapshots/restores locations and may start a fresh conversation after clearing selection, so project identity can also be dropped during Work → Chat transitions.

Suggested fix:

1. For a cloud ChatGPT Project with permission to create conversations, always expose the project-scoped New chat action; do not gate it on pin/filter/current global mode.
2. Make the action explicit: switch to Chat and start a conversation with the project ID as an atomic operation, rather than relying on transient home-route state surviving a mode transition.
3. Keep the Work/local-task action separate and capability-gated.

Regression coverage:

• Unpinned cloud project + Work mode + All filter → New chat remains available.
• Pinned and unpinned projects behave identically.
• Work → Chat from a selected cloud project preserves the project ID.
• The created conversation is listed under that project and inherits its context.
• Direct project + action and Cmd/Ctrl+N project flow produce the same assignment.

The distributed app contains compiled/minified client code and no source maps, so I have not attached a patch against generated artifacts; this needs to be changed in the desktop client source.

I can reproduce a closely related problem in the Windows desktop app with a Project linked to a local folder.

From inside the Project, I click the Project’s New Chat button and choose an ordinary Chat. The Chat is created, but it appears in Recents instead of remaining visibly inside the Project. I also cannot move it back into the Project: drag-and-drop shows the normal drag shadow, but dropping onto the Project does nothing.

I also tested the suggested workaround of pinning the Chat first and then dragging it into the Project. That does not help in my case.

This is a significant organizational problem for long-running Projects because project-related Chats become mixed into a large Recents list with unrelated one-off conversations.

I already submitted this through the in-app feedback form with session logs.

Feedback ID: no-active-thread-01a00b0a-9271-7383-8f18-64be876d4ee4

Expected behavior: ordinary Chat and Work conversations should be able to coexist organizationally inside the same Project, even if their execution/storage models remain technically separate.

Additional Windows/local-folder Project finding:

I tested Continue in work mode from an ordinary Chat that had been created for a local-folder Project but was stuck in Recents.

What happens is not a move/convert of the existing Chat. Instead, the app creates a separate Work thread inside the local Project that inherits the conversation context, while the original ordinary Chat remains outside the Project in Recents.

So the desktop app can carry the Chat context into a Project-scoped Work thread, but it still cannot keep the originating ordinary Chat organized under that same local Project.

For users working across multiple local Projects, this is not just cosmetic: over time the related ordinary Chats become indistinguishable from unrelated Recents, while only their Work continuations remain grouped by Project.

Expected UX: the local Project should be able to show both the ordinary Chat and its related Work continuation under the same Project, even if only Work has local-folder access.