Desktop app makes normal Chat inside cloud Projects impossible and conflates cloud, local, and SSH workspaces

Open 💬 2 comments Opened Jul 17, 2026 by Mooonika4ever

Summary

The new ChatGPT desktop app has a major Project workflow gap:

  1. Selecting an existing cloud ChatGPT Project and then switching to Chat silently drops the user into a global, non-project chat.
  2. The selected cloud Project is effectively retained only for Work/Codex.
  3. Cloud ChatGPT Projects, local folders, and SSH workspaces are presented together with insufficient visual and semantic distinction.

This is broader than simply hiding existing ChatGPT Projects. Even when a cloud Project is visible or selectable, there is no first-class way to start a normal Chat inside it.

Related: #32593

Environment

  • Platform: macOS desktop app
  • Subscription: ChatGPT Pro Lite
  • App version: current production build; exact build can be provided if required

Steps to reproduce

  1. Open the new ChatGPT desktop app.
  2. Select an existing cloud ChatGPT Project that was created on chatgpt.com.
  3. Choose or switch to Chat rather than Work/Codex.
  4. Send a message.

Actual behavior

The app exits the selected Project context and starts a global standalone chat.

As a result, the new chat does not clearly inherit the Project's:

  • files
  • project instructions
  • project memory/context
  • existing project organization

The only direct path that preserves the selected Project appears to be Work/Codex.

Expected behavior

The desktop app should support a first-class Chat in this Project flow. Switching from Work/Codex to Chat should preserve the selected cloud Project and its context.

Work is not a substitute for Chat. Many Project interactions are lightweight discussions, questions, comparisons, or iterative learning conversations that need Project context but do not need an agentic workflow.

Moving a standalone chat into a Project later is also not equivalent, because the initial response was generated without the Project's files, instructions, and context.

Second issue: ambiguous workspace types

The same picker mixes together:

  • cloud ChatGPT Projects
  • local folders
  • SSH/remote workspaces

These objects have materially different storage, synchronization, permissions, persistence, context, and execution semantics, yet they are difficult to distinguish at a glance.

Users cannot reliably tell:

  • whether an item is cloud, local, or remote
  • where the conversation will live
  • whether it will sync across devices
  • which files, instructions, and memory it will inherit
  • which machine the work will run on

Suggested changes

  • Add a first-class Chat in this Project action.
  • Preserve the selected cloud Project when switching to Chat.
  • Separate cloud Projects, local folders, and SSH workspaces into distinct sections, or provide strong Cloud / Local / SSH badges.
  • Show host, path, sync status, and execution location where relevant.
  • Make the current context boundary explicit before the user sends a message.

For users who use ChatGPT Projects as long-term knowledge spaces rather than merely agent workspaces, the current desktop design breaks a core workflow.

View original on GitHub ↗

This issue has 2 comments on GitHub. Read the full discussion on GitHub ↗