Warren: a control plane for coding agent runs on your own hardware
Run coding agents like infrastructure, not terminal sessions. Warren manages isolation, lifecycle, spend, recovery, and Git delivery on compute you control.
At a glance
- What is it?
- Warren wraps coding-agent runs in a lifecycle, a sandbox, a spend cap and a Git delivery step. It fits one operator or a small trusted team, and its own README says where the model stops.
- Who is it for?
- Adopt Warren if you are one operator or a small trusted team that already runs coding agents and wants the runs, credentials and history on compute you control. Do not adopt it if you need named users, per-user attribution or RBAC: the README states the current boundary is one deployment, one bearer credential, no RBAC.
- 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 1 day 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 problem: an agent run that outlives your terminal
A coding agent started in a terminal is tied to the terminal. Close the laptop and the run is gone. The context, the diff and the spend record go with it. Warren's README frames the change of state directly: the project becomes useful when an agent run stops being a terminal session and starts being a workload, meaning a run that may need to continue unattended, repeat on a schedule, survive failure, or become visible to someone besides the person who started it.
The intended user is narrow and stated. Warren fits individual operators and small, trusted teams that already use coding agents and want the runs off a developer terminal, especially when code, model credentials, compute and run history must remain on infrastructure the operator controls. That last clause is the real differentiator. If your reason for using an agent is that someone else runs the box, Warren is not aimed at you.
What Warren owns between dispatch and merge
The README lists seven things Warren takes responsibility for, and the list is the architecture. Workspace: each run starts from a fresh worktree or clone on its own branch. Isolation: the run stays inside a sandbox boundary the operator chooses for the deployment. Lifecycle: dispatch, monitoring, cancellation, finalization, cleanup. Control: live event streams, steering that reaches supported harnesses, spend caps that hold during execution. Recovery: watchdogs reconcile lost processes and pods, and finalization salvages work before teardown when possible. Git delivery: agents commit, and Warren manages Git credentials, branch construction, push and configured PR creation. History: run state, events, cost, token use and outcomes persist behind one HTTP API, CLI and UI.
The data flow is drawn in the README as a straight line. A repository plus a task produces an isolated agent workload. That workload emits live events, is bounded by spend and concurrency limits, accepts steering and cancellation, and goes through recovery and cleanup. The output is a pushed branch, and optionally a pull request. The README calls the pushed workspace branch the core guarantee, with PR creation, tracker updates and previews as project settings layered on top. That ordering matters: if you only want the branch, the rest is optional configuration.
Harnesses, runtimes and the adapter seam
Warren separates two concepts that are often blurred. A harness is the coding-agent process Warren drives. A runtime is the place where that workload runs. The run model supports any harness with a Warren runtime adapter, and the current distribution includes adapters for Pi and Claude Code. Agent roles such as planner, healer and PR fixer sit above the harnesses and compose prompts and policy on top of them.
Three runtime providers implement the same lifecycle, and the README gives a partial topology table. `local` uses `bwrap` on Linux and `sandbox-exec` on macOS, and is described as best for one host. `docker` uses a sibling container and is listed for Docker hosts. The third provider is cut off in the supplied material, so I cannot describe it. What is clear is the selection rule: a casual install never picks a provider, because `warren up` detects the machine and picks for you, while operators choose explicitly. That split is sensible for onboarding and slightly uncomfortable for anyone who wants to know exactly what boundary they got. The UI does not appear to surface the choice, so check it after the first boot.
Getting it running: two commands and one credential
The quickstart is two commands on a fresh macOS or Linux machine. First `curl -fsSL https://warren.run/install | sh`, which puts Bun and the `warren` CLI on your PATH when they are missing. Then `warren up`, which detects the sandbox runtime for the machine, asks for the one credential it still needs, and boots the server. The browser opens already logged in, and the UI walks through connecting GitHub, picking a repository and dispatching a prefilled starter run.
State lives under `~/.warren/`. Stopping the server is Ctrl-C, and restarting it is `warren up` again. The README points to `docs/quickstart.md` for the full walkthrough, including a subscription-versus-API-key choice that the top-level README does not resolve. If you are past the casual stage, the Operators section is the relevant one: deployments that serve a team, run in Docker or a cluster, or need explicit credentials start there, and the runtime topology table is the decision point. The shipped forge speaks GitHub through a GitHub App by default, or a static token for operator and CI paths.
The trust boundary is one credential wide
This is the limitation the README states most plainly, and it deserves to be read before anything else. One deployment serves one operator or a trusted team. One bearer credential guards the operator surface. Warren has no named users, no RBAC and no per-user attribution. Warren is self-hosted software, not a hosted SaaS.
The practical consequence is that the blast radius of a leaked credential is the whole deployment: every run, every stored event, every cost record, and the Git credentials Warren holds for delivery. Anyone who needs an audit trail that distinguishes Alice's dispatch from Bob's cannot get it from this system today. The README says so rather than implying otherwise, and it points at SECURITY.md for the full threat model and ROADMAP.md for future work. Treat the single-credential design as a boundary you accept, not a gap you patch with process. If your organization requires per-user attribution, that requirement is not satisfied by configuration here.
A second, smaller constraint sits in the recovery story. Watchdogs reconcile lost processes and pods, and finalization salvages work before teardown when possible. The phrase when possible is doing real work. Recovery is best-effort by the project's own description, so a run that dies mid-edit may still lose uncommitted state. The pushed branch is the guarantee, not the in-progress working tree.
Where a plain sandbox runner or a hosted agent service differs
Two adjacent approaches are worth comparing, because the difference is structural rather than feature-level.
A general sandbox runner such as Docker on its own gives you the isolation boundary and nothing above it. You get a container, and you own dispatch, retry, spend accounting, event streaming, branch construction and push. The `docker` runtime provider in Warren uses a sibling container, so the isolation layer is comparable, but Warren adds the lifecycle, the spend caps, the event stream and the Git delivery on top. If your runs are short, interactive and rare, that added layer is overhead you will not use.
A hosted agent service, by contrast, gives you the lifecycle and the UI but takes the compute, the credentials and the run history out of your hands. Warren's README states its own position against that trade: it is self-hosted software, and it is especially useful when code, model credentials, compute and run history must remain on infrastructure the operator controls. The cost of that choice is that you run the server, you hold the GitHub App or static token, and you own the upgrade path. There is no vendor to call when a watchdog fails to reconcile a pod.
Release cadence and what upgrading costs you
The release history in the supplied material shows v0.18.0, v0.19.0 and v0.19.1 landing within roughly three weeks of each other, with the most recent push to main on 2026-09-10. That is a fast minor-version cadence for a pre-1.0 project, which tells you two things. Expect the operator surface to move, and expect to read release notes before upgrading a deployment that a team depends on.
The mechanics of an upgrade are not spelled out in the README. State is under `~/.warren/`, and the install script manages the Bun runtime and the `warren` CLI, so the plausible path is re-running the installer and then `warren up`. I cannot confirm from the supplied material whether there is a migration step for stored run state, whether the HTTP API is versioned, or whether downgrades are supported. Those are the questions to answer from `docs/` and the release notes before you put a team on one instance.
On licensing, the repository is MIT, which permits commercial and private use and modification. That is permissive, and it also means no warranty and no obligation on the maintainer to keep the operator surface stable. This is a description of the licence identifier, not legal advice; read LICENSE and SECURITY.md yourself if the deployment touches regulated data.
Who should run Warren, and what to check first
Warren is aimed at a specific shape of user: one operator, or a small trusted team, already using coding agents, who wants runs off a developer terminal and wants the code, model credentials, compute and run history on hardware they control. The two-command install and the `warren up` auto-detection lower the entry cost enough that trying it on a spare machine is reasonable.
It is the wrong tool in three cases. If you need named users, RBAC or per-user attribution, the README rules it out today. If you want someone else to operate the control plane, this is self-hosted software by design. If your agent usage is occasional and interactive, the lifecycle, spend and recovery machinery is weight you will not amortize.
Before dispatching anything that matters, verify three things. First, which runtime provider `warren up` selected on your machine and whether that boundary matches your threat model, since the casual path chooses for you. Second, which forge path your deployment uses, the GitHub App or the static token, because that determines what the single bearer credential can reach. Third, read SECURITY.md against your own trust boundary rather than against the README's summary of it. The pushed workspace branch is the contract Warren makes; everything past that is project settings you configure and therefore own.
Editorial conclusion
Adopt Warren if you are one operator or a small trusted team that already runs coding agents and wants the runs, credentials and history on compute you control. Do not adopt it if you need named users, per-user attribution or RBAC: the README states the current boundary is one deployment, one bearer credential, no RBAC. Before dispatching real work, verify which runtime provider `warren up` selected on your machine, confirm the GitHub App versus static token path your deployment uses, and read SECURITY.md against your own trust boundary.
Community notes