[macOS][Work/Codex] Work mode cannot create SSH remote projects although it can use projects created in Codex mode

What version of the Codex App are you using (From “About Codex” dialog)?

ChatGPT desktop app for macOS, version 26.908.40834.

What subscription do you have?

ChatGPT Pro.

What platform is your computer?

macOS on Apple Silicon.

What issue are you seeing?

The unified ChatGPT desktop app allows an SSH-backed remote project to be used from ChatGPT / Work mode, but the UI for creating that same remote project is only exposed in Codex mode.

This makes the Work/Codex split visible as an arbitrary project-management restriction rather than a real capability boundary.

In practice:

• In Work mode, there is no way to create/add a project from an already configured SSH host.
• Switch the application to Codex mode, and the same configured SSH host can be used to create the remote project normally.
• Switch back to Work mode, and the newly created SSH remote project is present and fully usable there.

So Work mode is clearly capable of operating against the SSH-backed project once it exists. Only the creation affordance/path is gated behind Codex.

Feedback ID:

no-active-thread-01a0a2fa-43f7-7db3-9913-4f602393531e

What steps can reproduce the bug?

1. Open the ChatGPT desktop app on macOS.
2. Ensure an SSH host is already configured and available to the app.
3. Select ChatGPT / Work mode.
4. Attempt to create/add a new project rooted on that SSH host.
5. Observe that Work mode does not expose a way to create the SSH remote project.
6. Switch the app to Codex mode.
7. Create the remote project using the same SSH host.
8. Switch back to ChatGPT / Work mode.
9. Observe that the newly created remote project is now present and can be used normally from Work mode.

What is the expected behavior?

SSH remote-project creation should be available anywhere SSH remote projects themselves are usable.

A user should not have to switch from Work to Codex solely to expose the project-creation UI, create the project, and then immediately switch back to Work.

If Work mode can open and operate against the resulting SSH-backed project, it should also be able to create/add it.

Why this matters

This is particularly disruptive for workflows where research, planning, architecture discussion, model comparisons, and other context live in normal ChatGPT / Work conversations, while the project itself executes on an SSH-connected machine.

Codex mode does not expose the same ChatGPT conversation/research history, so requiring Codex solely for remote-project creation creates an artificial workflow boundary:

Research / planning in Work -> switch to Codex just to create SSH project -> switch back to Work to continue using it

There does not appear to be a technical reason for that boundary because the project remains usable after switching back.

Related issues

Related, but not duplicates:

• #40963 — Project-scoped Work/Codex environments instead of app-global or session-derived mode. This covers the broader problem of the app-global Work/Codex split controlling project semantics.
• #33723 — Desktop app makes normal Chat inside cloud Projects impossible and conflates cloud, local, and SSH workspaces. This covers broader project/workspace inconsistencies across Chat, Work, Codex, local, cloud, and SSH surfaces.

This report is intentionally narrower: the same SSH remote project can be used in Work mode but can only be created from Codex mode.

Start by reproducing the SSH remote-project creation flow in the macOS desktop app from Work mode, then compare it with the Codex-mode flow that creates the project. Trace where the project-creation affordance is gated by mode; done means a configured SSH host can create a project from Work mode and the resulting project remains usable there.