The CI-safe way to run Codex, Claude Code and Cursor

How to run Codex, Claude Code and Cursor-style harnesses on disposable repo mirrors in Vercel Sandbox, with no long-lived GitHub tokens and hard GPT‑4.1 budgets.

If you are running serious coding agents in CI in 2026, you should standardise on a disposable-mirror HarnessAgent + Vercel Sandbox pattern where CI owns Git credentials, agents only see a mirrored workspace, and every run is bounded by strict token, time and sandbox budgets. This fits neatly with the broader guidance in the AI coding agents in CI/CD pipelines article: agents help, but they should never be able to touch production systems directly.

This article lays out that pattern using AI SDK 7’s HarnessAgent, Vercel Sandbox microVMs and mid‑2025 GPT‑4.1 pricing as a worked example. As of September 22, 2026, OpenAI’s current pricing documentation must be checked before adopting any numeric budgets shown here, because GPT‑4.1 and GPT‑4.1 mini are no longer listed at the historical $2.00 / 1M input and $8.00 / 1M output (GPT‑4.1) and $0.40 / 1M input and $1.60 / 1M output (GPT‑4.1 mini) rates. For a deeper, cost-first take across agents and CI stacks, see the AI coding agent costs in CI after 2026 pricing changes brief.

Why a CI sandbox for HarnessAgent coding runs exists now

Vercel’s AI SDK 7 introduces HarnessAgent, an experimental abstraction that lets you run established agent harnesses such as Claude Code, Codex and Pi through a single Agent‑compatible interface, as described in the AI SDK 7 announcement. Its outputs integrate with the rest of the AI SDK in the same way as existing agents; models, prompts and tools are configured using the standard AI SDK patterns.

At the same time, Vercel Sandbox has matured into a standalone SDK for running untrusted code in isolated microVMs, usable from non‑Vercel platforms. Vercel’s documentation explains how to run untrusted or AI‑generated code inside Sandbox microVMs, treating the harness and the sandbox as separate layers: agent logic (for example, a HarnessAgent‑based harness) orchestrates tools and instructions, while Sandbox executes code with strong isolation.

The security problem this combination solves is straightforward:

Coding agents need file system access and tools to be useful in CI.
Giving them long-lived GitHub personal access tokens (PATs) or direct access to deployment credentials is risky and hard to audit.
Running them directly in the main CI runner widens the blast radius of any harness bug, prompt injection or supply-chain attack.

The design target is an opinionated, production-oriented workflow:

CI owns all GitHub credentials and main pipeline secrets.
Agents run only in sandboxed microVMs on a disposable mirror of the repo.
Every run is capped on tokens, wall-clock time and sandbox runtime.
The only persistent outcome is a PR-ready diff or patch, emitted by CI, not by the agent directly.

For teams still deciding where agents should sit in the pipeline, the broader safe AI coding agent PR workflow for production guide shows how this sandbox pattern fits into a PR-first strategy.

Design constraints for a 2026-ready HarnessAgent CI sandbox

A HarnessAgent CI sandbox pattern that is credible for 2026-era workloads needs to meet five constraints.

No long-lived GitHub PATs exposed to agents

All GitHub operations must happen outside the sandbox:

Use GitHub Actions’ ephemeral tokens or a GitHub App installation token on the CI host for clone, fetch, push and PR creation.
The sandbox receives only a workspace mirror (files on disk) and synthetic tools (for example, readFile, writeFile, runTests).

Vercel’s changelog on native subscription authentication shows how the harness layer can receive placeholder credentials while the real token is injected into outbound requests on the host when the sandbox environment supports it. That avoids exposing provider secrets directly to harness code.

No direct access to main workflows or deployment credentials

Inside the microVM, the agent should not see:

CI environment variables for production databases, deploy keys or cloud accounts.
Workflow definitions used for deployment or privileged operations.

Mount only the repository snapshot (or a scoped subset) and a small config describing the task. Treat the sandbox as untrusted code execution, matching Vercel’s positioning of Sandbox as an isolation layer for such workloads. For a deeper walkthrough of how this fits alongside GitHub and Vercel, pair this with the GitHub + Vercel hardening workflow for AI coding agents.

