›_ Codex Issues
Codex Issues / #11166

Expose app-server over network transport for remote/mobile session attach

Resolved 💬 5 comments Opened Feb 9, 2026 by colonelpanic8 Closed Apr 2, 2026
💡 Likely answer: A maintainer (etraut-openai, contributor) responded on this thread — see the highlighted reply below.

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:3284

Ideally 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

  • #9224 — Codex Remote Control (same motivation, different framing)
  • #10816 — Create mobile codex app
  • #2744 — Connect from ChatGPT desktop app
  • #5780 — Remotely control the local CLI (closed for low engagement — demand has grown significantly since)
  • anthropics/claude-code#24365 — Parallel request for Claude Code

View original on GitHub ↗

5 Comments

ForkyTheBot · 6 months ago

"The community has built 20+ third-party projects to work around the lack of a remote interface" - We just launched ForkOff this week as another approach to this exact problem.

What we built:
Instead of exposing app-server over network transport (which requires protocol changes from OpenAI), we built a layer on top that handles mobile approval specifically:

  • When Codex (or Claude Code/Cursor) needs approval → Push notification to your phone
  • See exactly what it wants to do (file diffs, bash commands, full context)
  • Tap approve/deny from phone
  • Session continues immediately
  • E2E encrypted (code never touches our servers)

Why we didn't wait for native support:
You're right that every third-party solution "reinvents encrypted relays, session polling, and approval-prompt parsing." But the alternative is waiting for Codex/Claude Code/Cursor to all ship native remote interfaces - which may never happen, or may take years.

Our positioning:

  • Codex ships codex serve natively → ForkOff becomes unnecessary (ideal outcome)
  • Until then → ForkOff lets you approve from mobile TODAY (works with Claude Code currently, Cursor CLI + Codex roadmapped)

On the "Happy Coder, Omnara, Zane" mention:
You're absolutely right - the demand is massive (proven by multiple teams building this independently). We're in that same category - solving it from the "mobile approval" angle specifically.

Re: ACP protocol:
Agree that ACP standardization would be better than tool-specific adapters. If Codex ships ACP over network, we'd happily integrate with it instead of maintaining our own relay.

Waitlist at https://forkoff.app (currently works with Claude Code, Cursor/Codex coming soon)

(Disclosure: I work on ForkOff. Your feature request is spot-on - native protocol support would be ideal. Until then, we're solving it at the approval workflow layer.)

---

P.S. The "20+ third-party projects" stat validates the market - but also shows the fragmentation. Would love to see Codex ship this natively so the ecosystem can consolidate around a stable protocol.

etraut-openai contributor · 6 months ago

See https://github.com/openai/codex/pull/10693. This is still experimental, so it could change.

vruru · 5 months ago

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:

  • one Telegram private chat or forum topic mapped to one Codex thread
  • real-time back-and-forth from Telegram instead of the local TUI only
  • thread steering / follow-up messages while Codex is already running
  • model / reasoning / speed / permission switching from Telegram commands
  • file and image input, plus voice-note-to-text forwarding for Codex conversations
  • macOS menu bar app + launchd, and Linux systemd user service support
  • release builds for macOS and Linux

Why this matters:

  • it solves a real gap today: Codex cannot natively live inside a mainstream messaging tool like Telegram, so users who want remote/mobile/chat-based workflows have to build their own bridge layer
  • once you have that bridge, Codex becomes much more usable away from the workstation: checking a long-running task, continuing a thread from a phone, sending a quick follow-up, reviewing output from a group/topic workflow, etc.
  • this is especially useful for people who already coordinate work in chat tools and want Codex to fit into that loop instead of forcing everything through a local terminal or desktop UI

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 · 4 months ago

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 contributor · 4 months ago

This feature is now implemented.