Repository navigation
Remote Control should support host General Chats / projectless chats, not only Projects #22947
Description
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:
- Codex Remote Control #9224: broader Codex Remote Control request, now available in preview.
- #12397 / #10950: General Chat / projectless chat requests, closed before the current Remote Control workflow shipped.
- Allow Chats to be moved into, out of, and between Projects #22345: moving chats into/out of Projects.
- Feature Request: [App] Make the "Chats" project directory configurable #19909 and Codex App: allow configuring default directory for projectless thread workspaces #22875: configuring the projectless chat workspace directory.
- Codex iOS remote sidebar does not sync Desktop project order or pinned chats #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.
Activity
github-actions commentedon May 16, 2026
Potential duplicates detected. Please review them and close your issue if it is a duplicate.
Powered by Codex Action
jonathanlaniado commentedon May 16, 2026
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 commentedon Jun 6, 2026
Was this updated?
iamhectorlopez commentedon Aug 23, 2026
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.
jvenezia commentedon Sep 21, 2026
I’m still running into this on macOS. I can connect to my remote Codex host and open existing conversations, but I can’t find a way to start a new projectless conversation on it. This works for me from iOS.
Is projectless remote chat creation planned for the macOS app? Any update on its priority or expected availability would be appreciated. If there’s already a supported way to do this, I’d be happy to try it.
MtkN1 commentedon Oct 1, 2026
Good news, this is working for me now! I'm currently using a projectless chat on a Linux host from the ChatGPT desktop app on Windows, without having to create or select a project first.
The “Work in” picker for projectless chats now shows “This computer”, “Cloud”, and “Remote”. Selecting “Remote” lets me start the chat on my Linux machine.
My guess is that this might be related to the recent rollout of the new Codex Cloud environments. I'm not sure whether this was an intentional change for Remote users or just a happy side effect of that work, but either way, it's a welcome improvement!
One remaining limitation: I still can't seem to choose where projectless chat directories are created. The workspace root appears to be fixed to
~/Documents/Codex. I tried changingprojectlessWorkspaceRootunder[desktop]in both the local and remoteconfig.tomlfiles, but neither change had any effect.My setup: