Support Desktop using the managed local App Server for direct mobile SSH/Tailscale control
Nobody has claimed this yet.
Assessment
- Difficulty
- 5/5
- Estimated time
- Over a week
- Newbie friendliness
- 35/100
- Issue type
- Feature
- Clarity
- Mostly clear
- Activity status
- Active
- Domain
- cli, desktop, networking
Research direction
Start by reproducing the managed App Server flow with codex app-server daemon bootstrap, CODEX_APP_SERVER_USE_LOCAL_DAEMON=1, and codex app-server proxy. Inspect the existing Desktop local-daemon path and the Unix socket connection described in the issue. Done means the workflow has a supported Desktop setting and documented persistent macOS configuration without requiring the undocumented environment variable.
Written by the indexing model from the issue text.
Description
Summary
I wanted to control Codex Desktop from the ChatGPT mobile app over my own private network, using Tailscale and SSH, instead of using the hosted Remote Control relay.
The hosted relay is significantly slower in my network environment. Direct SSH over Tailscale has much lower latency, but I still want the native Codex Desktop experience: threads, approvals, plugins, diffs, and project context.
I found a working configuration where Codex Desktop and the ChatGPT mobile SSH client connect to the same managed App Server process.
Working setup
Environment:
- macOS
- Codex standalone CLI 0.144.1
- ChatGPT/Codex Desktop
- ChatGPT mobile Codex SSH connection
- Tailscale as the private network
- Same macOS user and
CODEX_HOME
Install the standalone Codex package:
curl -fsSL https://chatgpt.com/codex/install.sh | sh
Start the managed App Server:
~/.local/bin/codex app-server daemon bootstrap
Enable the existing Desktop local-daemon path:
launchctl setenv CODEX_APP_SERVER_USE_LOCAL_DAEMON 1
After completely restarting ChatGPT/Codex Desktop, the Desktop app connects to:
~/.codex/app-server-control/app-server-control.sock
The ChatGPT mobile SSH connection automatically runs:
~/.local/bin/codex app-server proxy
That proxy connects to the same Unix socket.
Verified process topology
Codex Desktop ───────────────┐
├─ managed codex app-server
ChatGPT mobile → SSH → proxy ┘
The managed server was:
~/.codex/packages/standalone/current/codex app-server --listen unix://
I verified with lsof that:
- Codex Desktop had one connection to the App Server Unix socket.
- The mobile SSH proxy had another connection to the same socket.
- Both connections terminated at the same App Server PID.
- Messages sent from mobile appeared in the same live Desktop thread.
No public WebSocket port was exposed. Tailscale provided private network reachability, SSH provided authentication and transport, and the App Server remained bound to its user-private Unix socket.
Important installation detail
The Homebrew single-binary Codex installation was not sufficient for this Desktop configuration because it did not include codex-code-mode-host.
The official standalone installation provided both:
~/.codex/packages/standalone/current/bin/codex
~/.codex/packages/standalone/current/bin/codex-code-mode-host
Request
Could this workflow become a supported and documented option?
Ideally, Codex Desktop would provide a setting such as:
Use managed local App Server
This would avoid relying on the undocumented CODEX_APP_SERVER_USE_LOCAL_DAEMON=1 environment variable.
It would let users:
- Use ChatGPT mobile's native Codex UI.
- Connect directly through SSH over Tailscale or WireGuard.
- Avoid the hosted Remote Control relay when direct private connectivity is available.
- Keep execution, files, credentials, permissions, and project context on the Mac.
- Preserve the native Codex Desktop experience.
- Avoid exposing an App Server WebSocket port.
A documented persistent macOS configuration would also be useful because launchctl setenv may not survive logout or reboot.
Related discussions
- #9224 — Codex Remote Control
- #11166 — Expose App Server over network transport
- #21551 / #21558 — Live peer-client co-presence
- #23102 — Mobile SSH App Server proxy flow
- #23482 — Hosted relay stalls while Tailscale connectivity remains responsive
- Dominant language
- Rust
- Stars
- 125k
- Forks
- 19.5k
- Avg merge
- 1m
- Merged PRs (30d)
- 1k
Contributor guide
First steps
- Read the whole issue, then the project's contributing guide.
- Comment on the issue to say you are picking it up — it saves two people doing the same work.
- Fork the repository and make your change on a branch.
- Open a pull request that references the issue number.
More from openai/codex
-
enhancement remote
Difficulty 2/5 1-3 hours Newbie friendliness 68/100
-
bug CLI windows-os
Difficulty 2/5 1-3 hours Newbie friendliness 76/100
-
macOS sandbox blocks hw.optional.arm64 sysctl, causing Flutter to misdetect Apple Silicon as x64 Openbug CLI sandbox
Difficulty 2/5 1-3 hours Newbie friendliness 78/100
-
bug CLI TUI
Difficulty 2/5 1-3 hours Newbie friendliness 90/100
-
CLI config enhancement skills
Difficulty 2/5 1-3 hours Newbie friendliness 84/100
Similar issues
-
risk:low runtime status:in-progress type:test
Difficulty 1/5 Under an hour Newbie friendliness 92/100
zeroclaw-labs/zeroclaw#11023 ·
-
good first issue refactor
Difficulty 2/5 1-3 hours Newbie friendliness 72/100
-
Difficulty 2/5 1-3 hours Newbie friendliness 86/100
kwakseongjae/auto-hwp#319 ·
-
area:cli bug filter-quality good first issue priority:medium
Difficulty 2/5 1-3 hours Newbie friendliness 84/100
-
Difficulty 1/5 Under an hour Newbie friendliness 72/100
bevyengine/bevy#25861 ·