The open repository contains Warp's GUI and TUI client
Warp began as a terminal and now describes itself as an agentic development environment. The client combines a native GUI, a headless TUI, terminal sessions, editor and file surfaces, cloud-synced Drive objects, and agent interfaces. Its built-in agent is one option; Claude Code, Codex, Gemini CLI, and other command-line agents can run inside Warp. That makes it useful to developers who want to supervise several coding sessions without abandoning the shell.
The open-source boundary is the client codebase. Engineering instructions describe connecting it to a separate warp-server over HTTP and WebSocket, including a local-server mode when that service exists. Cloud synchronization and agent services therefore should not be mistaken for features that this checkout alone makes self-hostable. You can inspect, build, and modify the desktop and TUI code, but reproducing every Warp-operated backend is a different requirement.
Two licenses apply to different parts of the client
Warp licenses warpui_core and warpui under MIT. The rest of the repository uses AGPL-3.0. That split gives other projects a permissive path to the UI framework while placing the broader client under copyleft terms. Teams distributing modified builds or connecting modified AGPL code to users over a network should review their obligations with counsel rather than assuming the entire repository carries the MIT license shown for those 2 crates.
The workspace is substantial. Cargo lists the app plus crates for AI, MCP, terminal behavior, completion, editor logic, persistence, cloud objects, GraphQL, isolation, voice input, managed secrets, and multi-agent clients. Native implementations cover macOS, Windows, and Linux, with GUI and TUI front ends sharing core state but using different renderers. A small terminal emulator has fewer boundaries; Warp's value depends on wanting these adjacent development surfaces together.
What happened when we ran it
Our sandbox installed 1,397 Rust packages in 109 seconds. The build then succeeded after 860 seconds. We measured commit e83d07d in an unprivileged container with 3 CPUs and 12 GB of RAM. Before dependencies, the checkout was 388.9 MB with 6,248 files and roughly 1,732,233 source lines. It included 21 CI workflow files, no root Dockerfile, and no top-level tests directory.
The test command failed with exit code 101 after 674 seconds. The last supplied line was a truncated Rust compiler or linker invocation containing several internal libraries. There was no summary naming a failed test, panic, or assertion. We therefore cannot say what broke or how many cases ran. The useful result is narrower: the code built successfully in our container, but the available test step did not pass and its tail was not diagnostic.
Rust tests are not absent merely because there is no tests/ folder. The contributor guide sends unit work through cargo nextest, keeps many tests beside modules, and places user-flow coverage under crates/integration. It also requires manual evidence for nearly every user-visible change, with screenshots for small visual edits and narrated recordings for broader interactions. Contributors should budget for both a long compile cycle and hands-on verification.
Oz shapes issue triage, specifications, and code review
Warp's contribution process gives its Oz agents a formal role. Issues may receive ready-to-spec or ready-to-implement labels. Product and technical specifications define testable behavior and planned code changes before implementation. Oz performs the first pull-request review, and contributors may request /warp-agent-review up to 3 times before escalating to maintainers. Human maintainers still make the project decisions, but automation controls much of the queue's first pass.
That process can make a very busy repository easier to route. It can also feel foreign if you expect to open a patch directly and discuss it with a maintainer. The guide asks contributors to link actionable issues, include tests, provide manual proof, and personally participate in discussion rather than sending an agent to speak for them. Read the workflow before investing in a large change; a technically sound patch can still arrive before the product behavior is settled.
Agent sessions still have visible lifecycle failures
Open issue 15429 reports built-in agent conversations stalling after the response stream detaches from the UI, leaving runs marked in progress until manual interruption. Issue 14960 asks Warp to restore an external CLI-agent session into its pane after application restart instead of returning a bare shell. A related report says restored panes can show a new-conversation interface rather than the previous agent state. These are active reports, not universal behavior, but they affect Warp's main reason to replace a plain terminal.
Terminal input has its own current rough edge. Issue 15580 reports a notification toast taking the Space key while the user is typing, turning git status into gitstatus. Another same-day bug says Project Explorer stays rooted in the original directory after Warp creates and enters a Git worktree. An ordinary terminal has fewer synchronized views to drift apart. Warp buyers should test worktrees, restarts, long agent streams, keyboard focus, and session recovery in their own daily loop.
64,552 stars sit beside a non-product release tag
GitHub showed 64,552 stars and 5,109 combined issues and pull requests. The repository was pushed on August 27, 2026, with bugs and feature requests updated the same day. The latest-release endpoint returned a July 28 tag whose name and description say it temporarily hosts screenshots for pull-request review. That tag is not a meaningful product-version signal, so users should follow Warp's documented stable and preview download channels instead of GitHub's latest-release badge.
Warp is a credible choice for developers who want their terminal to become the cockpit for agents, files, and task state. The packaged build is the right way to test that proposition. The source repository is valuable for inspection and contribution, but 1,397 packages, a 14-minute build, and a failed 674-second test run make casual compilation unattractive. If agent supervision does not improve your actual workflow, Alacritty, WezTerm, or Ghostty will demand less attention.