Warp: MIT for two UI crates, AGPL for the rest of the client

Only the UI framework crates carry a permissive licence

The licensing section is two sentences and the distinction matters more than anything else in this repository. Warp's UI framework, the `warpui_core` and `warpui` crates, is licensed under the MIT licence, with the text in LICENSE-MIT. The rest of the code in the repository is licensed under AGPL v3, in LICENSE-AGPL, and the workspace metadata in Cargo.toml states the licence as `AGPL-3.0-only`.

So the boundary runs through the product rather than around it. If you wanted the terminal's rendering and input layer, that part is permissively granted. If you wanted the terminal itself, the agent, the cloud object layer or the command completion machinery, the grant is copyleft with network use conditions, and you should read the AGPL text and take advice on it rather than rely on this paragraph.

The second detail is in the same file and easy to miss. The workspace package block sets `publish = false`. Nothing in this repository is published to crates.io, so there is no versioned package to depend on and no deprecation policy attached to one. Depending on any Warp crate means pinning a git revision, which is a different maintenance commitment from adding a registry dependency.

The three newest releases are dev builds from one day in June

Look at the release list and the versioning scheme explains itself. The three most recent tags are `v0.2026.06.09.19.54.dev_00`, `v0.2026.06.09.09.21.dev_00` and `v0.2026.06.08.09.48.dev_00`, each titled Dev Release, and all three were published on 2026-06-08 and 2026-06-09. The version string is a date, a time and a dev counter, and the suffix marks the build as a development snapshot rather than a stable one.

The consequence is that the release feed is not a changelog. There is no stable tag in that list to pin, and a version number tells you when the build was cut rather than what changed in it. The last push to the repository was 2026-11-02, almost five months after the newest of those dev builds, so the tags are also well behind the branch. Anyone tracking this project for stability has to make a judgement the repository does not make for them, and anyone tracking it for change has to read commits rather than releases.

A maintainer label is the real gate on your pull request

The contribution flow is the most carefully specified part of the README, and it is not the usual file-an-issue-and-pr template. You are asked to search existing issues first, and the search link is pre-sorted by reactions descending, which makes the visible queue a popularity ranking rather than a priority list. If nothing matches, you file an issue using their templates. Security vulnerabilities go through a private path described in CONTRIBUTING.md rather than the public tracker.

Then a maintainer reviews it and may apply one of two readiness labels. `ready-to-spec` means the design is open and contributors should write the specification. `ready-to-implement` means the design is settled and code pull requests are welcome. Anyone can pick up a labelled issue, and mentioning `@oss-maintainers` is how you ask for a label to be considered at all.

The consequence for a new contributor is that your first contribution is usually a document rather than a diff, and the label is the actual gate rather than the issue existing. It is a good protocol, and it is also a queue you do not control: the default sort is by reactions, so a well-connected contributor's issue surfaces ahead of yours regardless of merit.

The repository's own development is run by agents

The README states that this repository is driven by Warp Factories, described as open, flexible infrastructure for teams to build cloud software factories of their own, defined in code and deployable on any model or harness, with evals, benchmarks and self-improvement built in. The contributions dashboard at build.warp.dev is where you watch thousands of those agents triage issues, write specifications, implement changes and review pull requests, see top contributors and in-flight features, track your own issues with GitHub sign-in, and click into a live agent session running in a web-compiled Warp terminal.

Read that as a fact about both the product and the repository. The tooling the team uses on its own issues is the tooling it is selling, which is unusual and worth taking seriously. It also means a large share of incoming pull requests may be agent-authored, which changes what review has to be for.

The limitation is in the access model. Factories is behind a request for early access rather than something you can install, and the dashboard is a web property rather than a local command. The repository is the one place you can read, so an engineer evaluating Factories is reading about the pitch and reading the code, with no way to run the factory layer locally from what is published here.

OpenAI sponsors the repository, and GPT models power the workflows

A note near the top of the README carries the commercial context plainly: OpenAI is the founding sponsor of the new, open-source Warp repository, and the new agentic management workflows are powered by GPT models. That single sentence tells you who funds the client codebase and which models sit behind the agent features.

The practical consequence is a dependency you cannot audit from the source tree. The Factories layer, the agent that triages issues and the agentic management workflows all route through models you do not host, and the repository shows you the orchestration rather than the inference. For a team with a policy about which model providers touch its issue tracker and its specifications, that is a question the code cannot answer, and the README does not attempt to.

Worth separating from the sponsorship, because they are independent facts: the client is open source, the licence split is real, and the README documents how to build it from a checkout. None of that is affected by who sponsors the work, and none of it tells you what the hosted product costs or what its terms are.

The default build is ten crates out of a much larger workspace

Cargo.toml declares workspace members as `crates/*` and `app`, then lists a `default-members` set of eleven: app, channel_versions, command, editor, graphql, markdown_parser, sum_tree, warpui, warp_completer, warp_terminal and warp_util. A comment above that list explains the omissions, noting that serve-wasm is excluded because it is a helper for serving wasm binaries and not something to compile or run tests against, and integration because it is only used for testing.

So the repository contains many more crates than the default build touches, and the workspace dependency table is long enough to show the shape of the product: `ai` and `ai_types`, `cloud_objects` with separate client, persistence and models crates, `computer_use`, `firebase`, `fuzzy_match`, `handlebars`, `http_client` and `http_server`, `input_classifier`, and more. Any of those can be referenced by path without a version, which is convenient locally and useless to an outside consumer with no published package.

There is a smaller signal in the file listing too. Alongside `.rustfmt.toml`, `.clippy.toml`, `deny.toml` for licence checking and `diesel.toml` for the ORM, a Rust workspace root carries PowerShell analyser settings, `.PSScriptAnalyzerSettings.psd1` and `PSScriptAnalyzerCustomRules.psm1`, which tells you some of the tooling around the build is written in PowerShell.

Warp Server Framework is a different project that happens to share the name

The README calls out the open source dependencies that helped get Warp off the ground, and the list names Tokio, NuShell, the Fig Completion Specs, Alacritty, Hyper, FontKit, Core-foundation and Smol among others.

One entry will send you somewhere unexpected. The Warp Server Framework is listed as a dependency and it links to a different repository entirely, a Rust web framework that shares the terminal's name. If you go looking for Warp's terminal code in that crate, or if you search a crate registry for warp and land there first, you will be reading about an HTTP framework rather than an agentic development environment. The two names collide often enough that it is worth knowing before you start.

The build itself is three scripts, and they are the whole local setup story:

./script/bootstrap   # platform-specific setup
./script/run         # build and run Warp
./script/presubmit   # fmt, clippy, and tests

AGENTS.md holds the full engineering guide including coding style, testing and platform notes, and there is a Preview build linked for testing experimental features before they reach a stable channel.

Editorial conclusion

Warp is a real open-source terminal rather than a closed product with a public readme, and the engineering around it is unusually legible: three scripts to build it, an AGENTS.md for the conventions, a security reporting path, and a contribution protocol that tells you exactly which stage your issue is at. Two things decide whether you can actually use it. The permissive licence covers two crates and not the terminal you would want to embed, and no crate is published, so any dependency is a git reference you have to track yourself. And the release feed offers no stable tag, since the three most recent releases are calendar-versioned dev builds from two days in June 2026. Before you build on it, verify three things: which crates you actually need and under which licence, what your presubmit run costs on a machine that only builds the eleven default members, and whether a labelled issue is genuinely open before you write the spec.

Frequently asked questions

Official sources

1. Official documentation
2. Official README
3. Project repository
4. Release notes