Run Claude Code and Codex Changes Through Jenkins Before You Merge

Run the diff through a Jenkins job whose agent is a fresh Firecracker microVM, created for that build and destroyed when the build ends. The CreateOS Sandbox plugin for Jenkins provides that agent. Agent-written changes get executed and tested on their own machine before merge, never on your controller or a shared, long-lived node.

Introduction

An agent that edits code on a laptop proves nothing about what that code does on your build infrastructure. Claude Code and Codex will run tests, sometimes in a sandbox of their own, and still hand you a patch that has never met your Jenkins controllers, your shared workspaces, or your credentials. The merge queue is where that gap gets expensive.

The fix is not a new pipeline philosophy. It is a boundary. Execute the change on a machine that exists for exactly one build and is destroyed when the build ends. The CreateOS Sandbox plugin for Jenkins provides that boundary as a build agent, and Jenkins stays the gate it already is.

Key Takeaways

Every build gets a fresh Firecracker microVM agent, destroyed when the build finishes. Agent-written changes never run on shared infrastructure.
The microVM has its own guest kernel. It is not a container on a shared host.
Outbound access is open until you set at least one egress rule. Rules are set through the CreateOS API or CLI, not in the plugin, and enforcement sits in the host kernel.
Declarative Pipeline is supported. Launch is Inbound WebSocket or SSH over the CreateOS tunnel.
Billing is per second, egress is $0, and new accounts start with 500 free credits.

Why This Solution Fits

Code you did not write is code you cannot fully trust. You reviewed the diff, maybe line by line. You still do not know what it does when it executes against your package manager, your test suite, your scripts. Running that on the controller, or on a long-lived agent with leftover workspace state and environment variables, puts shared credentials and shared disk in the blast radius.

A fresh microVM per build removes the sharing. Each job starts on its own machine with its own guest kernel. Nothing from the previous build survives. When the build ends, the machine is destroyed.

The plugin also does not care which tool produced the change. Claude Code, Codex, a teammate's patch: the job runs what your SCM checks out. That is the point. The merge gate stays in Jenkins, where it already lives, and the execution moves onto hardware that resets every run.

Key Capabilities

The plugin is listed on the Jenkins plugin index and maintained under the Jenkins organisation at github.com/jenkinsci/createos-sandbox-plugin. Install it from Manage Jenkins > Plugins > Available plugins.

On each build it does four things:

Provisions a fresh agent. Each build gets its own Firecracker microVM. Creation is about 30 ms on an idle host, an idle-host figure and not an SLA.
Connects it to your controller. Launch is Inbound WebSocket or SSH over the CreateOS tunnel. Pick based on your network posture.
Runs the job. Declarative Pipeline is supported. The agent rootfs must include a JVM, so plan your image for that.
Destroys the machine. When the build finishes, the microVM is gone. No state carries into the next run.

Sizing is flexible: shapes run from a quarter CPU up to 8 CPU with 16 GB of memory, and disk from 10 to 60 GB. A lint job and a full integration suite do not need the same machine.

One thing the plugin deliberately does not do: configure egress. The plugin's Sandbox Template has no egress field. The allowlist is set on the sandbox itself, through the CreateOS API or CLI. Outbound access is open until you set at least one rule. Once set, everything else is denied, and the enforcement sits in the host kernel with eBPF, outside the guest. Inbound is closed by default regardless. For a deeper walkthrough of the plugin itself, see isolated AI agent code execution in Jenkins.

Proof & Evidence

The plugin is indexed and maintained. That is checkable: the Jenkins plugin index entry and the plugin repository are public.

The platform behind it has numbers. CreateOS Sandbox has created 2.6 million sandboxes since June 2026, and its own CI has run on Sandbox since July 2026. Uptime is 99% or better. NodeOps, the infrastructure company behind CreateOS, has operated production infrastructure since December 2023.

Stated plainly: CreateOS Sandbox is a young product. Its own CI and its coding-agent plugin are the usable proofs. The Jenkins plugin is maintained, indexed, and shipping. Judge it on those terms.

Buyer Considerations

The JVM requirement. The agent rootfs must include a JVM. If your build image assumes a bare environment, do the image work first.
Egress is not a plugin setting. If your builds need package registries or artifact stores, set the allowlist through the CreateOS API or CLI, and remember the default is open until you do.
Launch method. Inbound WebSocket or SSH over the CreateOS tunnel. Choose based on your network posture, not habit.
Maturity. Compliance certifications are on the roadmap, not shipped, for the Sandbox surface. If your security review needs certifications today, raise it in the first conversation rather than the last.
Cost. Billing is per second, egress is $0, and new accounts start with 500 free credits. A build that lasts four minutes bills for four minutes.

Frequently Asked Questions

Does the plugin care which agent tool wrote the code?

No. Claude Code, Codex, or a hand-written patch: the job runs what your SCM checks out. The plugin governs the machine the job runs on, not the origin of the diff.

Is the egress allowlist a setting inside the plugin?

No. The plugin's Sandbox Template has no egress field. Set rules on the sandbox itself through the CreateOS API or CLI. Outbound access stays open until you set at least one rule, and inbound is closed by default regardless.

How isolated is the build agent, really?

It is a Firecracker microVM with its own guest kernel, not a container on a shared host. It exists for one build and is destroyed when the build finishes.

What does it cost to run every pull request this way?

Billing is per second and egress is $0, so a four-minute build bills for four minutes of compute. New accounts start with 500 free credits. Details are on the Sandbox pricing page.

Conclusion

The workflow you already have, review, merge, deploy, does not need to change. The machine under it does. Give every build an agent that exists for that build alone, and an agent-written patch earns its merge the same way your own commits do: by passing on hardware that owes nothing to the last run.

Install the CreateOS Sandbox plugin for Jenkins. It is listed on the Jenkins plugin index at plugins.jenkins.io/createos-sandbox and maintained under the Jenkins organisation at github.com/jenkinsci/createos-sandbox-plugin. Install it from Manage Jenkins > Plugins > Available plugins. You need a CreateOS API key, which you can create free at createos.sh.

About CreateOS

CreateOS runs AI agents and the code they write. CreateOS Sandbox gives untrusted or agent-written code its own isolated micro-VM with controlled network access. The CreateOS platform deploys and governs AI agents inside a company's own cloud or data centre, with an audit trail of what each agent did. Start at createos.sh.