Warp Goes Open Source: AGPL Client, MIT UI Framework, and a New `settings.toml`

Warp open-sourced its client on April 27, 2026, with changelog entry v0.2026.04.27.15.32 leading with "Warp is now open source" and a separate launch post on the Warp blog the next day. The repository at github.com/warpdotdev/warp is the actual Rust client codebase -- not an issues placeholder -- with the warpui_core and warpui UI framework crates under MIT and the rest of the code under AGPL v3. The same release ships a new TOML settings file editable from the settings page or by asking Warp's built-in agent to update it. Warp's server infrastructure stays closed-source, and OpenAI is the founding sponsor of the effort.

For background on Warp's positioning as an Agentic Development Environment, see our deeper writeup of Warp's universal agent support; the open-source move is the next layer underneath that thesis.

Key Takeaways

• What: Warp's client is open source as of changelog v0.2026.04.27.15.32, announced on the Warp blog April 28, 2026.
• Where: github.com/warpdotdev/warp, roughly 98% Rust, with app/, crates/, script/, docker/, and specs/ directories present.
• License split: warpui_core and warpui crates under MIT; remaining code under AGPL v3.
• Server: Still closed-source. The open-source release is the client.
• New settings model: A TOML settings file you can open from the settings page or have Warp's agent edit for you.
• Sponsor: OpenAI is the founding sponsor of the open-source effort.
• What did not change: Universal agent support for Claude Code, Codex, Gemini CLI, and OpenCode -- those still work the same way they did before this release.

What Actually Shipped on April 27

The Warp changelog entry for v0.2026.04.27.15.32 leads with two user-visible items:

• "Warp is now open source." This is the headline claim, with the codebase published at github.com/warpdotdev/warp.
• TOML settings file. Per the changelog: "Warp's configuration now lives in a TOML settings file. Access the file from the settings page or ask Warp's agent to update settings for you."

The same changelog batch also includes a number of smaller quality-of-life changes that are easy to miss but worth knowing if you live in Warp:

• A setting to disable suggested rules
• A new /feedback slash command
• oz run get and oz run list now support JSON output with --jq filtering
• Middle-click closes vertical tabs (matching horizontal tab behavior)
• Slash commands available even when AI is disabled
• Network log viewer opens as an in-app read-only pane (50-item buffer) instead of writing to disk
• A "Check now" button on long-running commands that delivers fresh agent snapshots
• The /feedback skill supports screenshot attachments with auto-captioning

The pattern across the smaller changes is "make Warp feel more like a power-user tool you can drive without the GUI." TOML settings is the headline of that pattern. The open-source release is the structural change that makes the rest of it inspectable.

How the License Split Actually Works

The license picture has two layers, and the GitHub repository is the source of truth for both:

The MIT layer is deliberate. Warp explicitly calls out the warpui crates as the piece they want other projects to lean on -- a Rust UI framework born from building a modern terminal is a reusable artifact in its own right. The AGPL v3 layer is the rest of the client. AGPL v3 specifically extends the copyleft to network use: if you fork Warp's client code, modify it, and offer it as a hosted service, you have to publish your modifications. For most developers running Warp locally, AGPL v3 behaves like GPL v3 -- you can read it, fork it, run it, and patch it.

The server side -- where Warp's agent orchestration, cloud features, and account infrastructure live -- is not in the repository. Warp's launch blog is explicit about this: "the server portion of Warp will remain closed-source for now." The open-source release is a client-side commitment, not a full-stack one.

What settings.toml Actually Lets You Do

The TOML settings file is the more underrated half of the release. The changelog's framing -- "ask Warp's agent to update settings for you" -- is the part that matters in practice. A few implications:

• Programmatic configuration. A TOML file is something you can check into a dotfiles repo, sync across machines, or generate from a setup script. The previous GUI-only configuration story made every new device a manual click-through.
• Agent-edited configuration. Warp's built-in agent can read and write the settings file. That turns "I want my prompt to look like this" into a single conversational request rather than a tour through preference panes.
• Portability and audit. A plain-text settings file is grep-able, diff-able, and reviewable. For team-managed terminals or compliance-sensitive setups, that is a real shift over an opaque GUI store.

