OpenCodex: browser access to Codex Desktop on your own network
OpenCodex is a middleware layer for Codex/ChatGPT Desktop. It lets you use a phone, tablet, or another computer to access and operate Codex on a target machine through a browser, making it suitable for continuous AI Coding in LAN or remote LAN environments.
At a glance
- What is it?
- OpenCodex is a middleware layer that puts a browser front end on an existing Codex or ChatGPT Desktop installation, so a phone or another machine can drive the same runtime over a LAN, Tailscale or VPN. It is AGPL-3.0, JavaScript, and the last push to main was on 2026-09-13.
- Who is it for?
- OpenCodex fits engineers who already run Codex Desktop on a workstation and want the full session, file tree and terminal on a phone or second machine without a public relay. Skip it if you need a hosted service, a Linux desktop launcher, or a supported replacement for the official mobile Codex support in ChatGPT.
- Can I use it commercially?
- Yes, with strict conditions. AGPL-3.0 is a network copyleft licence: if people use a modified version over a network, for example as a hosted service, you must offer them its source code under the same licence.
- Is it still maintained?
- Yes. The repository last received commits 3 days ago.
- What is it written in?
- Mainly JavaScript, according to GitHub's language statistics.
Answers come from the project's GitHub data, last synced on September 15, 2026, and from our analysis. They are not legal advice.
DEEP OPEN-SOURCE ANALYSIS
What OpenCodex adds on top of an installed Codex Desktop
The project does not ship a coding agent. It attaches to one you already have. The README states that the machine must have either the older Codex Desktop or the newer ChatGPT Desktop with Codex inside it, and that the desktop app does not need to be running. OpenCodex then serves a browser interface that reaches the same runtime, so a session started on a phone is the session on the workstation.
The intended users are people who leave a machine on and want to keep working from elsewhere. The README frames this as continuous AI Coding, and lists the scenarios where it differs from the official mobile support in ChatGPT: no proxy network required, no foreign Google Play or Apple account, and third-party API logins still work remotely. It also keeps the full desktop surface rather than a chat window, naming the file tree, terminal and review views.
The last point matters more than it reads. A thin chat bridge would be a much smaller project. OpenCodex carries the whole UI, which is why the repository has a web-shell directory, a gateway, a launcher and a plugin SDK rather than a single server file.
Gateway, launcher and app-host: how the pieces connect
Three layers are visible in the repository layout. The launcher is an Electron application whose entry point is launcher/main.cjs, declared as main in package.json. The gateway is a Node service under gateway/. The web-shell directory holds the browser front end, and shared/ and sdk/ carry code and plugin interfaces used by more than one layer.
The gateway is the piece that talks to the desktop runtime. The environment table exposes CODEX_DESKTOP_APP_PATH for the install path or app.asar, CODEX_DESKTOP_EXECUTABLE_PATH for the Electron binary on Windows and Linux, and CODEX_APP_SERVER_BINARY_PATH for the Codex app-server or CLI binary on Windows. When these are unset the values are described as auto-scanned. CODEX_WEB_OFFICIAL_BUNDLE_DIR points at a cache for the unpacked official bundle, and CODEX_WEB_OFFICIAL_AUTO_SCAN_UPGRADE, default 1, decides whether the gateway rescans the official runtime at startup or reuses the cache unless it is missing.
That design explains the compatibility claim in the README about following the local Codex or ChatGPT Desktop runtime version. OpenCodex is not pinned to a protocol it defines. It unpacks and mirrors a runtime that someone else updates, which is also where its fragility lives.
A second path exists for plugins. OPENCODEX_PLUGIN_DIRS names external plugin roots whose structure must match web-shell/plugins, and the repository ships examples/plugin-v2-hello plus docs/PLUGINS.md. Plugin loading is therefore a directory convention, not a registry.
Installing OpenCodex and opening the first session
The README offers two routes. Most users take the desktop launcher, downloaded from the Releases page or from CI Artifacts, the latter requiring a GitHub login. The command line route is described as being for temporary debugging, and it is the one that can be reproduced from a terminal.
Start by installing dependencies in the repository root:
pnpm installThen start the gateway bound to the local machine only. The README uses port 3737 for this example:
PORT=3737 pnpm run web:devTo reach it from another device, bind all interfaces. The README pairs this with a strong recommendation to set an access password and change the port:
HOST=0.0.0.0 PORT=3737 pnpm run web:devThe password comes from a YAML file. Copy the example and edit the password field:
cp config.example.yaml config.yamlauth:
password: "your password"The gateway reads config.yaml by default; CODEX_WEB_CONFIG_PATH overrides the path. With the service running, open http://127.0.0.1:3737 in a browser. If the page does not load, the README suggests checking the health endpoint, which should return a successful response:
curl http://127.0.0.1:3737/api/healthFor remote use, OpenCodex does not act as a relay. The README directs you to Tailscale, ZeroTier, Cloudflare Tunnel or a self-hosted VPN, then to enable LAN mode in the launcher. It notes that exposing the service directly to the public internet is not recommended.
Session state, token accounting and the Auto model router
Two features in the README are worth separating from the marketing list. The first is token reporting: OpenCodex shows real token consumption, and projects and sessions sort by most recent update. That is a UI concern, but it changes how you work, because the cost of a long session becomes visible while you are in it.
The second is the smart scheduler. When the model selection is Auto, OpenCodex picks a model and a reasoning effort level based on the task, with the stated goal of saving tokens, and the README says the tiers can be customized per usage scenario. The repository backs this with gateway/test/model-router.test.cjs, model-router-classifier.test.cjs, model-router-presentation.test.cjs and model-router-transport.test.cjs.
Read that as a trade-off rather than a free win. A classifier that downgrades reasoning effort is guessing about your task. For exploratory work where the cost of a wrong answer exceeds the cost of tokens, pinning the model explicitly is the safer path, and the README does not describe an audit log of which tier was chosen for a given request.
Where OpenCodex is the wrong tool
The clearest limitation is stated by the project itself. If you run OpenCodex and the official desktop app at the same time, each maintains its own session state. The data is the same, but the README says synchronization may not be fully real time. The recommended workaround is to use only OpenCodex, locally as well as remotely, optionally as a PWA. That is a real constraint: adopting OpenCodex means giving up the native window as your primary client.
The second limitation is platform coverage. There is no prebuilt launcher for Linux. The README points to docs/LINUX_GUIDE.md and says command line use is advised. macOS and Windows get packaged installers through pnpm run launcher:dist:mac and pnpm run launcher:dist:win, with output in release/.
Third, first load can be slow. The FAQ attributes an empty session history on first open to loading time and to the speed of the remote LAN link, and suggests waiting and refreshing. If your link to the workstation is poor, the experience degrades in a way that has nothing to do with the code.
Finally, there is no hosted option and no official relay. OpenCodex does not provide remote access service. If you cannot run Tailscale, ZeroTier, Cloudflare Tunnel or your own VPN, this project does not solve your problem, and putting the gateway on a public address is something the README explicitly discourages.
Compared with the official Codex support in ChatGPT
The README opens by acknowledging that ChatGPT gained Codex support, and then argues for the remaining differences. The comparison is worth taking literally, because the two approaches are structurally different rather than feature-different.
Official support routes through vendor infrastructure. OpenCodex runs a gateway on the machine that holds the code and lets a browser connect to it over a network you control. That is why the README lists no proxy network, no foreign app store account, and support for third-party API logins as advantages. It is also why data does not pass a vendor relay.
The cost sits on your side of the line. You own the network setup, the port, the password, the TLS termination if you want it, and the upgrade path when the desktop runtime changes underneath. An official client carries none of that. If your goal is simply to check on a session from a phone and you already have the official app working, OpenCodex is extra infrastructure for a problem you do not have.
Maintenance, licensing and what an upgrade actually costs
The repository is not archived, and the last push to main was on 2026-09-13, the same day as the 2.1.0 release. Earlier releases were 2.0.3 on 2026-07-31 and 2.0.2 on 2026-07-10, so the release cadence over that window has been roughly monthly with a larger jump to 2.1.0.
The maintenance burden is unusual because part of it is not yours to control. CODEX_WEB_OFFICIAL_AUTO_SCAN_UPGRADE defaults to 1, which means the gateway rescans the official Codex runtime at startup. When the desktop app updates, OpenCodex is expected to follow it, and the README describes that as automatic compatibility. When it does not follow cleanly, the environment table gives you the escape hatches: set the flag to 0 to reuse the cached bundle, or point CODEX_DESKTOP_APP_PATH and the related path variables at a specific installation.
Licensing is AGPL-3.0. That is a copyleft licence with a network clause, so if you modify OpenCodex and let users interact with it over a network, the licence's source-availability terms are the thing to read before you build on it. The plugin system under OPENCODEX_PLUGIN_DIRS and sdk/ is where this question becomes concrete, since a plugin is code you distribute. This is a description of the licence, not legal advice; get your own reading if you plan to ship something.
Editorial conclusion
OpenCodex fits engineers who already run Codex Desktop on a workstation and want the full session, file tree and terminal on a phone or second machine without a public relay. Skip it if you need a hosted service, a Linux desktop launcher, or a supported replacement for the official mobile Codex support in ChatGPT. Verify first that pnpm install completes, that curl http://127.0.0.1:3737/api/health answers, and that config.yaml carries an auth.password before you bind HOST=0.0.0.0.
Frequently asked questions
What is OpenCodex?
It is a middleware layer for Codex Desktop and ChatGPT Desktop that lets a phone, tablet or another computer reach Codex on a target machine through a browser. The README describes it as suitable for continuous AI Coding over a LAN or a remote LAN built with Tailscale, ZeroTier or a VPN.
Does OpenCodex need Codex Desktop installed?
Yes. The environment requirements list Node, pnpm, and a local install of either the older Codex Desktop or the newer ChatGPT Desktop that includes Codex. The desktop app does not need to be running, and the README says both can be used at the same time.
Can I use OpenCodex over the public internet?
The README says OpenCodex does not provide a remote access service and recommends Tailscale, ZeroTier, Cloudflare Tunnel or a self-hosted VPN instead. It notes that a public address can work but advises against exposing OpenCodex directly to the internet.
Why is the session history empty the first time I open it?
The FAQ attributes this to a slow first load, which is also affected by the speed of the remote LAN connection. It suggests waiting and then refreshing or re-entering the session.
Why are sessions not syncing between OpenCodex and the desktop app?
The README states that OpenCodex and the official desktop each maintain their own session state, so the same underlying data may not be fully in sync in real time. It recommends using OpenCodex alone, locally and remotely, optionally installed as a PWA.
Community notes