Remote Control should support host General Chats / projectless chats, not only Projects

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

What variant of Codex are you using?

Codex Desktop App with Remote Control / Control other devices

What feature would you like to see?

When using Codex Desktop to control another Codex Desktop host, the remote-control flow should expose the host's Chats / projectless general-chat surface, not only host Projects or selected project folders.

Current behavior

After connecting to another device through Settings > Connections > Control other devices, starting a new chat appears to behave much like adding a remote project: the user is pushed toward choosing an existing directory/project on the host or creating a project-like workspace on that host.

That works for codebase-specific work, but it does not preserve the normal local Codex Desktop mental model where the sidebar separates:

  • general Chats
  • project-scoped Projects

For general questions, planning, homelab/smart-home debugging, personal operations, or other non-repo work, users should not need to create or pick a project folder just to ask a host-backed general question.

Expected behavior

A remote-control client should allow the user to start and continue the host's projectless/general chats, with the same first-class separation that the local Desktop UI provides.

Possible UX options:

  • Show the host's Chats section alongside host Projects in the remote-control sidebar.
  • Add a New General Chat on action when connected to a controlled device.
  • Let projectless chats created from the remote client appear under the host's normal Chats section.
  • Preserve host continuity so a chat started from MacBook while controlling a Mac mini is later visible from phone when controlling the same Mac mini.

Why this matters

The new Remote Control feature is valuable because it lets one always-on host act as the continuity anchor. A common setup is:

  • always-on Mac mini or desktop host running Codex Desktop;
  • laptop and phone used as remote-control clients;
  • host has the MCPs, plugins, credentials, and active local environment;
  • user switches between project work and general/non-project questions throughout the day.

Without host-backed General Chats, users are forced into awkward workarounds:

  • create a fake "general" project folder on the host;
  • use a random existing folder as the catch-all cockpit;
  • fall back to screen sharing to the host just to use the host's real General Chats UI;
  • or start local-only general chats on the client, losing remote continuity.

That weakens the main promise of Remote Control: one host-backed Codex workspace that can be controlled from multiple devices.

Related issues

This is related to, but distinct from:

  • openai/codex#9224: broader Codex Remote Control request, now available in preview.
  • [#12397](<https://github.com/openai/codex/issues/12397>) / [#10950](<https://github.com/openai/codex/issues/10950>): General Chat / projectless chat requests, closed before the current Remote Control workflow shipped.
  • openai/codex#22345: moving chats into/out of Projects.
  • openai/codex#19909 and openai/codex#22875: configuring the projectless chat workspace directory.
  • openai/codex#22806: remote sidebar state not matching Desktop sidebar state.

Those issues cover pieces of the model, but this request is specifically about exposing the host's projectless Chats experience through Desktop-to-Desktop and mobile Remote Control.

Additional information

The desired outcome is not cloud execution. The host should remain the source of truth for tools, MCPs, filesystem access, credentials, approvals, and chat state. The remote client should simply be able to create and steer the same kind of projectless General Chat that the host Desktop app already supports locally.

View original on GitHub ↗

4 Comments

github-actions[bot] contributor · 3 months ago

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

  • #22819

Powered by Codex Action

jonathanlaniado · 3 months ago

Not a duplicate.

#22819 is a mobile persistence bug: projectless chats can be created, but disappear after reconnect. This issue is a Desktop-to-Desktop Remote Control UX gap: the remote client does not expose the host’s General Chats / projectless chat surface as a first-class place to start or resume chats.

IgDiaz · 2 months ago

Was this updated?

iamhectorlopez · 4 days ago

Confirming the broader Remote parity request is still relevant.

On Android Remote controlling a macOS host, No project is visible, but host-backed projectless/general chat is not practically usable because task creation fails at project-trust verification before the task starts. The same Mac can create a projectless task locally in the desktop app. The specific Android → macOS failure is tracked in #39678.

So even where the mobile picker exposes No project, Remote still needs a first-class, working General Chats/projectless path with desktop parity rather than requiring a saved project as the practical workaround.