codexapp: A Browser Bridge for the Codex App UI on Linux, Windows and Termux
🚀 Run Codex Mobile Anywhere: Linux, Windows, or Termux on Android 🚀
At a glance
- What is it?
- codexapp is an npm package that serves the Codex app-server UI over HTTP on port 18923, with an optional cloudflared tunnel on by default and an optional Telegram bot bridge. It is a convenience layer for people who want the Codex desktop experience in a browser, including on Android through Termux, and it inherits the exposure risks of any tool that puts a local agent UI on a reachable URL.
- Who is it for?
- Adopt codexapp if you want the Codex app-server UI reachable from a phone or another machine and you are willing to manage the URL it is published on. Skip it if you need a documented authentication model before exposure, or if you cannot keep a Termux session alive.
- Can I use it commercially?
- Yes. MIT is a permissive licence: you can use, modify and sell software built on it, as long as you keep its copyright and licence notices.
- Is it still maintained?
- Yes. The repository last received commits 112 days ago.
- What is it written in?
- Mainly TypeScript, 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
The gap codexapp fills: a Codex UI you can open from another device
The Codex app-server normally presents itself through a desktop application. codexapp takes that app-server workflow and puts a web UI in front of it, then starts a local HTTP server so you can open the interface in a browser. The README frames it as a lightweight bridge and says you run one command, start a local web server, and open it from your machine or your LAN. The target user is someone who already works with the Codex app but wants the same projects and conversations from a different device. The README's Tailscale section is explicit about this: the author describes viewing the same projects and conversations from a Windows host while working in iPhone Safari. That is the concrete use case, not a general web dashboard. The package is published on npm as codexapp, written in TypeScript, and licensed MIT.
What actually runs when you type npx codexapp
The command starts a web server that listens on port 18923 by default, and the README gives http://localhost:18923 as the address to open. It also starts a cloudflared tunnel by default, running cloudflared tunnel --url http://localhost:<port>. Startup output prints the tunnel URL, a terminal QR code, and a password together. The tunnel is the part worth pausing on. A tunnel URL is reachable from outside your machine by design, which is why the same startup output includes a password. The README does not describe how that password is generated, where it is stored, or how the server checks it on each request. That is the largest documentation gap in the material, and it matters more than any feature listed under the payload heading. If you are not using a provider or gateway that is already authenticated, codexapp runs codex login during startup; the --no-login flag suppresses that step. Two other flags appear in the material: --no-tunnel disables the cloudflared behavior, and --port changes the listening port, as shown in the Tailscale example.
Termux on Android: what the instructions require of the device
The Android path is Termux, not a native app. The README's setup is pkg update && pkg upgrade -y, then pkg install nodejs -y, then npx codexapp. Node 18 or newer is the stated requirement across all three platforms. The Android section then lists four conditions that are not optional in practice. You must keep codexapp running in the current Termux session and not close it. You must disable battery optimization for Termux in Android settings. You must keep the persistent Termux notification enabled so Android is less likely to kill the process. And termux-wake-lock is described as optional but recommended. The README also states plainly what happens when the process dies: if the app is killed, return to Termux and run npx codexapp again. There is no supervisor, no systemd unit, and no restart-on-boot instruction in the material. Treat the Termux route as a foreground process you keep alive, not a service.
The Telegram bridge and its allowlist requirement
The Telegram bridge is the one integration in the material with an explicit security control. You set TELEGRAM_BOT_TOKEN, TELEGRAM_ALLOWED_USER_IDS, and optionally TELEGRAM_DEFAULT_CWD before starting codexapp. The README states that TELEGRAM_ALLOWED_USER_IDS is required for safe access, that only allowlisted Telegram user IDs can use the bridge, and that if no allowed user IDs are configured, incoming Telegram messages are rejected. That default-deny behavior is the right call. The bridge maps a Telegram chat to a Codex thread and forwards messages both ways. Commands include /start, /threads, /newthread, /thread <threadId>, /current, /history, /status, /whoami, and /help. Outgoing assistant messages use Telegram parse_mode=HTML, with an automatic plain-text fallback if HTML delivery fails. To find your user ID, the README says to message the bot and then call the getUpdates endpoint for your token, reading message.from.id from the response. Note the asymmetry: the Telegram path documents an allowlist, while the web UI path documents a password printed in the terminal but not how it is verified.
Project export and import, including the chat history rewrite
Export produces a ZIP from the project or thread menus. The README says the archive includes matching Codex chat JSONL history under .codex-project/chats/. Import restores an exported ZIP from the browser through an Import Project action. The interesting detail is what happens to imported chats: they are rewritten for the destination CODEX_HOME, the project path, and the currently selected provider and model so they can be resumed in the new environment. That rewriting is the feature that makes the round trip useful rather than a file dump, and it is also the part most likely to surprise you if a thread references a model or provider that is not configured on the destination machine. The README is candid about the performance asymmetry: exports stream ZIP bytes with response backpressure handling and skip generated and git-ignored folders, while imports buffer the selected ZIP once because the browser upload arrives as a single file. So import memory use scales with archive size.
Where codexapp is the wrong tool
The Tailscale section contains the most useful caveats in the whole README, and they read like field notes rather than marketing. It says that depending on proxying details, authentication behavior may differ from direct remote access. It notes that conversations created in the web UI may not immediately appear in the Windows app, and that restarting the Windows app may refresh them. It mentions minor mobile Safari CSS issues that do not prevent normal use, and it says HTTPS or a secure context appears to be important on iOS for mobile browser access and for dictation. None of this is disqualifying, but together it means codexapp is not a transparent window onto the desktop app. There is state that does not sync instantly in either direction. If your workflow depends on a conversation appearing in the desktop client the moment you send it from the phone, this will annoy you. If you need a single supported deployment with a documented auth story, a public tunnel started by default is the wrong default for you. And if you cannot keep a foreground process alive on the device, the Termux path will keep dying.
How it compares with reaching the app-server directly
The obvious alternative is to skip codexapp and put the Codex app-server behind your own reverse proxy, or to use the desktop app on each machine. The difference is scope of work. A reverse proxy gives you a transport and leaves the UI, the project picker, the thread mapping, the dictation input, the ZIP export with JSONL history, and the Telegram bridge for you to build or forgo. codexapp ships those as one npm package with a one-command start. The trade is that you accept its defaults, and its default is a cloudflared tunnel. The Tailscale Serve path is the middle ground the README itself recommends for iPhone and iPad: npx codexapp --no-tunnel --port 5900 followed by tailscale serve --bg 5900, then open https://<your-machine>.<your-tailnet>.ts.net. That keeps access inside your tailnet, gives iOS the secure context the README says matters for dictation, and avoids publishing a tunnel URL. If you already run Tailscale, this is strictly less exposure than the default.
Maintenance, release cadence and what to verify before you rely on it
The release list shows v512, v513, and v514 all tagged within roughly two days in May 2026, with the last repository push on 2026-05-26. A cadence that dense suggests active iteration and also suggests that pinning a version is wise if you depend on it; npx codexapp without a version tag will pull whatever is current. Because the package is distributed on npm and run through npx, there is no global install to manage, which lowers the cost of trying it and raises the cost of knowing exactly which build you are running. The README's feature list is long and includes items described as coming from main commits, so the published package and the repository may not be identical at any given moment. The licence is MIT, which permits commercial use and modification; that is a statement about the licence text, not legal advice, and you should read the LICENSE file yourself if the distinction matters to your organization. The concrete thing to verify first is the authentication path for the web UI: start it with npx codexapp --no-tunnel, confirm what the printed password protects and how the server enforces it, and only then decide whether a tunnel or a Tailscale Serve address is acceptable for your network.
Editorial conclusion
Adopt codexapp if you want the Codex app-server UI reachable from a phone or another machine and you are willing to manage the URL it is published on. Skip it if you need a documented authentication model before exposure, or if you cannot keep a Termux session alive. Before relying on it, verify how the startup password is generated and transmitted, then run npx codexapp --no-tunnel --port 5900 and reach it over Tailscale Serve instead of a public tunnel.
Community notes