Clarify new-thread context and support moving threads between General and Projects

Open 💬 3 comments Opened May 23, 2026 by culstrup
💡 Likely answer: A maintainer (github-actions[bot], contributor) responded on this thread — see the highlighted reply below.

What variant of Codex are you using?

App / Codex Desktop

What feature would you like to see?

Codex Desktop needs a clearer and more reversible flow for choosing where a new thread starts: General, home/projectless, or a specific Project/repo.

My actual workflow often starts before I know the right project. Sometimes I want to start a quick general thread, with my home directory or another neutral default being fine. Sometimes I know the exact repo. Sometimes a general planning or debugging thread later becomes project-specific. The current UX makes that context decision feel too early, too easy to get wrong, and too hard to change later.

Concrete friction:

  • If I previously worked in a project, it is easy to accidentally start the next thread in that same project when I intended a general/home thread.
  • General or projectless threads feel second-class even though they are often the right starting point for research, planning, triage, or deciding which repo owns the work.
  • Once a thread starts in the wrong place, there is no obvious supported way to move it into a project, move it out of a project, or re-home it to another repo.
  • The sidebar and global recents view make it hard to hop across projects because the active project/context is not always visible enough before opening or starting a thread.
  • The default projectless workspace behavior is confusing. A user should be able to choose where projectless/generated workspaces live, or start from a neutral home/general workspace without feeling like they created a fake project.

The mental model I want:

  1. Start a thread quickly, with a clear visible context: General, Home, or Project: <name/path>.
  2. Show that context prominently in the composer before I send the first prompt.
  3. Let me change that context before the first turn.
  4. Let me move or attach the thread later: General -> Project, Project -> General, Project A -> Project B.
  5. Preserve the project memory/context benefits when I intentionally open a thread inside a repo, while avoiding the need to know the final repo before I start thinking.

Claude Code's terminal agent flow handles part of this better because choosing a repo feels like an explicit launch context. Codex Desktop has more surface area, but the project/thread navigation does not yet make that context decision feel visible, safe, or reversible.

Possible UX options

  • A first-class General or Home start target in the new-thread composer.
  • A persistent context chip in the composer, for example General, ~/, or powerline.
  • Move to Project, Remove from Project, and Change Workspace actions on a thread.
  • Project metadata in global recents, not only inside grouped project views.
  • A setting for the default projectless workspace root.

Related issues

This seems related to several existing requests and bugs, but the underlying workflow issue is broader than any one of them:

  • #12397: Add General Chat mode and convert chat to project
  • #22345: Allow Chats to be moved into, out of, and between Projects
  • #22875: Allow configuring default directory for projectless thread workspaces
  • #19909: Make the Chats project directory configurable
  • #24083: Show project and execution-context metadata in the global recent chat list
  • #18640 / #21581 / #19873: Sidebar/project/thread visibility and grouping issues

View original on GitHub ↗

3 Comments

github-actions[bot] contributor · 3 months ago

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

  • #23313
  • #22875
  • #24083

Powered by Codex Action

claell · 3 months ago

Adding another concrete workflow that fits this request:

I often start in Chats because the idea is not clearly a repo or project yet. The thread may still accumulate useful files in its Codex-owned working folder. Later, the work becomes substantial enough that I want to promote it into a real project stored at a chosen location.

The important part is not only moving the sidebar entry. A supported "Promote to Project" flow should also handle the workspace on disk:

  • choose a new project name and destination folder, or attach to an existing project
  • move/export the chat-owned working folder into that destination
  • update the thread/project metadata so future agent runs, terminal sessions, file tree views, and search use the new project root
  • preserve the full chat history and avoid creating a confusing fork or duplicate thread
  • keep a clear fallback if file moves fail, for example by copying first and only switching metadata after validation

Related prior request: #10950 also asked for a General Chat mode with a way to turn the chat into a project later. It is closed now, but the workflow overlap seems worth linking here so the history is easier to follow.

A later extension could support merging several related chats into one project, possibly with LLM-assisted conflict detection and file/context reconciliation. That seems harder, but the single-chat promotion path would already cover the common case where exploratory work turns into a real project.

grandmaster451 · 25 days ago

A current Windows data point that makes this especially confusing:

  • Desktop package: 26.727.6591.0 (bundled Electron app 26.727.51351)
  • Settings > General > Popout Window > Default to standalone chat is enabled and persists as hotkey-window-projectless-default-enabled = true.
  • Pressing Ctrl+N while a local project is selected still opens the new-chat composer in that project.

Inspection of the shipped bundle shows that this is internally working as implemented, but the scope is easy to misunderstand:

  • the setting is described internally as Whether new popout-window tasks default to projectless mode;
  • Ctrl+N invokes the separate newTask / New Chat command;
  • projectless creation is a separate newProjectlessTask / New standalone chat command, currently bound to Ctrl+Alt+O.

So this is not a persistence failure in the setting. It is a discoverability/default-context gap: users who want every ordinary new chat to start projectless cannot express that preference through the visible setting, and Ctrl+N silently inherits the currently selected project.

Suggested narrow improvement:

  1. Add a global New chat default context preference: Current project or Standalone.
  2. Apply it to newTask / Ctrl+N; keep New standalone chat as an explicit override.
  3. Clarify the existing setting label/description so it explicitly says it affects only the Popout Window.
  4. Document the New standalone chat command and its shortcut in the desktop keyboard-shortcut reference.

The current workaround is to invoke New standalone chat directly, or remap that command to Ctrl+N in Settings > Keyboard Shortcuts and remove the conflicting binding from New Chat.