Connect to Codex CLI from the ChatGPT desktop app

What feature would you like to see?

What

Enable the ChatGPT desktop app (Win/macOS) to detect and connect to a locally running Codex CLI instance, exposing it as a selectable model (e.g., "Codex CLI @ my-computer/my-directory"). All functionality from the ChatGPT app (searchable history, nice font/formatting, refined scroll behaviour, dictation, drag-and-drop file attachments) remains available, but responses are powered by the user’s local Codex.

Why

Better developer experience. The TUI is good, but developers miss out on all the nice affordances that have been added to the ChatGPT app over the years.

This might also save the codex-cli team re-inventing a whole bunch of features from the ChatGPT app one by one.

How (some rough ideas)

(I'm aware this involves changes across two repos, but only the codex CLI repo is public so I'm logging this here.)

MVP

ChatGPT app probes 127.0.0.1 on a particular port listened to by Codex.
Shows **“Codex CLI @ ... ” in the model selector if found.
Connect via WebSocket.
History persistence with Codex-tagged sessions.
Basic error handling (e.g. when viewing conversation on phone, the model isn't available).

Later phases

File/image forwarding.
WSL-aware port forwarding on Windows (if it doesn't just work out of the box)
Remote connection if local codex is exposed (maybe a terrible idea!)

Some inspiration could be taken from how Chrome Dev Tools allows access to local folders in the Sources tab. Perhaps the ChatGPT App could have something similar where you define in the app UI which folders you want to be able to access with Codex (and ultimately, there's no reason that the app itself couldn't manage the install and launching of Codex).

Open Questions

Should local Codex chats sync to cloud search?
Should tool-calls (e.g., Drive search) be proxied by the app or Codex?
How would it work with projects?
Would it require a different system prompt?
Should the ChatGPT UI show multiple codex instances (for multiple directories) if they're running? What if there's two instances for the same directory?
Should the ChatGPT UI allow viewing/changing sandbox and approval options?
Should the user have to manually run a Codex instance, or would this involve a background process.
How to handle codex-only interactions like interrupting (or is that basically the same as hitting the stop button in the app?) or running commands like !git status
Should this only be in the ChatGPT App, or also chatgpt.com (there's certainly something 'odd' about a website connecting to a local process, but I don't think there's any technical blocker)
I think there's this view that developers love being in the terminal; and maybe that's true for others, but for me I'd much prefer the well designed interface of the ChatGPT App. So the big question is: would a reasonable portion of developers prefer to interact with Codex through a more feature-rich UI? Maybe an internal OpenAI survey would provide an interesting insight.

Are you interested in implementing this feature?

No response

Additional information

No response

yes plz

Related #2614

While the Desktop App can connected to local instances in theory, often instances are running on remote servers and would require an outbound connection from codex CLI instead, but both should be supported an the UI should be similar in the ChatGPT Mobile App, web app and desktop app, just how it connects can differ.

You are suggesting to show it in the chat view, while I suggested to instead show in the Codex view. Right now the Codex is not available native in the desktop app, only the web app and mobile app.

One big disadvantage of showing it in the regular chat view is that it would make the chat list incredibly cluttered unless it switched the chat list betwen the codex agent chats and regular chats when switching models.

It might be better to show in the codex view rather than the chat view, otherwise it will just be cluttered, but that requires the codex view to be implemented in the desktop app too. In any case the UI of either the chat view or the codex view would need to be reworked a bit to get a good UX.

Below is a concrete, path to make Codex CLI feel first‑class across Desktop, Web, and Mobile—without cluttering the chat experience or compromising security.

TL;DR – Recommended direction

Architecture: Support two connection modes behind one UX.
1. Local Bridge (Desktop ↔ 127.0.0.1) for the fastest, private loopback.
2. Cloud Relay (CLI ↔ outbound WebSocket) so Web/Mobile/Desktop can reach remote or headless CLI instances with no inbound ports.
UX: A Codex workspace in Desktop (plus Web/Mobile), with an Agent List and a Session view. Keep regular chats uncluttered. Offer lightweight chat-side attach for “send this message to an agent” without moving users out of chat.
Security & privacy: Explicit scopes (FS, shell, network, git), per‑folder allowlists, capability negotiation, and opt‑in history/indexing.
MVP scope: Local discovery + selection; single-agent sessions; history persisted and labeled; basic error states; “Stop/Interrupt”; minimal settings for scopes.

1) Critique of the two proposals (and high‑impact fixes)

A. “Show Codex CLI as a selectable model in Chat”

Drawbacks

Chat list clutter: dozens of agent sessions pollute the single chat rail.
Mental model collision: regular model chats vs. stateful/long‑running agents with tools and FS access.
Missing agent constructs: diffs, runs, approvals, and logs don’t map cleanly into a plain chat transcript.

Fixes

Scoped list switching: when a Codex agent is the current “model,” the left rail switches to Agent Sessions only. A clear breadcrumb (“Chat ▸ Codex ▸ AgentName”) prevents confusion.
Inline agent sidecar: show Runs, Diffs, and Tools in a right‑hand side panel; chat stays center.
Smart routing: if a user tries to attach files or request FS actions, guide them to the Codex workspace (one click), not the regular chat view.

B. “Show Codex in a separate Codex view (Agents list)”

Drawbacks

Discoverability: developers living in chat may never open Codex view.
Context switching: jumping between chat and Codex can feel heavy.

Fixes

Hybrid navigation:
- A Codex workspace (Agents list + Sessions) for deep work.
- A chat-side attach action: from any chat message, “Send to Agent…” (choose agent → opens a lightweight session drawer or deep‑links into Codex workspace).
- A global switcher (⌘K / Ctrl‑K) that lists Chats, Agents, Sessions in one searchable surface.

Bottom line: Use a Codex workspace as the primary surface and chat-side attach as the bridge. Avoid polluting the main chat list.

2) Architecture options

Option	How it connects	Where it works	Pros	Cons	Recommendation
Local Bridge	Desktop app probes `127.0.0.1:PORT` (WebSocket)	Desktop only	Zero cloud, low latency	No Web/Mobile reach; WSL/path quirks	MVP
Cloud Relay	CLI keeps outbound TLS WS to a relay; clients fan‑in	Desktop/Web/Mobile	NAT‑proof, remote servers, teams	Requires auth & relay infra	Phase 2
P2P (STUN/TURN)	NAT traversal between client↔CLI	Desktop/Web/Mobile	Potentially lower relay cost	Complex, brittle	Later/Optional

Handshake (both modes)

Capability advert: CLI sends version, tools, FS scopes, project root(s), sandbox flags.
Auth: Device‑link or OAuth device code (“Run codex link → enter code in app”), short‑lived tokens, mTLS between relay and CLI where applicable.
Health: heartbeats, backoff, retry, status lights.

3) UX system

