# What you will learn

• How codex-bridge turns web ChatGPT into a local file reader and agent orchestrator via MCP
• The exact install steps (Swift build, MCP config) and a minimal example
• Which local agents it connects to, and what approvals and live output actually look like
• Why this is a young, promising repo rather than a mature product
• The biggest limitation: security and the trust boundary you have to own

# What codex-bridge actually does

You know the frustration: you're in ChatGPT's web interface, thinking through a refactor, and the model can only talk about your codebase in the abstract. It can't open the file, can't run the test, can't see the error. Fanch-hui/codex-bridge is a bridge built to fix exactly that. It's an MCP (Model Context Protocol) server that gives the web version of ChatGPT local read/write access and connects it to local coding agents — Codex, OpenCode, DeepSeek Harness (dsh), and Antigravity (agy) — so ChatGPT can act as the brain and dispatch work to those agents on your machine.

Here's the concrete problem it solves. MCP is the emerging standard for giving models tools, but most MCP servers assume the model and the tools live in the same environment. Web ChatGPT doesn't. Codex-bridge sits in between: ChatGPT calls the bridge, the bridge exposes your local filesystem and your installed agents as tools, and you get approvals and live output so you're not handing the keys over blindly. That last part matters. The repo is explicit about approvals, live output, and session control — the three things that separate a useful agent orchestrator from a remote code execution vulnerability with a chat window.

The project is written in Swift, which is an unusual choice for this kind of tooling and tells you something about the author's environment (likely macOS-first). It appeared on GitHub Trending with a modest but real star count in the low hundreds, and the source material dates it to late 2026. Treat that as a signal of interest, not maturity.

# How to install it and wire it to ChatGPT

Because this is a young repo, the README is your source of truth for exact commands — I won't invent flags that aren't there. But the shape of the setup is predictable for an MCP bridge, and you should expect these steps:

1. Clone and build. Since it's Swift, you'll need a Swift toolchain (Xcode command line tools on macOS). Clone the repo and build the executable with swift build -c release.
2. Run the MCP server. Launch the built binary so it listens for MCP connections. The repo describes it as a bridge, so expect a local server process you keep running while you work.
3. Register it with your MCP client. Point your MCP-capable ChatGPT integration at the bridge's command or socket. In a typical MCP config this looks like a JSON entry naming the command that starts the server.
4. Point it at your projects and agents. Configure which local directories it can read/write and which agents (codex, opencode, dsh, agy) it should be allowed to invoke.

A minimal mental example: you ask ChatGPT to "run the failing test in the auth module and have Codex propose a fix." ChatGPT calls the bridge's file-read tool to see the test, calls the agent tool to launch Codex with that context, and streams the output back to you. You approve the write before it lands. That's the whole value proposition — the model stays in the chat, the work happens locally, and you stay in the loop.

# Who this is for, and the one thing that makes it different

This is for developers who already live in ChatGPT's web UI and have local agents installed but hate context-switching. If you're a terminal purist running Codex directly, you're not the target. If you're on Windows or Linux and the Swift build is rough, you're also not the target yet.

The differentiator is the brain/agent split. Most tools make ChatGPT either a chatbot or an agent. Codex-bridge makes it a dispatcher: ChatGPT reasons about the task, then delegates execution to whichever local agent fits — Codex for one job, OpenCode for another, DeepSeek Harness or Antigravity when you want a different model's take. That orchestration layer, with approvals and session control baked in, is the interesting bet. It's also the same bet the industry is making broadly: as I argued in AI codes better than most devs — that was never the job, the value is shifting from raw generation to coordination and oversight.

# Where it falls short

Let's be honest about the limitations. First, this is a young repository, not a mature product. Expect rough edges, sparse docs, and API churn. The Swift choice narrows the audience considerably. Second, and more importantly, the security model is yours to own. A bridge that gives a remote model read/write access to your filesystem and the ability to launch agents is, by definition, a high-trust component. The approvals feature is the mitigation, but you need to actually read what each tool can do before you enable it. This is the same trust problem the industry is wrestling with everywhere — see AIUC wants to insure rogue agents for how the insurance crowd is thinking about it.

Third, live output and session control are advertised but, in a repo this young, likely uneven across the four supported agents. Don't expect parity. And fourth, there's no evidence yet of a community, plugin ecosystem, or long-term maintenance commitment. If you adopt it, adopt it as an experiment.

# The bottom line

Codex-bridge is a smart, timely piece of glue. It takes the MCP standard seriously and uses it to solve a real annoyance: web ChatGPT is smart but blind, and your local agents are capable but disconnected. Bridging them with approvals is the right instinct. The execution is early, the platform is narrow, and the security burden is real — but if you're a macOS developer already juggling ChatGPT and local agents, it's worth a weekend. The broader lesson, one I keep coming back to in pieces like V7 gives AI agents institutional memory, is that the orchestration layer — not the model — is where the next round of useful tooling is being built.