With thirty minutes left in my day, I drop a stack of well-defined tickets into Todo, set Amphetamine to keep my laptop awake, and close the lid. By morning, the PRs are open, CI is green, and code review comments are addressed.

I haven't hand-written a PR in months. Clipboard has tripled deploys per engineer. My workflow opens 50+ PRs a day and burns 9.5B tokens a month, over $7,000 at retail API rates, paid for by the Claude Code Team and Codex Pro plans I already have.

In Agents Can't Iterate Against Tests That Lie, I wrote about cutting our end-to-end flake rate from 100% to under 15% so agents had a feedback loop they could trust. Another bottleneck is humans prompting in between the ticket and the PR.

Today, we're open-sourcing the tool that took us out of the middle: groundcrew. It watches a ticket source (default Linear) and farms tickets to local Claude Code and Codex sessions running in sandboxes. We're also releasing clearance, the deny-by-default egress proxy underneath it.

Why local, interactive agents?

Coding agents fall on a spectrum from "remote, fully autonomous" (Devin, Codex Cloud) to "local, interactive" (Claude Code, Codex CLI). The remote end is easier to delegate to. The local end runs on subscription plans you already pay for, and stays steerable: You can drop into any session if agents get stuck. That matters most when you're iterating on new workflows. More on this below.

What does groundcrew do?

groundcrew is an orchestration runner. You point it at a ticket source, label tickets to route them to a coding agent, and it spawns a session per ticket.

The lifecycle for one ticket:

1. crew run --watch polls the ticket source for those in Todo with an agent label (agent-claude, agent-codex, or agent-any).
2. For each new ticket, crew creates a git worktree inside a sandbox and starts a Claude Code or Codex session in a cmux or tmux workspace, passing the ticket description as the prompt.
3. The agent works the ticket and produces an output (e.g., another ticket, a PR).

Three design choices are doing most of the work.

Ticket as control plane. The ticket source is the queue. Adding work means filing a ticket. Routing means changing a label. Stopping work means moving the ticket out of Todo. There's no separate UI to learn and no orchestrator state that can drift from your task tracker.

One worktree per session. Each ticket gets its own git worktree, so agents don't fight over local state, generated files, or the working directory. You can have ten sessions running on the same repo.

Hard stops on usage. Claude Code Team and Codex Pro both have 5-hour and weekly limits. Without limit tracking, a runaway overnight job will exhaust your weekly quota by 9 a.m. and leave you on API rates for the rest of the week. crew tracks both windows and refuses to start new sessions when either is close to depleting.

I've found Codex is the better debugger and reviewer, and Claude Code is the better designer. Running both also keeps us under rate limits (most of the time).

What kinds of tickets work?

50+ PRs a day? At that volume, are humans meaningfully reviewing, or just rubber-stamping?

Most of our changes are scoped with tight feedback loops where review is cheap:

• Flaky test fixes. Run the candidate fix 50 times in a row in CI; if it passes, it's low-risk to merge.
• Dependabot/Renovate dependency update failure. Agents triage and either fix the breakage or close the ticket.
• Stale feature flag cleanup. Once a flag has been at 100% rollout for long enough, agents remove the dead branches.
• Long-tail migrations. We converted 1M lines of JavaScript to TypeScript and used @ts-expect-error for existing violations so strict mode could ship for new code. Each is now a ticket.

PR count is not the goal; it's a side effect of clearing work that used to sit in the backlog because no one had the appetite to do it by hand.

As we gain confidence in our workflows, guardrails, and AI reviewers, we're expanding the changes we're comfortable letting groundcrew handle.

How do tickets route in practice?

The flaky-test workflow from the previous post now runs through groundcrew end-to-end:

1. A Datadog monitor detects a flake and creates a Linear ticket with the agent-codex label and instructions to use the $flaky-test-debugger skill.
2. groundcrew picks up the ticket and starts a Codex session in a worktree. Codex investigates using the custom playwright-reporter-llm output and Datadog APM traces.
3. The session marks the original ticket Done and creates a new ticket with a fix plan for human review.
4. I review the plan in Linear, move approved plans to Todo, and close or ask for more investigation on the rest.
5. groundcrew picks up the approved ticket for another Codex session to implement and open a PR.

Two agents, two ticket lifecycles, one human review step in the middle.

What about review feedback?

Opening the PR is half the job. We open-sourced babysit-pr for the rest.

babysit-pr is an agent-agnostic skill that watches a PR and:

1. Fixes CI failures and merge conflicts. It reproduces the failure locally, identifies the root cause, and pushes a fix.
2. Triages every review comment three ways:
   • Agrees: Pushes the fix and replies with the commit link and a one-line summary.
   • Agrees but defers: Tracks follow-ups so the current PR doesn't bloat.
   • Disagrees: Replies with why.

Without it, every PR still needs us in the loop to chase down review feedback. With it, we review the agent's researched replies to reviewers.

Is this safe?

Local agents in YOLO mode are fast and dangerous. Without isolation, a confused agent can rm -rf outside its working directory, exfiltrate secrets to a pastebin, or push to the wrong remote. We needed a sandbox that was strict by default and transparent to the agent.

clearance combines two layers:

1. Host-OS isolation inherited from agent-safehouse. The agent sees a filesystem view scoped to its worktree and a process namespace that can't reach the host.
2. Deny-by-default HTTP proxy. The agent's network egress goes through a proxy that allows only an allowlisted set of domains, e.g., package registries, the model provider's API, GitHub, Linear, and Datadog. Everything else gets blocked.

groundcrew uses clearance transparently. When groundcrew spawns a session, the agent runs in a clearance sandbox without any special configuration. If the agent attempts to curl an arbitrary domain, it's denied.

clearance is useful on its own if you're running agents locally and want a stronger sandbox than your shell.

What changed in our workflow?

The plan → ship → review → fix loop runs without us in the middle for any ticket we can specify clearly. We've moved up the stack: deciding what to build, writing the rules and feedback loops that keep agents honest, and proving the result.

This isn't autonomy for its own sake. The shape of the work changed. With agents writing the code, the human bottleneck moved to plan quality, verification, and the choice of which problems are worth solving at all.

groundcrew turns a queue of well-specified tickets into open PRs while you sleep. clearance prevents nightmares.

Both projects are MIT-licensed:

• groundcrew
• clearance

Let us know what you build with them.

Thanks

Clayton Winders built the initial version of groundcrew. Thanks also to Paul Baranowski at Instacart, and to George Bezerra, David Huculak, Sarthak Dalabehera, Mike Cook, and Felipe Philipp at Clipboard for early contributions.