Summary
When using Settings > Connections > Control other devices between two Macs, a project created from the controlling Mac appears in that Mac's project list, but does not appear in the controlled Mac's project list. The project folder and its Git repository exist on the controlled Mac, and the chat can run commands there normally.
Read-only checks on the controlled Mac found no saved project record for the folder. This appears to be a remote project registration or synchronization issue, although the root cause and intended behavior are not yet established.
Environment
- Connection: Mac-to-Mac Remote Control (not SSH).
- Controlled host: Mac mini, macOS 27.0.1.
- Controlled host desktop app: 26.1007.30912, build 20156, read from the installed app's Info.plist.
- Controlling Mac's app and OS versions: not collected.
- Observed on October 11, 2026.
Observed sequence
These are the steps from the affected session, rather than a verified clean-install reproduction:
- Connect the controlling Mac to another Mac using Control other devices.
- Create a project from the controlling Mac, pointing to a project folder on the controlled Mac.
- Start a chat in that folder and clone a private Git repository directly into the folder's root.
- Compare the project lists on the two Macs.
The user sees the project in the controlling Mac's project list, but not in the controlled Mac's project list. Cloning succeeds, the working tree is clean, and the chat can read the files on the controlled Mac.
Read-only diagnostics on the controlled Mac
- The shell hostname confirms that commands execute on the controlled Mac mini.
list_threads returns the affected chat with the correct working directory, but projectId: null.list_projects does not return the affected project or any saved local Codex projects; it returns only unrelated ChatGPT projects.- In the host's
state_5.sqlite, both projects and project_roots contain zero rows.
- In the host's
.codex-global-state.json, local-projects is empty and selected-project is null.
The controlling Mac's project registry has not been inspected. Its project visibility is based on the user's observation, so we cannot yet confirm where or how that client-side entry is persisted.
No application state or database records were edited, and the folder was not manually re-added on the host during this investigation. Repository names, private URLs, absolute user paths, chat IDs, and credentials are omitted.
Expected behavior
If adding a project through Remote Control is intended to register it on the selected host, the host's saved-project registry and desktop project list should reflect that project. The chat should also be associated with that saved project.
If remote projects are intentionally saved only on the controlling client, please clarify that behavior in the documentation and UI, including whether the same folder must be added separately on the host.
Actual behavior
The controlling Mac shows a project entry, while the controlled Mac has the folder and chat but no saved project record. The chat is reported with a null project ID.
Related reports
Could you confirm whether client-created Remote Control projects should be registered on the host, and investigate why the host has no project record in this case?
Summary
When using Settings > Connections > Control other devices between two Macs, a project created from the controlling Mac appears in that Mac's project list, but does not appear in the controlled Mac's project list. The project folder and its Git repository exist on the controlled Mac, and the chat can run commands there normally.
Read-only checks on the controlled Mac found no saved project record for the folder. This appears to be a remote project registration or synchronization issue, although the root cause and intended behavior are not yet established.
Environment
Observed sequence
These are the steps from the affected session, rather than a verified clean-install reproduction:
The user sees the project in the controlling Mac's project list, but not in the controlled Mac's project list. Cloning succeeds, the working tree is clean, and the chat can read the files on the controlled Mac.
Read-only diagnostics on the controlled Mac
list_threadsreturns the affected chat with the correct working directory, butprojectId: null.list_projectsdoes not return the affected project or any saved local Codex projects; it returns only unrelated ChatGPT projects.state_5.sqlite, bothprojectsandproject_rootscontain zero rows..codex-global-state.json,local-projectsis empty andselected-projectis null.The controlling Mac's project registry has not been inspected. Its project visibility is based on the user's observation, so we cannot yet confirm where or how that client-side entry is persisted.
No application state or database records were edited, and the folder was not manually re-added on the host during this investigation. Repository names, private URLs, absolute user paths, chat IDs, and credentials are omitted.
Expected behavior
If adding a project through Remote Control is intended to register it on the selected host, the host's saved-project registry and desktop project list should reflect that project. The chat should also be associated with that saved project.
If remote projects are intentionally saved only on the controlling client, please clarify that behavior in the documentation and UI, including whether the same folder must be added separately on the host.
Actual behavior
The controlling Mac shows a project entry, while the controlled Mac has the folder and chat but no saved project record. The chat is reported with a null project ID.
Related reports
projectId. That report involves an existing saved project and the opposite visibility direction.Could you confirm whether client-created Remote Control projects should be registered on the host, and investigate why the host has no project record in this case?