Codexia: a Tauri desktop shell for Codex CLI and Claude Code sessions

The problem Codexia is aimed at

Running Codex CLI or Claude Code in a terminal works until you need two of them at once, or you want a job to run every morning without you typing the prompt again. Codexia's README frames the project as a "Lightweight Agent Workstation" that puts several agent CLIs, a scheduler, git worktree management and a prompt notepad into one workspace. The target user is someone who already has the CLIs installed and wants a persistent surface around them rather than a replacement for them. The Requirements section lists Codex CLI and Claude Code CLI as prerequisites, so Codexia is a client, not a bundled runtime. If you have not installed either CLI, this is not the tool to start with.

What sits between the UI and the agent process

The architecture note in the README is specific enough to reason about. The desktop backend is Tauri v2 with Rust under src-tauri/src/, and the frontend is React, TypeScript, Zustand and shadcn/ui under src/. Agent runtime for Codex goes through the app-server JSON-RPC integration, which is what drives session and turn lifecycle. Claude Code is reached through a Rust SDK integration, and third-party agents connect over the Agent Client Protocol, with the README stating that those sessions persist across restarts and that tool calls render live in the thread. A separate headless backend exists: an Axum web server in web/, with a WebSocket broadcast stream at /ws for browser clients. That means there are two backends to think about, not one. The named entry points are src-tauri/src/lib.rs for desktop commands and state, web/src/server_web.rs for headless startup, src-tauri/src/web/router.rs for the HTTP route surface, and src/services/tauri/ as the frontend invoke layer.

The HTTP surface, and what it implies about exposure

In web or headless mode Codexia exposes a browser-accessible API. The README lists the route groups: GET /health and GET /ws for health and streaming; /api/codex/thread/*, /api/codex/turn/*, /api/codex/model/* and /api/codex/approval/* for Codex lifecycle; /api/automation/* for creating, updating, listing, running, pausing and deleting scheduled jobs; /api/filesystem/*, /api/git/* and /api/terminal/* for files, git and terminal access; /api/cc/* for Claude integration; and /api/notes/* plus /api/codex/usage/token for notes and token usage. Read that list again with a hostile eye. A route group named /api/terminal/* and one named /api/filesystem/* are exactly the surfaces you do not want reachable from an untrusted network. The README does not state an authentication model for the headless server in the material available here, and it does not state a default bind address. Treat that as the first thing to check in docs/WEB_SERVER.md before running headless mode anywhere but a local machine. The remote control feature, including iOS, is built on this server, so the convenience and the exposure are the same feature.

Installing it and starting a first session

The README gives three install paths. On macOS, brew install --cask codexia. On Windows, scoop bucket add milisp https://github.com/milisp/scoop-bucket followed by scoop install codexia. Prebuilt releases for macOS, Linux and Windows are on the GitHub Releases page, and Windows additionally ships a portable archive named codexia_<version>_x64_portable.zip that runs without installing. The Quick Start is four steps: launch Codexia, add your project directory, enter a prompt and start an agent session, then create an Agent Task Scheduler job for recurring workflows. There is no configuration file shown in the README, so setup appears to be UI-driven. Contributors adding endpoints are told to put handlers under ./web/src/handlers/, register routes in ./web/src/router.rs, and add matching frontend client calls in src/services/tauri/. That three-place pattern is worth knowing if you plan to fork.

Scheduling, worktrees and the multi-agent case

The two features that distinguish Codexia from a plain chat window are the task scheduler and git worktree management. The scheduler is exposed both in the UI and over /api/automation/*, which means a recurring job can be created by hand or by a script hitting the API. Git worktrees matter because two agents editing the same checkout will collide; separate worktrees give each session its own working directory while sharing one repository. The README does not describe how Codexia assigns a worktree to a session, whether it creates one automatically per task or whether you point a session at an existing worktree. That is a gap. If you are evaluating this for parallel agent runs, the worktree-to-session binding is the first thing to test, because it determines whether the feature prevents conflicts or merely displays them. The ACP client is the other half of the multi-agent story: any agent speaking the Agent Client Protocol can be attached, and the README claims those sessions survive a restart.

Security claims worth reading carefully

The Security section makes four statements: agents run in separate processes, file and network access are configurable per agent, all data stays on your machine, and the code is open source. The first two are design claims, not guarantees. Process isolation keeps one agent from corrupting another's memory, but it does not constrain what an agent does to your filesystem once it has a shell, and the README's own API list includes /api/terminal/*. The per-agent permission control is the mechanism that matters, and the README does not document its defaults. Local storage is a real property of the desktop build, but the moment you enable the headless web server for remote control, the boundary moves: the data still lives on your machine, while the interface to it is now a network service. Open source is a property, not a security control, and the README offers no audit, no threat model and no disclosure policy in the supplied material.

Where Codexia is the wrong tool, and what to use instead

If your agents are triggered by CI, by a git hook, or by a script in a pipeline, Codexia adds a desktop process and a second HTTP surface to maintain without adding capability. The same applies if you work on a remote box over SSH and want the agent next to the code: a terminal multiplexer plus the CLI is fewer moving parts. For the terminal-first case, the README itself points at keke, described as a local terminal coding agent with zero vendor lock-in that works with subscriptions, API keys or self-hosted models and speaks ACP. The difference in approach is the shape of the thing: keke is a terminal agent that other clients can attach to over ACP, while Codexia is a client that attaches to agents. If you want one agent with a stable interface, keke is the closer fit. If you want several agents, a scheduler and a worktree view in one window, Codexia is the closer fit. The README also lists two community forks, jeremiahodom/codex-ui with a Node.js backend using API and SSE, and nuno5645/codexia with reasoning and token count events, which suggests the web layer is the part people most want to change.

Maintenance cost and the MIT licence

Codexia is MIT licensed, which permits commercial use, modification and redistribution provided the copyright notice and permission notice are retained. That is the whole of the licence implication here; anything beyond it depends on your jurisdiction and is a question for a lawyer, not for this article. The maintenance picture is less settled. The release cadence visible in the supplied material is dense, with v0.50.0, v0.50.1 and v0.50.2 all landing within a three-day window in September 2026. Frequent patch releases can mean active maintenance or a fast-moving surface; the version number alone does not tell you which. What you can infer is coupling: Codexia depends on the Codex CLI's app-server JSON-RPC interface and on a Claude agent Rust SDK, and the README's own contributor instructions require touching three files for every new endpoint. When the upstream app-server contract shifts, the integration in src-tauri/src/ is what breaks, and the desktop and headless backends both need to follow. Budget for tracking upstream releases rather than for a set-and-forget install, and pin the CLI versions you test against.

Editorial conclusion

Adopt Codexia if you already run Codex CLI or Claude Code from a terminal and want session persistence, a worktree panel and a scheduler in one window, and if you are willing to check the permission settings before letting an agent touch a real repository. Skip it if your agents are invoked from CI or from scripts, where a GUI adds nothing and the headless server is a second interface to keep patched. Before committing, read docs/WEB_SERVER.md and confirm what the headless mode binds to by default, then verify that your Codex CLI version matches the app-server JSON-RPC contract Codexia expects.

Official sources

1. License: MIT
2. milisp/codexia on GitHub
3. Project website
4. README
5. Releases