Set up the Warp Agent so it returns a change your team can review. Write project rules and pick an agent profile before work, start anything bigger than a small fix with /plan, keep the command denylist on, and review the diff in Warp before merge.
When you need this
- Engineers have started using the Warp Agent and the quality of what comes back varies by person.
- Someone turned on auto-approve to save time and you want to know what it can now run.
- You want one team standard for rules, autonomy, and review across Warp's agent and the CLI agents run inside Warp.
The playbook
Before work: project rules
Where do build commands, test commands, and conventions live?
In practiceAn AGENTS.md at the repository root, with more specific files in subdirectories. The filename must be in capitals, and WARP.md still works for older projects. /init generates a first draft. The most specific file wins over the root file, and both win over global rules in Warp Drive.
Before work: agent profile
Which model and autonomy does this kind of work get?
In practiceA named profile per kind of work, each with a base model and a level per action: Agent decides, Always ask, Always allow, or Never. Add read-only commands to the allowlist and keep rm, curl, wget, and eval on the denylist, which forces a prompt even under Always allow.
During work: plan first
Did anyone read the plan before code changed?
In practice/plan for any change larger than a small fix. The plan opens in an editor and saves each agent revision as a version. Run one phase at a time. A builder rebuilt an ML project in 18 stories with Warp's agent using specs, AGENTS.md, and repository skills. The builder still had to catch a model input bug.
During work: autonomy switch
What happens when someone presses auto-approve?
In practiceRun until completion runs every suggested command until the task ends, and by default it also runs denylisted commands. Turn off the setting that lets auto-approve bypass the denylist, and on Enterprise enforce it from the Admin Panel.
During work: context
Does the agent see the right code and nothing it should not?
In practiceCodebase Context indexes Git-tracked repositories, each worktree separately, and uses .warpindexingignore to skip files. Free indexes 3 codebases, Build and Max 40, and Business 80. Secret Redaction, off by default, masks matching patterns before a request leaves the machine.
Before merge: review
Who checks the change, and against what?
In practiceInteractive code review in Warp, so the agent can act on comments before the change lands. Tests and CI on every change, and a named human reviewer on the pull request. Review comments can also go to Claude Code or another CLI agent running in the same tab.
Questions to settle with each team
- Which repositories have an AGENTS.md, and who keeps it current?
- Which profiles exist, which models do they use, and who can change them?
- Is the denylist bypass turned off for everyone, or only for some?
- Which repeated corrections should become a rule or a skill?
Red flags
- Auto-approve used on a machine with standing production credentials while the denylist bypass is on.
- Allowlist entries that match write or network commands.
- Large diffs merged on a green build with no named human reviewer.
- Secrets pasted into prompts with Secret Redaction off.
Products in this piece
Sources
- Official documentation
- 9
- Public source
- 2
- Warp docs: Rules for agents
- Warp docs: Profiles & Permissions
- Warp docs: Agent planning and execution
- Warp docs: Codebase Context
- Warp docs: Secret Redaction
- Warp docs: Interactive Code Review
- Warp docs: Claude Code in Warp
- Warp docs: Admin Panel for teams
- Warp: Pricing
- Sertan Yamaner (dev.to): Part 1: The Architecture & The Agent, Spec-Driven ML Development With Warp (Apr 14, 2026)
- Jack Herrington (YouTube): Is Warp Code The Best Terminal In 2025? (Sep 8, 2025)