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

> The terminal is open source, and the licence boundary runs straight through it. Two crates are MIT, everything else is AGPL-3.0-only, nothing is published to a registry, and the three newest releases are dev builds from a single day in June. The build-from-source path is three shell scripts.

**warpdotdev/warp** — Warp is a terminal-based development environment with command search, reusable workflows, team sharing, and coding-agent support.

- Repository: https://github.com/warpdotdev/warp
- Website: https://warp.dev
- Stars: 65,162 · Forks: 5,587
- Language: Rust
- License: AGPL-3.0
- Published: 2026-08-04 · Updated: 2026-08-18 · Language: en
- Canonical page: https://hysenlabs.com/projects/warpdotdev-warp

## 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-09-25, more than three 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 genuinely open, the licence split is real, and the build scripts work 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 ten: 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 is worth reading as architecture. Tokio for async work, NuShell for structured shell behaviour, the Fig Completion Specs for command completion, Alacritty for terminal rendering, Hyper for HTTP, FontKit and Core-foundation for text and platform integration, and Smol for small async tasks.

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:

```bash
./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.

## 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 one day 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 ten default members, and whether a labelled issue is genuinely open before you write the spec.

## FAQ

### What is Warp dev?

Warp describes itself as an agentic development environment born out of the terminal, and its client codebase is open source in Rust. You can use Warp's built-in coding agent or bring your own CLI agent, with Claude Code, Codex and Gemini CLI named as examples.

### How do I install Warp?

Download Warp from warp.dev/download and follow the platform-specific instructions in the documentation at docs.warp.dev. To build and run it from source instead, the repository provides `./script/bootstrap` for platform-specific setup, `./script/run` to build and run, and `./script/presubmit` for formatting, clippy and tests.

### Is Warp AI free to use?

The repository does not address pricing for the hosted product. What it does set out is the licensing of the client: the `warpui_core` and `warpui` crates are MIT, everything else is AGPL v3, and Cargo.toml marks the workspace `publish = false`, so no crate is published to a registry.

### Is Warp better than claude code?

The README does not compare them, and it positions them as complementary rather than competing. Warp's built-in coding agent is one option, and bringing your own CLI agent, with Claude Code named first among the examples, is the other.

## Sources

- [Official documentation](https://warp.dev)
- [Official README](https://github.com/warpdotdev/warp#readme)
- [Project repository](https://github.com/warpdotdev/warp)
- [Release notes](https://github.com/warpdotdev/warp/releases)

---

Hysen Labs editorial analysis, written from the project's own repository and release notes. Cite the canonical page: https://hysenlabs.com/projects/warpdotdev-warp