The exact schema, location, and supported keys are best read from the Warp docs at the time you adopt the file -- early TOML schemas iterate fast, and the changelog wording suggests Warp is leaning into the agent-edited pattern over a hand-maintained config-as-source-of-truth pattern.

Why This Matters For Coding-Agent Users

The pure marketing layer of "Warp is open source" is the kind of headline that is true and not necessarily load-bearing. The actual reason this release matters for developers running coding agents in Warp is more specific:

• You can audit the terminal you trust with credentials and prompts. Warp is the wrapper around Claude Code, Codex, Gemini CLI, and OpenCode for a growing number of teams. The terminal sees every prompt, every tool call, and the credentials those agents use. AGPL v3 source means that wrapper is now inspectable. For security-sensitive shops, that is the difference between "we approved Warp" and "we read Warp's process model and approved it."
• You can fork Warp's UI framework into your own tools. The MIT-licensed warpui crates are a native Rust UI framework hardened by being the surface of a real shipped product. That is unusual -- most native UI frameworks in Rust are toy-sized. If you build developer tooling, this is a real reusable asset.
• You can build on Warp's primitives instead of around them. Slash commands, the input editor, the per-pane status badges, the vertical tabs surface -- all of those are now patchable. Custom workflows that previously required external tools chained around Warp can now be in-tree forks.
• You can read Warp's agent-runtime code. Warp's "Oz" agents -- the cloud-side orchestration mentioned in the launch blog -- are not in the open-source release, but the client-side hooks the local agent uses are. For developers building their own agent tooling, that is a non-trivial reference implementation of "how a terminal that hosts coding agents talks to them."

Practical Caveats

A few honest caveats on how to read the announcement, because the gap between "open source" as a tagline and "open source" as a developer experience is where most projects accumulate caveats:

• Not every client component may be in the first cut. The repository README itself is cautious: it talks about open-sourcing the Rust UI framework "first, and then parts and potentially all of our client codebase." That is a softer commitment than the changelog headline suggests. Build-from-source completeness depends on what is actually checked into the repo when you read it.
• "Sponsored by OpenAI" is more than a credit line. OpenAI being the founding sponsor and the launch post quoting an OpenAI engineering lead is a clear signal about where this project's commercial gravity sits. That is not a problem -- it is context. If you are picking a terminal partly on its independence story, it is worth knowing.
• The server stays closed. Anything cloud-side -- account, sync, hosted Oz orchestration, billing -- is not in the repo and is not on the AGPL v3 track. Self-hosting Warp end-to-end is not what was announced.
• AGPL v3 has a network-use clause. If you fork the AGPL v3 portion and run it as a hosted service for others, the AGPL requires you to publish your modifications. For internal-only or local use, that does not bind you. For commercial hosting on top of forked Warp, it does. Have your legal team look at it before you build a product on a Warp fork.
• The blog announcement was published April 28, 2026. The changelog timestamp on the release is April 27. The discrepancy is not meaningful -- the release shipped on the 27th and the marketing post followed on the 28th -- but if you are reconciling timelines, that is the order.

How This Fits Into the 2026 Picture

Warp's open-source move is the second large client-side opening in the AI coding agent space this year. Cursor remains closed; Codex CLI is open-source already; Claude Code is closed; Gemini CLI is open. With Warp now in the open camp at the client level, the terminal-and-agent stack increasingly looks like a mix of open clients (Codex CLI, Gemini CLI, Warp) over closed cloud services (Anthropic, OpenAI, Google). That asymmetry is becoming the dominant shape of the agent toolchain, and Warp's release reinforces it rather than disrupts it.

For where Warp sits versus other "agent works while you are away" surfaces -- routines, scheduled agents, hosted threads -- our comparison of Claude Code Routines vs. Cursor Automations is the right anchor. Warp's open-source release does not change Warp's positioning relative to those tools, but it does change what teams can credibly do with Warp inside their own infrastructure.

The canonical references for this release are the Warp changelog (durable source for what shipped), the Warp open-source announcement post (sponsor and license framing), and the warpdotdev/warp repository on GitHub (the actual code and license files).