Hard budgets: tokens, time, sandbox runtime

On the LLM side, OpenAI historically priced GPT‑4.1 at USD $2.00 per 1M input tokens, $0.50 per 1M cached input tokens, and $8.00 per 1M output tokens, and GPT‑4.1 mini at $0.40 per 1M input, $0.10 per 1M cached input, and $1.60 per 1M output, according to OpenAI’s GPT‑4.1 announcement and pricing materials in 2024–2025. As of September 22, 2026 OpenAI’s current pricing pages list newer GPT‑5‑series models instead; the GPT‑4.1 figures in this article are dated examples only, and the latest OpenAI pricing documentation must be consulted before setting budgets.

On the sandbox side, practical limits normally include:

MicroVM lifetime (for example, 2–5 minutes for small repos, longer for heavy runs).
CPU and memory (per sandbox) to avoid CI runner saturation.

The pattern assumes explicit per-run ceilings on aggregate tokens, wall-clock time and sandbox lifetime, and repo-level or org-level monthly limits. For a deeper, cost-first take across agents and CI stacks, see the dedicated AI coding agent costs in CI after 2026 pricing changes brief.

Deterministic integration: patches and PRs only

The sandbox writes files, runs tests and produces structured diffs or patches. Only the CI host actually pushes to GitHub or opens PRs, providing a single, auditable integration point back into the real repo.

Replayable logs and traces

Every HarnessAgent run should have:

A unique request ID and repo SHA.
Model and token usage details.
Tool traces and commands executed in the sandbox.
A summary of diffs produced, even if they were not applied.

Vercel’s AI SDK and Sandbox documentation emphasise that sandbox behaviour and safety policies are delegated to the provider. Observability is therefore the responsibility of the team operating the system: logs must be queryable both from CI and from whatever telemetry stack is used.

Reference architecture: disposable mirror → HarnessAgent in Sandbox → PR back

This section describes a concrete, repeatable flow suitable for GitHub Actions, but the same pattern applies to other CI systems. For a GitHub Actions-only view with a worked YAML example, see the HarnessAgent GitHub Actions disposable mirror workflow article.

Step 1: trigger and host-side checkout

CI triggers on events such as pull_request labels (ai-refactor, ai-tests) or branch naming conventions.
The CI runner uses its short-lived token to checkout the repo at the target SHA into a working directory.

Step 2: create a disposable mirror workspace

Copy or hard link the checked-out tree into an isolated directory (for example, /tmp/ai-mirror/<run-id>).
Optionally scope the mirror to subdirectories like services/api or apps/web for cost control.

This workspace is not a new Git remote; it is a local copy that will be mounted into the sandbox.

Step 3: start a Vercel Sandbox microVM

Using the Sandbox SDK described in the Vercel Sandbox knowledge base:

Start a microVM with a time-limited session.
Mount the mirror directory into the sandbox file system.
Configure CPU/memory and maximum runtime per the repo size and harness complexity.

Vercel’s documentation shows how to pair AI SDK harnesses (including HarnessAgent) with Vercel Sandbox to run untrusted code, including examples that operate on cloned Git repositories. That pattern is directly aligned with this design, even if specific harness brands like Claude Code or Codex are not always named.

Step 4: run HarnessAgent against the mirror

Inside the sandbox, a small host script initialises AI SDK 7’s HarnessAgent with the chosen harness (Codex, Claude Code or another HarnessV1 adapter) and model.
The agent receives instructions (for example, “add missing tests for changed files”) and tools that read/write files, run tests and produce structured change sets.

Because HarnessAgent is designed as an interface over multiple harnesses and sandboxes, it is possible to swap harness implementations without changing the CI wiring. For a broader comparison of where Codex, Claude Code and Cursor-style agents fit, see Cursor vs Claude Code 2026: IDE-first vs agent-first coding stacks.

Step 5: collect diffs, apply on host and open PR

The sandbox script returns a machine-readable description of file changes: paths, hunks, or full file contents.
The CI host reconstructs a Git patch, applies it to a branch (for example, ai/<run-id>), runs validation tests, and only then pushes.
From the host, use the GitHub token or App to open or update a PR with a summary of what the agent did.

