Where to Host a Coding Agent: The Case for CodeBuild
I moved an autonomous coding worker onto AWS CodeBuild. Here's the disk, timeout, and fail-loud reasoning that made it beat a container runtime.
Where to Host a Coding Agent: The Case for CodeBuild
"Where should this thing run?" turns out to be the most consequential question you answer when you build an autonomous coding agent — more consequential than the model, the prompt, or the tool wiring. Get it wrong and you'll spend weeks fighting the host instead of shipping features. I spent those weeks. This is what I learned, and why my autonomous coding worker now runs on AWS CodeBuild .
First, notice you have two different workloads
The phrase "run the agent" hides a fork in the road. In my setup, "Claude Code" is really two workloads with almost nothing in common:
| Interactive chat | Autonomous coding worker |
|---|---|---|
Shape | Human in the loop, token-streaming | Unattended batch job, minutes to hours |
Trigger | A person typing | An issue-comment mention |
Output | A conversation | A draft pull request |
Streaming need | Token-level (UX matters) | Event-level (nobody's watching live) |
These want different homes. The chat path genuinely benefits from a low-latency, session-oriented container runtime — that's what token streaming is for, and it's why I keep it on Amazon Bedrock AgentCore Runtime (I wrote up that hosting pattern in Host Claude Code on Bedrock AgentCore with the AgentCoreApplication CDK Construct ).
The batch coding worker is the one this post is about. It clones a repo, runs the
claude CLI unattended for a while, and pushes a PR. No human is watching the tokens scroll by. And that changes everything about where it should live.The candidates for a batch coding worker
Before landing on CodeBuild, I ran the worker in most of the obvious places:
- My laptop. Fine until you close the lid. I stopped doing this early on — an unattended job that dies when your Wi-Fi drops isn't unattended.
- An always-on EC2 box. This works well, and I still reach for it for interactive sessions I want to let run to completion . The downside for a fleet of dispatched jobs: you own the instance, the scaling, and the idle cost.
- Lambda. The 15-minute ceiling rules it out the moment a task needs a real
pnpm installand a multi-file refactor.
- A container runtime (AgentCore Runtime). Where the worker started. It's a great home for the chat path — and, it turned out, the wrong home for the batch worker.
The failure modes I hit on the container runtime are the clearest argument for what a batch coding worker actually needs. Here are the three that mattered most.
What broke — three failure modes
1. The disk fills, and the agent wedges silently
The runtime gave each session a 1 GB
/mnt/workspace volume. On a real monorepo, a routine pnpm install plus a build fills that in about 25 minutes. Once it's full, every file write fails — and the agent doesn't crash. It loops silently on failed writes for the rest of a multi-hour run and finishes having produced nothing. It's the single worst kind of failure: expensive, slow, and quiet.A batch coding worker needs tens of gigabytes of scratch space, sized to the repo — not a fixed 1 GB NFS mount.
2. Idle reclaim kills long jobs mid-flight
A microVM-backed runtime reclaims sessions it thinks are idle. My worker spends long stretches "thinking" with no HTTP chatter, so the platform reclaimed the microVM out from under a running job — killing anything past its idle threshold before it could report back. The workaround was a
/ping health check that lied and always reported "busy" to keep the microVM pinned — and needing to trick your host into not killing your job is a sign you're on the wrong host. (A close cousin: work simply lost when a run hit its ceiling.)3. A broken image ships green because CI never boots it
The runtime container was built and deployed by the pipeline, but CI never actually started it. So a bad image — one missing a module the entrypoint imported — sailed through every check and only exploded ~60 seconds into a real dispatch, at runtime boot, with
ERR_MODULE_NOT_FOUND . The problem isn't just the missing file; it's that failure surfaced at the worst possible moment instead of at build time.Why CodeBuild fits a batch coding worker
Line those three failures up against what AWS CodeBuild gives you and the fit is almost embarrassing:
Big, configurable disk. CodeBuild build environments come with tens of GB of disk under
$CODEBUILD_SRC_DIR , and it scales with the compute type you choose . The silent disk-full wedge doesn't get a fix — it stops being possible.Long timeout, no idle reclaim. A build runs until it's done or until its timeout, which you can set anywhere from 5 minutes up to 36 hours ( 2,160 minutes ). Nothing reclaims a "quiet" build for thinking too long. The
/ping lie simply deletes itself.A native IAM service role. A CodeBuild project runs as a service role you define . That means the worker calls Amazon Bedrock with role credentials — no OIDC assume-role dance, no long-lived API key to rotate. Auth gets simpler the moment you move.
It fails loudly. A build that can't start its container is a red build, at build time, in your face — exactly the class of failure that slipped through when CI never booted the image. Loud failure is a feature when the alternative is a silent 60-second death in production.
Clean orchestration and GitHub wiring. CodeBuild slots straight into AWS Step Functions via
StartBuild , so a durable Wait / Choice loop can supervise a long run instead of an agent re-invoking itself. And when you want CI-style triggers, CodeBuild can host your GitHub Actions runners — the job inherits the CodeBuild service role, so even claude-code-action with use_bedrock: true skips the credential juggling.The live view survives. The one thing you might fear losing is the browser "watch it work" view. You don't — as long as the worker keeps publishing session events (I use a SigV4 writer straight to AppSync). You trade a token firehose for message- and tool-level updates, which is exactly right for a job nobody is watching keystroke-by-keystroke.
Be honest about the tradeoffs
CodeBuild isn't free of edges, and pretending otherwise would be a disservice:
- No
issue_commentwebhook. CodeBuild's native GitHub events cover pushes, PRs, and workflow jobs — but not issue comments, which is how a@mentionbot gets dispatched. The clean answer is to route the mention through a GitHub Actionson: issue_commentworkflow, which then kicks off the build (directly or via Step Functions). The event router lives in Actions; the heavy lifting lives in CodeBuild.
- Cold start. Provisioning and image pull cost tens of seconds per run. For a background coding job that runs for minutes, that's noise — but if you need instant response, a reserved-capacity fleet trades standing cost for warm starts.
- Concurrency limits. The default concurrent-build quota (around 20, varying by compute type) is adjustable — worth confirming before a big fan-out of parallel dispatches.
The takeaway: match the host to the workload's shape
The mistake I made early was treating "hosting the agent" as one decision. It's two. An interactive, human-in-the-loop chat agent wants low-latency streaming and session affinity — a container runtime earns its keep there. An autonomous batch worker wants big disk, a long uninterrupted runway, native cloud credentials, and loud failure. That's a build system's job description, and CodeBuild reads like it was written for it.
If you're standing up an autonomous coding agent and wondering where it should live, ask what shape the work is. If it's "clone a repo, grind for a while unattended, open a PR," you probably want a build, not a server.
Related reading
- Let Your AI-DLC Agent Run to Completion on EC2 — the always-on-instance option, when you want it.
- I Stopped Running Claude Code on My Laptop. Here's What I Do Instead. — why unattended work leaves the laptop.
- Host Claude Code on Bedrock AgentCore with the AgentCoreApplication CDK Construct — the right home for the chat path.
- @agent in Your GitHub Issues, No Runner Required: Webhooks + Step Functions + Bedrock AgentCore — the dispatch-from-a-mention pattern.
- How I Used Claude Code to Make an Autonomous Coding Harness Reliable — the reliability work that surfaced these failure modes.
- Autonomous Epic Delivery with Orchestrator + Worker Agents — where the worker fits in the bigger picture.
Enjoyed reading this content? Let the author know!
Your likes, comments, shares, and saves help creators reach more builders.
Loading recommendations
Loading article