A. Agents list (Codex workspace left rail)

Sections: Online (green), Idle (yellow = waiting for input), Offline (gray).
Grouping: by Project (root path) and Host. Deduplicate by (host, projectRoot); allow aliases when two CLIs attach to the same dir.
Actions on hover: Start/stop, Pin, Share (team), Settings (scopes, approvals).

B. Session view (center)

Top bar: Agent name, project root, status pill, “Stop/Interrupt,” “Open project folder.”
Main stream: Interleaved Messages, Run steps, Diffs, Command output.
Right side panel (toggle):
- Files (allow‑listed tree; quick open),
- Tools (Drive/Git/Shell toggles),
- Runs (history),
- Approvals (pending prompts).
Input affordances: Dictation, drag‑and‑drop files, “Run in terminal” vs “Let agent apply.”

C. Chat-side attach (bridge from normal chat)

Right‑click / ellipsis on a message → “Send to Agent…” → choose agent → confirm context items (message, files).
Creates/links a session and shows a mini session drawer; deep‑link available.

D. Mobile/Web parity

Cloud Relay agents appear the same as Desktop agents.
Push notifications when an agent requests input or completes a run.

4) Permissions, safety, and privacy

Scopes at connect time: FS(Read/Write), Shell, Network, Git, Package Manager, Custom Tools.
- Each scope can be Allow, Ask, or Deny (policy per agent).
Folder allowlists: macOS security‑scoped bookmarks / Windows folder picker / Linux directory picker. Persisted per agent.
Command preview: For dangerous actions (e.g., rm -rf), require inline approval; show exact command and impact.
History & indexing:
- Default: store locally in Desktop app; cloud indexing off.
- Per‑agent toggle to sync transcripts and diffs for cross‑device search; redact secrets by default.
Audit & export: Per session event log (who, what, when), one‑click export of diffs/messages.

5) Handling multi‑instance, WSL, and remote hosts

Instance identity: (agentId, hostName, projectRoot, capabilitiesHash).
WSL & path mapping: Detect WSL; normalize paths (C:\… ↔ /mnt/c/...); show active environment (WSL1/2, distro).
Remote naming: Show hostName and an optional label (e.g., gpu-rig).

6) Feature mapping (MVP → Phases)

MVP (Desktop + Local Bridge)

Discovery on 127.0.0.1:PORT (configurable; single port or mDNS).
Agents list + Session view in Desktop.
History persistence (tagged as Codex); offline states; Stop/Interrupt.
Basic error handling: agent unavailable on phone/web; show last known state.

Phase 2 (Cloud Relay + Parity)

CLI outbound registration (codex link), team sharing, push notifications, Web/Mobile use.
File/image forwarding, secure upload/download channel.
Drive/Git/Shell tools proxied by CLI; cloud tools (e.g., Drive search) proxied by client—see Tool Broker below.

Phase 3 (DX polish)

