codex - 💡(How to fix) Fix Remote Control should support host General Chats / projectless chats, not only Projects

Official PRs (…)
ON THIS PAGE

Recommended Tools

×6

Utilities matched from this issue’s tags and category — try them while you read without losing context.

GitHub issue graph ai analysis

Paste a GitHub issue URL. We fetch that issue, discover linked issues from bodies/comments/timeline, collect linked pull requests, and produce a structured English report.

The report is written in English Markdown for sharing and archival.

Helpful · Quick feedback

Loading…

Root Cause

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.

Fix Action

Fix / Workaround

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

RAW_BUFFERClick to expand / collapse

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 <host> 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:

  • #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.
  • #22345: moving chats into/out of Projects.
  • #19909 and #22875: configuring the projectless chat workspace directory.
  • #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.

Vote matrix · Quick signals

Works
Did the solution work? Tap to confirm.
Easy Fix
Was it a quick fix?
Time Saver
Did it save you time?
Blocking
Was it severely blocking?
Common Issue
Are others likely hitting this too?
Flaky / Intermittent
Is it intermittent?
Verified / Reproducible
Can you reproduce it reliably?
Loading…

FAQ

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 <host> 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.

Still need to ship something?

×6

Another batch ranked right after the header list — different links, same matching logic.

Back to top recommendations

TRENDING

codex - 💡(How to fix) Fix Remote Control should support host General Chats / projectless chats, not only Projects