If any step fails (invalid patch, failing tests, Sandbox timeout), the run is marked as advisory or failed and no Git changes are pushed.

Step 6: teardown and discard

Terminate the sandbox session.
Delete the mirror workspace from the CI runner.

The only durable artefacts are CI logs, agent traces and Git state in the PR branch.

Concrete wiring: AI SDK 7 HarnessAgent + Vercel Sandbox in CI

The exact code will depend on the stack in use, but the wiring follows a consistent shape using AI SDK harness packages. The @ai-sdk/harness-codex npm package, for example, is documented as a HarnessV1 adapter for Codex intended to be used with @ai-sdk/harness and @ai-sdk/sandbox-vercel when running Codex in a sandbox.

Minimal TypeScript harness runner inside the sandbox

A simplified example shows the idea (pseudocode, not a full implementation):

import { createHarnessAgent } from "@ai-sdk/harness";
import { createCodexHarness } from "@ai-sdk/harness-codex";
import { vercelSandboxFs } from "@ai-sdk/sandbox-vercel";
import { openai } from "@ai-sdk/openai";

async function runHarness() {
  const fs = vercelSandboxFs({ rootDir: process.env.WORKSPACE_ROOT });

  const codexHarness = createCodexHarness({
    fs,
    // other Codex-specific options
  });

  const agent = createHarnessAgent({
    harness: codexHarness,
    model: openai("gpt-4.1-mini"),
    instructions: "Add missing unit tests for the changes in this branch.",
    tools: { fs /* plus test runner, formatter, etc. */ },
    sandbox: { timeoutMs: 120000 },
  });

  const result = await agent.generate({
    input: {
      task: "write tests for changed files",
      diff: process.env.CHANGED_FILES_DIFF,
    },
  });

  // result should include a structured list of file edits
  console.log(JSON.stringify(result, null, 2));
}

runHarness().catch((err) => {
  console.error(err);
  process.exit(1);
});

Here, the vercelSandboxFs binding provides file system access inside the microVM rooted at the mirrored workspace. HarnessAgent orchestrates the harness, model and tools, while respecting a sandbox timeout.

Session lifecycle

A robust session flow looks like:

Host starts sandbox with a maximum lifetime.
Sandbox process starts the harness runner with environment variables describing the task and workspace location.
HarnessAgent runs, emitting logs and diffs.
On completion or timeout, host reads logs and diff artefacts, then shuts down the sandbox.

Vercel Academy’s “Build Your Own AI Coding Agent Harness” course notes that production sandbox lifecycles typically require more durable workflows and state than local demos. In CI, that implies explicit timeouts, retries and telemetry rather than ad-hoc scripts.

Native subscription authentication and credential handling

With native subscription authentication enabled in the harness layer, the host can store provider credentials (for example, an OpenAI API key or a Codex subscription token) and allow the harness to use logical placeholders. When the sandbox environment supports it, the host injects the real token into outbound requests without exposing the secret directly to harness code, as detailed in Vercel’s changelog. This pattern is compatible with the goal of avoiding long-lived GitHub tokens in the sandbox.

GitHub integration without handing agents your keys

The core security idea is simple: keep GitHub access on the CI host and expose only file-system level operations to the sandbox.

Host-side Git operations with ephemeral tokens

In GitHub Actions, the GITHUB_TOKEN is a short-lived token scoped to the repo and job.
For more control, configure a GitHub App with fine-grained permissions and exchange its installation ID for a scoped token inside CI.

Use these tokens only on the host to:

git checkout the target SHA.
git push an ai/<run-id> branch.
Call GitHub’s REST or GraphQL API to open/update PRs.

The sandbox never sees these tokens. It manipulates local files only.

From harness output to Git patches

Design the harness output schema to describe changes deterministically, for example:

List of edited files, with either full content or patch hunks.
New and deleted files explicitly marked.

The host then:

Writes file contents into the mirror or applies hunks using a patch library.
Runs git diff --binary to produce a patch artefact.
Applies the patch to the working branch and runs tests.

Failure isolation

This pattern gives multiple safety gates:

