Warp Open Source: A Terminal Built for Agents to Write

The Open-Source Release

Warp shipped as a closed-source product for years before the April 2026 open-source release. The note pinned at the top of the README is direct: OpenAI is the founding sponsor of the new open-source repository, and the agentic management workflows are powered by GPT models. The application code is AGPL-3.0; the warpui_core and warpui UI-framework crates are MIT, which lets that work be reused outside the terminal.

The repository is large. 60-plus workspace crates, 2,900 lines in app/src/lib.rs alone, custom WGSL shaders, platform-specific Metal renderers, embedded shell bootstrap scripts for zsh, bash, fish, and PowerShell. None of this was written for the open-source release. What was added for it is the agent-readable layer on top.

The Agent-First Repository

Three directories at the root signal the design intent: .agents/, .warp/, and .claude/. .agents/skills/ contains twenty kebab-case directories, each with a SKILL.md. The frontmatter is YAML with two required fields, name and description. The description is required to begin with an action verb and include both what the skill does and when to use it, because that string is what an agent harness uses to decide whether to load the skill at all.

The skills cover the contribution lifecycle: write-product-spec, write-tech-spec, spec-driven-implementation, implement-specs, add-feature-flag, rust-unit-tests, warp-integration-test, create-pr, review-pr, review-pr-local, fix-errors, resolve-merge-conflicts, diagnose-ci-failures. Two are about issue management (triage-issue-local, dedupe-issue-local). One is meta (update-skill) and documents how to write the others.

.claude/skills is a symlink to .agents/skills. .warp/skills/ contains skills that are branch-specific or developer-machine-specific (the only one shipped at this commit is integration-test-video). .mcp.json wires the GitHub MCP server. WARP.md at the root is the engineering guide that any agent landing in the repo reads first.

Specs as Agent Context

The specs/ directory at the pinned commit holds 142 ticket-named directories, each with a product.md and a tech.md. The two-spec pattern is the contribution model. A product spec defines testable behavior invariants from the user's point of view and stays out of implementation detail. A tech spec is grounded in this codebase: it requires a Context section listing relevant files with line numbers, a Proposed changes section, and a Testing and validation section that ties each invariant from the product spec to a verification plan.

Reading specs/GH408/tech.md shows the format in action. The Relevant code section names app/src/terminal/input/slash_commands/mod.rs (445-450) as the handler that needs to change, app/src/search/command_palette/files/data_source.rs:196 as the existing pattern to follow, and app/src/terminal/input_test.rs (2553-2596) as the existing test to extend. An agent that reads this spec has been handed the diff frame before writing a single line.

The directory naming is split. Older specs use specs/APP-<ticket>/ for Linear ticket numbers; the open-source contribution flow uses specs/GH<issue>/ for GitHub issue numbers. Both shapes coexist and are documented in CONTRIBUTING.md and the spec-driven-implementation skill.

Oz, Readiness, and the Review Flow

The contribution flow is unusual because much of it is automated. Bug reports are implicitly ready-to-implement once triaged. Feature requests get a ready-to-spec label first, requiring a spec PR before any code is written. ready-to-implement means a code PR is welcome. needs-mocks means design work is still pending.

When a PR opens, Oz (Warp's review agent, available as a separate product at oz.warp.dev) is auto-assigned and writes the first review. Only after Oz approves does a Warp team subject-matter expert get auto-assigned. Contributors do not request human reviewers manually. After pushing fixes, contributors comment /oz-review to request a re-review, up to three times per PR. Past that, mentioning @oss-maintainers escalates to the team.

The CONTRIBUTING.md guidance is also direct about which agents work: "any coding agent". Warp's built-in agent, Claude Code, Codex, Gemini CLI. The repository ships agent-readable context (the skills, the specs, WARP.md) that any harness supporting these formats can read. Mentioning @oss-maintainers on a ready issue can also request that an Oz cloud agent implement it for free on complimentary credits.

What This Means for Reading the Code

The Architecture tour walks the engineering shape: workspace, async runtime, GPU text rendering, font rasterization, shell integration via private OSC sequences, the typed IPC, and the build scripts. The Agent Skills tour zooms into the agent-facing surface: .agents/skills/, the SKILL.md format, the spec directory, the editor and agent affordances, and the contribution flow.

If you came to learn how a modern Rust terminal is built, read the Architecture tour. If you came because the agent-first repository structure is the interesting story, read the Agent Skills tour, then copy the patterns into your own repo. The core moves are small: a directory of skill files with structured frontmatter, a specs directory anchored to issues, a WARP.md or AGENTS.md at the root, and a contribution flow that puts an automated reviewer in front of every PR. Everything else is choice of harness.