One‑click install & run from Desktop; auto‑update CLI (opt‑in).
Templates (Node, Python, monorepo) with pre‑scoped folders.
Diff visualizations (three‑pane, inline comments), code map, and run timelines.

7) Tool Broker: where calls should execute

Local/host‑sensitive tools (FS, Shell, Git): CLI executes; app shows previews and asks for approvals.
Cloud tools (Drive search, issue trackers): Client/App executes via user’s cloud auth; results forwarded to agent.
Conflict behavior: If both can run a tool, prefer the actor with richer auth/context; expose a per‑agent override.

8) Interrupts, runs, and commands

Stop button maps to CLI interrupt (SIGINT or cooperative cancel).
Command mode: Prefix (!git status) or button converts the next instruction to a terminal command preview; user approves and the CLI runs it.
Run queue: One active run per agent by default; queued runs display ETAs; users can reorder/cancel.

9) Answers to the Open Questions

Should local Codex chats sync to cloud search?
Default off. Offer per‑agent opt‑in with redaction. Show a shield icon when a session is local‑only.
Should tool‑calls be proxied by the app or Codex?
Split: host‑sensitive via CLI; cloud/SAAS via client. Use a Tool Broker to route and show provenance.
How would it work with projects?
Agents attach to Project Roots; Sessions inherit project context (env, scopes). Agents can be grouped under Projects in the rail.
Different system prompt?
Yes—use a Codex‑operator system prompt that emphasizes reproducibility, conservative edits, and tool etiquette. Keep it visible and overridable per agent.
Multiple Codex instances for the same directory?
Allowed; show as siblings under the same project with different host labels. Offer a “prefer fastest/closest” default.
Sandbox and approval options in UI?
Yes—per‑agent Settings: scopes, approvals, environment, redaction, indexing. Quick toggles in the right panel.
Manual run vs background process?
MVP: manual (codex start). Phase 2: optional background helper managed by Desktop (with clear menu bar tray and Quit).
Interrupts and CLI‑only features (!git status)?
Supported as command mode with preview + approval. Stop maps to interrupt.
Desktop‑only or also web?
Desktop: Local Bridge + Cloud Relay. Web/Mobile: Cloud Relay only. The UI looks the same; the transport differs.
Will developers prefer a richer UI to a TUI?
Expect both camps. Provide workspace UX for rich interactions, terminal‑first workflow for purists, and chat‑side attach for casual use.

10) Key UI flows (concrete)

Connect a local agent (MVP):

User runs codex start (defaults to port 8719).
Desktop app detects agent → shows toast “Found Codex @ ~/repo” → Connect.
User selects allowed folders and scopes → agent appears Online in Codex workspace.

Link a remote agent (Phase 2):

On the remote machine: codex link → device code displayed.
In Desktop/Web/Mobile: Add Agent → Enter code → agent shows under “Remote”.
Push notifications when input is requested.

Send a chat message to an agent:

From any chat message → “Send to Agent…” → pick agent → a mini session drawer opens with the forwarded content and a link to the full session.

11) Reliability & diagnostics

Status footer in Session: latency, last heartbeat, queue length.
Diagnostics panel: recent errors, last 50 logs, “copy bundle” for bug reports.
Graceful degradation: when agent goes offline, keep read‑only transcript with a Reconnect CTA.

12) Security checklist

Outbound‑only networking for relay; no inbound ports required for Web/Mobile.
Short‑lived tokens; per‑agent revocation; optional mTLS between relay and CLI.
Content redaction for secrets; opt‑in cloud indexing; explicit scope gates.
Clear UX that distinguishes local‑only vs synced sessions.

13) What to build first (bite‑sized backlog)

Local Bridge detection + connect flow with folder picker and scopes.
Codex workspace (Agents list + Session view) in Desktop.
Session transcript with Runs, Diffs, Approvals, Stop.
Chat-side attach action.
Robust offline/unknown state handling.
Path normalization for WSL/macOS/Windows.
Export session (JSON + patch bundle).

Phase 2 adds Cloud Relay, mobile/Web parity, push notifications, team sharing, and file/image forwarding.

14) “Where this could go” (optional polish)

Code map + blame overlays in the right panel.
Run recipes (e.g., “Bump dependency safely”) as one‑click macros.
Session templates per framework (React, Django, Go).
Latency‑aware routing (prefer closest agent).

In the Codex web you also launch an agent, and it doesn’t clutter the chat list. After all, you’re running the main session, while the internally launched ones are stored within it.

it also need to come with tabs, like how terminal / browser we can keep open fresh chat while not closing it. then well be really great.

ram leak n performance issue still there. just a plain bring app in front cost 54% on m4 cpu.
less gui more hotkey make ux better, eg raycast chat.

that say chatgpt.com seems also can intergrat this.

Connect to Codex CLI from the ChatGPT desktop app #2744

Description