If the sandbox crashes, CI sees a non-zero exit code and skips Git changes.
If diffs are invalid, the host can reject them and keep the run purely advisory, attaching the diff artefact to the CI logs for manual review.
If validation tests fail, CI can still open a draft PR with failing status checks, or drop the changes entirely.

At no point does the harness itself call the GitHub API. This contrasts with patterns where agents hold a PAT and push branches directly, which reintroduces key management and audit challenges. For a GitHub-specific deep dive into safe wiring patterns, see run AI coding agents in GitHub Actions safely.

Budgeting and timeouts tuned to GPT‑4.1 pricing

With GPT‑4.1 and GPT‑4.1 mini historically priced as described above, token consumption in coding harnesses becomes a first-order concern. The scenarios in the decision brief translate those historical prices into practical budgets.

Price reference

Model	Type	Price	Tokens per USD
GPT‑4.1	Input	$2.00 / 1M tokens	500,000
GPT‑4.1	Cached input	$0.50 / 1M tokens	2,000,000
GPT‑4.1	Output	$8.00 / 1M tokens	125,000
GPT‑4.1 mini	Input	$0.40 / 1M tokens	2,500,000
GPT‑4.1 mini	Cached input	$0.10 / 1M tokens	10,000,000
GPT‑4.1 mini	Output	$1.60 / 1M tokens	625,000

OpenAI previously documented a 50% discount for some models when used via the Batch API rather than real‑time requests. Because available models and discounts change frequently and GPT‑4.1 itself is being phased out of some products, any Batch or bulk‑usage discounts must be verified against OpenAI’s current pricing documentation instead of assuming a fixed 50% reduction.

Per-run cost scenarios (derived)

The following scenarios use arithmetic based on historical GPT‑4.1 / GPT‑4.1 mini prices as illustrative examples; these must be recomputed with the current model and OpenAI’s up‑to‑date pricing.

Solo builder, GPT‑4.1 mini, advisory-only runs — Assume 0.5M input + 0.1M output tokens per run.
- Input: 0.5M / 1M × $0.40 = $0.20
- Output: 0.1M / 1M × $1.60 = $0.16
- Total per run ≈ $0.36
- At 100 runs/month ≈ $36/month
Small team, GPT‑4.1, deep refactors — Budget 2M input + 0.5M output tokens per run.
- Input: 2M / 1M × $2.00 = $4.00
- Output: 0.5M / 1M × $8.00 = $4.00
- Total per run ≈ $8.00
- At 200 runs/month ≈ $1,600/month
Larger org, tiered GPT‑4.1 mini + GPT‑4.1 — 80% runs on mini (1M input + 0.25M output), 20% on GPT‑4.1 (3M input + 0.75M output).
- Mini run: 1M × $0.40 = $0.40 input; 0.25M × $1.60 = $0.40 output; ≈ $0.80 total.
- GPT‑4.1 run: 3M × $2.00 = $6.00 input; 0.75M × $8.00 = $6.00 output; ≈ $12.00 total.
- For 1,000 runs/month: 800 mini ≈ $640; 200 GPT‑4.1 ≈ $2,400; ~ $3,040 total.
Architectural choice: full-repo vs scoped-directory — Both on GPT‑4.1 mini.
- Full repo: 4M input + 0.5M output.
  - Input: 4M / 1M × $0.40 = $1.60
  - Output: 0.5M / 1M × $1.60 = $0.80
  - Total ≈ $2.40
- Scoped: 1M input + 0.2M output.
  - Input: 1M × $0.40 = $0.40
  - Output: 0.2M / 1M × $1.60 ≈ $0.32
  - Total ≈ $0.72
- Saving per run ≈ $1.68; at 1,000 runs that is ≈ $1,680/month.

Implementing budgets in the stack

A practical configuration ties together:

Model-level caps: pass per-run maximum tokens into the harness configuration, and reject or truncate requests beyond those caps.
Gateway-level spend limits: if an AI gateway is used, configure monthly ceilings and alerting when approaching them.
CI-level labels: only runs with specific labels (for example, ai-deep) are allowed to use GPT‑4.1 with higher budgets.

