Feature request: create/register a new local Codex project and first thread from mobile

Open 💬 3 comments Opened Jun 13, 2026 by Celob185

Request

Allow ChatGPT Codex mobile to create/register a new local Codex project and start the first thread on a connected desktop host.

Current behavior

Today, mobile can continue local projects that already appear in the project list, but it does not appear to provide a first-class way to bootstrap/register a new local folder from mobile.

In a controlled local comparison:

| creation path | local state shape | mobile result |
| --- | --- | --- |
| codex debug app-server send-message-v2 ... from a fresh folder | source=vscode, thread_source=NULL, originator=Codex Desktop | folder appeared in ChatGPT Codex mobile |
| codex exec -C <folder> ... from a fresh folder | source=exec, thread_source=user, originator=Codex Desktop | local session was created, but folder did not appear in ChatGPT Codex mobile |

Token usage was effectively the same in this comparison (23432 vs 23417 total tokens in local rollout evidence), so the practical difference was project registration / mobile visibility rather than cost.

Desired behavior

From ChatGPT Codex mobile, I want to:

Choose a connected desktop host.
Select or enter a local folder path on that host.
Create/register the folder as a Codex project.
Start the first thread in that project.

Why this matters

Mobile is useful for continuing Codex work remotely, but today I still need to use a desktop/app-server path once before mobile can see a new local project. This makes mobile less useful as a true remote-control surface for starting work.

Suggested implementation

Expose the same registration behavior used by Desktop/app-server-created threads as a first-class mobile action, for example:

"New local project"
"Register folder on host"
"Start thread in folder"

This would avoid requiring users to run codex debug app-server send-message-v2 manually just to make a folder visible from mobile.

View original on GitHub ↗

3 Comments

DiscoStew6082 · 1 month ago

This is blocking my use case as well. I need to start work in a new folder while away from my Mac, but mobile Remote only exposes previously registered projects. Please support registering/selecting a host folder and starting its first thread entirely from mobile.

xiaoxuesheng123467 · 10 days ago

Adding another affected-user report for this same workflow.

Use case: use ChatGPT/Codex mobile as a real remote-control surface while away from the desktop host, and start work in a new local folder on the connected Mac/PC host.

Current behavior seen by the user:

Mobile Remote can select projects that already appear in the host-backed project list.
A brand-new local folder/project cannot be registered from mobile.
If the folder has never had a Codex thread/task created through the desktop/app-server path, it is absent from the mobile project picker.
The practical workaround is still: go back to the desktop host, open/register the folder there, create the first Codex thread/task, then return to mobile and continue from the now-visible project.

Why this is painful: it breaks the core remote-host use case. If I am away from the Mac/PC, I cannot bootstrap a new project even though the host is online and already has the filesystem, credentials, SSH/VPN access, and Codex environment.

Expected behavior:

Choose a connected desktop host from mobile.
Enter or select a folder path on that host.
Register it as a Codex project.
Start the first thread/task in that project entirely from mobile.

A clear “new local project on this host” / “register folder on host” flow would solve this. If direct folder registration is intentionally unsupported on mobile, the UI should say that explicitly and point users to the required desktop bootstrap step.

Local version detail captured from the current host: codex-cli 0.148.0-alpha.9. Mobile app version not captured.

mshostack · 5 days ago

Confirmed this workaround on a directly paired, headless Linux Remote host—no desktop app or intermediate SSH host involved.

Environment:

Codex CLI 0.149.0
Managed experimental Linux app-server with Remote Control connected
ChatGPT mobile connected directly to that Linux environment
Existing Git repository under the Remote host’s workspace

Results:

codex exec -C /workspace/example-project ... created a durable thread, but the project remained absent from mobile.
Calling experimental project/create succeeded, and project/list returned the correct project root, but mobile still omitted it.
Creating a project-linked thread with thread/start, then completing a read-only turn, still did not surface it.
Running this from the repository directory worked:

``bash codex debug app-server send-message-v2 \ -c 'sandbox_mode="read-only"' \ -c 'approval_policy="never"' \ "Identify the repository directory and branch only. Make no changes."``

After that app-server-native turn completed, the project appeared in ChatGPT mobile immediately.

No daemon restart, host re-pairing, mobile logout, or repository modification was required.

One potentially useful detail: send-message-v2 launched a separate app-server process whose Remote Control status was disabled, yet the thread metadata it persisted was sufficient to trigger mobile project indexing. This suggests mobile visibility depends on the thread creation/origin path—not merely the durable project registry, cwd, recent activity, or projectId.

This reproduces and strengthens the issue’s original comparison on a headless Linux Remote host. A first-class mobile “register folder/start first thread” action—or indexing directly from project/list—would eliminate this workaround.