Repository navigation
Expose app-server over network transport for remote/mobile session attach #11166
Description
What feature would you like to see?
The Codex app-server already has an excellent bidirectional JSON-RPC 2.0 protocol with full session lifecycle, approval workflows, and event streaming. The TUI is reportedly being refactored to connect to remote app-server instances. The ask is to ship this: let the app-server listen on a Unix socket or TCP port so that remote clients can attach to running Codex sessions.
Something like:
# Listen on a Unix socket (ideal for SSH — no port forwarding needed)
codex serve --socket /tmp/codex.sock
# Or listen on a TCP port
codex serve --port 3284
# Attach from anywhere
codex attach /tmp/codex.sock
codex attach host:3284Ideally speaking ACP, since Codex already supports it (via codex-acp) and ACP has broad adoption (Zed, JetBrains, GitHub Copilot CLI, Gemini CLI, Claude Code). Exposing ACP over a network socket would make Codex accessible to any ACP-compatible client — including Toad (2.1K stars) and potential mobile ACP clients — without needing tool-specific adapters.
Why this matters
The community has built 20+ third-party projects to work around the lack of a remote interface for agentic coding tools — mobile apps (Happy Coder, 10.8K stars; Omnara, YC S25; Zane, which already builds on Codex's app-server), Discord/Telegram bridges, web UIs, etc. Every one of them reinvents encrypted relays, session polling, and approval-prompt parsing. They break when the CLI updates because they're scraping terminal output rather than speaking a stable protocol.
Codex is architecturally closer to solving this than any other tool — the app-server already cleanly separates UI from agent logic. The missing piece is just letting it listen on a socket.
Prior art
- OpenCode already ships this:
opencode serve/opencode attach http://host:port - Codex app-server already has the JSON-RPC protocol — it just needs a network listener
- Zane (z-siddiqi/zane) demonstrated the viability by building a web client on top of the app-server's JSON-RPC interface via a Cloudflare Worker relay
Related issues
- Codex Remote Control #9224 — Codex Remote Control (same motivation, different framing)
- Create mobile codex app that can talk to codex on my local computer #10816 — Create mobile codex app
- Connect to Codex CLI from the ChatGPT desktop app #2744 — Connect from ChatGPT desktop app
- Remotely control the local CLI #5780 — Remotely control the local CLI (closed for low engagement — demand has grown significantly since)
- [FEATURE] Expose ACP over network transport (
claude serve) for remote/mobile session attach anthropics/claude-code#24365 — Parallel request for Claude Code
Activity
ForkyTheBot commentedon Feb 15, 2026
etraut-openai commentedon Feb 15, 2026
See #10693. This is still experimental, so it could change.
vruru commentedon Mar 13, 2026
I want to add a concrete community example here: we built a Telegram bridge for Codex that turns Telegram private chats and forum topics into a real-time conversational front end for local Codex threads.
Project: https://github.com/vruru/telegram_codex_bridge
What it already supports:
Why this matters:
The biggest architectural pain point is exactly what this issue describes: because app-server is not exposed as a first-class network/remote transport, third-party integrations have to wrap local Codex in their own control plane, persistence, service management, and message routing. That works, but it is more brittle than it should be.
So from experience building and shipping this bridge, I strongly support exposing app-server over a proper network transport (or another official remote interface). It would make Telegram / Discord / web / mobile front ends dramatically simpler and more robust, and it would let the ecosystem build on Codex without scraping UI behavior.
Asuka-wx commentedon Apr 2, 2026
I built a Telegram bridge to control Codex from my phone
Turn local Codex sessions on macOS into a Telegram control surface you can actually use from your phone.
https://github.com/Asuka-wx/codex-telegram-bridge
One-line positioning:
Keep your existing ssh + tmux + Codex workflow, and use Telegram only as the remote layer for status, approvals, and follow-up input.
Why It Matters
No workflow rewrite: keep using local tmux + Codex instead of switching to a browser dashboard or remote desktop
Actually remote-usable: not just logs, but approvals, interrupts, and follow-up input
Clear multi-task control: one control topic plus task-specific topics for parallel work
Phone-friendly by design: useful when you are away from your machine but still need to keep work moving
Lower setup friction: one-command installer plus launchd service support
etraut-openai commentedon Apr 2, 2026
This feature is now implemented.