Timeout and wall-clock recommendations

Deriving from typical CI expectations, a simple guidance table looks like this (sandbox limits exclude external test runtimes):

Repo size	Harness complexity	Suggested sandbox timeout	Use case
Small (<50k LOC)	Advisory tests/docs	1–2 minutes	GPT‑4.1 mini suggestions
Medium (50k–300k LOC)	Targeted refactors	3–5 minutes	Scoped directories only
Large monorepo	Deep refactors	5–10 minutes	Nightly or labelled jobs

Timeouts above this range risk backing up CI queues, and deep refactors on very large repos are usually better suited to scheduled jobs or sub-tree runs rather than on-every-PR execution.

Logging, observability and failure modes for HarnessAgent in CI

HarnessAgent standardises how harnesses are called, but it does not hide the operational realities of sandboxes or LLM APIs. Common failure modes include:

Tool deadlocks or long-running test commands.
Sandbox crashes or resource exhaustion.
LLM rate limits or context overflows.
Malformed diffs that cannot be applied cleanly.

Recommended logging structure

For each run, log at minimum:

Run ID, repo, branch and commit SHA.
Model, harness type and config (for example, gpt-4.1-mini, Codex harness).
Token usage split by input, cached input and output.
Sandbox lifecycle events (start, heartbeat, timeout, exit code).
Summary of file changes (count of files and lines changed).

Emit structured logs into CI output for quick inspection and into a separate telemetry store for longer-term analysis (for example, to compute cost per merged line of code or revert rates). For examples of what to measure in practice, the Cursor, Codex, Claude Code cost stack article is a useful complement.

Fallback strategies

Retry with reduced scope: if a full-repo or large-scope run times out, automatically retry on changed files only.
Model downgrade: if GPT‑4.1 calls are rate limited or out of budget, fall back to GPT‑4.1 mini for advisory runs.
Skip and log: if the sandbox infrastructure is degraded, skip agent steps but keep a record of what would have been attempted.

Extending beyond Codex: Claude Code, Cursor-style harnesses and custom agents

AI SDK 7’s HarnessAgent is explicitly positioned as an interface over multiple harnesses and sandboxes rather than a sandbox implementation. That allows teams to treat Codex, Claude Code, Cursor-style harnesses, and custom agents as interchangeable backends behind the same CI pattern.

Pluggable harnesses

With HarnessAgent wired to a sandbox, it is possible to:

Route ai-tests labels to a Codex harness for test generation.
Route ai-refactor labels to a Claude Code harness optimised for multi-file changes.
Use a Cursor-like harness or a just-bash harness (as in the Vercel Academy example) for scripted migrations.

The disposable mirror + sandbox + PR pattern remains the same; only the harness implementation changes. For teams choosing between these agents, the comparison in Cursor vs Claude Code vs terminal-first agents can help establish sensible defaults per workflow.

Hybrid workflows

A pragmatic structure is:

Use HarnessAgent + sandbox for any workflow that needs tools, file system access or test execution.
Use direct GPT‑4.1 mini API calls (without sandbox) for small, stateless edits such as docstring updates or comment generation.

This keeps the heavy, higher-risk operations inside microVMs and uses cheaper models for lightweight tasks.

Keeping harnesses current

Because the harness is a dependency inside the sandbox, platform teams can:

Pin harness versions per repo or per pipeline.
Test new harness versions in a staging CI environment against sample branches.
Roll out gradually by label or directory.

That approach aligns with Vercel’s guidance that production harness lifecycles should use more durable workflows than quick demos.

Operator checklist: shipping a HarnessAgent CI sandbox in your org

For platform and security teams deciding whether to adopt this pattern as standard, the decision brief’s thesis is that this architecture is appropriate for organisations running serious coding agents in CI. This section turns that into a checklist.

Deployment checklist

Sandbox provider: Vercel Sandbox or an equivalent microVM platform that supports the AI SDK harness integration.
Harness packages: AI SDK 7, @ai-sdk/harness, @ai-sdk/harness-codex or other harness adapters as needed.
CI runners: capacity to run short-lived sandbox sessions and to manage disposable workspace mirrors.
Token policy: documented budgets per repo and per label, based on historical GPT‑4.1 and GPT‑4.1 mini prices as examples.
GitHub configuration: ephemeral tokens or a GitHub App with strictly scoped permissions, held only on the CI host.
Observability: logging and metrics piped from both CI and sandbox to a central telemetry system.

Initial rollout and hardening path

Pilot on one repo, scoped to a directory and advisory-only mode (patches attached to CI artefacts, no auto-PR).
Enable auto-PRs for low-risk changes (documentation, tests) once revert rates and costs are understood.
Add auto-merge gates for very low-risk changes with strong tests (for example, generated tests in a dedicated directory).
Extend to more repos and harness types as platform maturity and budgets allow.

Security and compliance points

Review data residency implications of Vercel Sandbox or any third-party sandbox used; if necessary, plan for a self-hosted microVM layer.
Ensure that logs do not inadvertently capture secrets from inside the repo.
Document the boundary: agents cannot access production data, only code and test fixtures.

When the decision changes

The decision brief outlines conditions that flip the recommendation:

If an organisation cannot or will not run sandbox microVMs from CI, the pattern’s main security advantage disappears; in that case, restrict agents to advisory comments or offline tools instead.
If only small, low-risk repos are in scope and a tightly scoped GitHub App is acceptable, a simpler GitHub App-based integration may be enough.
If operating huge monorepos with multi-hour test suites and tight CI SLAs, apply this pattern to scoped subtrees or off-peak jobs rather than every PR.
If workloads are small, stateless edits with no need for tools or file system access, direct LLM calls from CI steps are cheaper and simpler.
If compliance forbids mirroring repos into third-party sandboxes, the architecture remains valid but the sandbox provider must be internal.

Under normal constraints for modern product teams using Codex, Claude Code or Cursor-like agents in CI, a disposable-mirror HarnessAgent + Vercel Sandbox pattern offers a clear balance of security, cost control and operational clarity. It keeps GitHub keys on the host, constrains agents to an isolated view of the repo, and translates historical GPT‑4.1-era LLM pricing into predictable example budgets rather than surprises.

FAQ

How does this HarnessAgent CI sandbox avoid giving agents long-lived GitHub tokens?

The design keeps all GitHub operations on the CI host. The runner uses short-lived tokens or a GitHub App installation token to clone and push, while the sandbox sees only a file-system snapshot of the repo and high-level tools to read and write files. Where supported, native subscription authentication in the AI SDK harness layer allows provider secrets to be injected into outbound calls on the host without exposing them directly inside the harness code.

What does a typical HarnessAgent coding run cost, using historical GPT‑4.1 prices as an example?

Using the historical GPT‑4.1 / GPT‑4.1 mini prices above as a worked example rather than current 2026 numbers, a modest GPT‑4.1 mini run with 0.5M input and 0.1M output tokens comes out to ≈$0.36, while a deep GPT‑4.1 run with 2M input and 0.5M output tokens is ≈$8.00. These figures must be recalculated against whatever model and prices are actually used in production.

Can this pattern work outside GitHub Actions?

Yes. Vercel Sandbox is documented as a standalone SDK for running untrusted code in microVMs from non‑Vercel platforms, and the HarnessAgent abstraction is CI-agnostic. Any CI system that can provide short-lived Git credentials, spawn sandbox sessions and manage ephemeral workspaces can adopt the same disposable-mirror + sandbox + PR pattern.

What if a HarnessAgent run produces bad code?

The host applies additional validation: running tests, linting and static analyses before pushing or merging. If tests fail or diffs are malformed, CI can downgrade the run to advisory-only, attach logs and patches as artefacts, and require human review. Because agents do not push directly, there is always a human- or policy-controlled gate between their output and the main branch.

When should teams avoid adopting this as a standard pattern?

Teams without the operational appetite for sandbox microVMs, logging and budget governance should avoid standardising on this pattern. For occasional, low-risk AI usage—such as IDE suggestions or simple PR comments—a GitHub App or direct API calls may be enough. The HarnessAgent CI sandbox design pays off once coding agents become first-class infrastructure with real responsibility for code changes.