Should you run Claude Code via HarnessAgent on Workers?
How to run Claude Code and Codex via AI SDK 7 HarnessAgent into a Cloudflare Workers monorepo with Vercel Sandbox and read-only GitHub mirrors.
Should you centralise Claude Code and Codex behind a Cloudflare Workers monorepo?
This pattern gives you a end-to-end way to run Claude Code and Codex through AI SDK 7’s experimental HarnessAgent into a Cloudflare Workers monorepo, with Vercel Sandbox as the execution backend and GitHub treated as read-only. The verdict: it is worth considering if you are already on Cloudflare Workers, want strict blast-radius control, and are willing to pay the complexity tax of wiring Workers, HarnessAgent, Sandbox and repo mirrors together.
Vercel’s AI SDK 7 introduces experimental harness abstractions and HarnessAgent as a TypeScript API for running established agent harnesses like Claude Code and Codex through a single interface, with sandbox support and first-class timeouts highlighted in the launch post AI SDK 7 is now available. Vercel’s guide on investigating GitHub issues with HarnessAgent shows how to run these agents in Vercel Sandbox microVMs rather than on the host environment Investigate GitHub issues with HarnessAgent and Vercel Sandbox. Combined with Cloudflare Workers as a control plane and a dedicated monorepo, this lets you expose realistic repositories to agents and still keep your real GitHub repos and secrets out of reach. If your team is also considering HarnessAgent in CI, compare this Workers pattern with the disposable mirror workflows in AI SDK 7 HarnessAgent CI sandbox: keep Codex, Claude Code and Cursor away from your real repo.
The largest benefit is deterministic blast radius: all writes happen inside mirrored repos and a Cloudflare-managed monorepo, promoted only by pull requests. The largest downside is operational complexity: you add Workers, Vercel Sandbox, repo mirrors, queueing and PR automation on top of AI SDK 7. For a deeper look at how to structure an AI-native Workers monorepo, see the companion guide Cloudflare Workers AI monorepo for agents, done right.
Architecture at a glance: how the pieces fit together
At a high level, the pattern looks like this:
- Cloudflare Workers monorepo — your control plane. A Worker exposes an API (or dashboard) to request coding tasks. It owns secrets and the mapping between tickets and sandbox sessions.
- GitHub read-only — the Worker reads from your real repos via a service account with read-only scopes. Agents never get that token.
- Disposable mirrors — for each task, the Worker arranges a short-lived mirror repo or archive (e.g. in a Vercel Sandbox volume or pre-synced storage).
- Vercel Sandbox — execution backend. A microVM runs the HarnessAgent process with the Claude Code or Codex harness attached, pointing at the mirror, not the real repo.
- AI SDK 7 HarnessAgent — the harness orchestrator, running inside the sandbox. It talks to Anthropic/OpenAI APIs, manages prompts, tools and timeouts.
- Promotion path — when the agent is done, the Worker collects patches from the sandbox and opens PRs back to GitHub via a bot account, or pushes to a staging repo.
OpenAI’s Agents SDK documentation shows a similar pattern where a Cloudflare Worker forwards sandbox traffic for agent execution Sandbox clients | OpenAI Agents SDK. A public project named background-agents demonstrates Cloudflare Workers acting as a control plane for Vercel Sandbox background-agents GETTING_STARTED. These references indicate that Workers are a viable control plane for external sandboxes.
Decision table: when this pattern makes sense
| Option |
Best for |
Starting infra price |
Main strength |
Main limitation |
| HarnessAgent + Cloudflare Workers monorepo + Vercel Sandbox (this article) |
Teams standardising on Cloudflare Workers with strict guardrails |
Cloudflare Workers Paid, plus Vercel Sandbox usage |
Hard network boundaries and PR-only promotion; agents never touch real repos or secrets |
Highest plumbing complexity; requires Workers, Sandbox, mirrors and PR automation |
| HarnessAgent in CI only (GitHub Actions + Sandbox) |
Teams that only need suggestion/patches tied to CI |
GitHub Actions + Sandbox usage; no Workers needed |
Simpler integration surface; disposable mirrors per CI run |
No central long-lived control plane; CI-centric UX |
| Vercel-only HarnessAgent backend |
Vercel-first teams, not on Cloudflare Workers |
Vercel Sandbox and deployments; no Workers |
Fewer platforms; direct integration with Vercel tools |
Less natural for Cloudflare-native infra; no Workers-first control plane |
| IDE-native agents (Cursor, Claude Code local, Codex in editor) |
Solo builders or small teams optimising for speed |
IDE subscriptions + token usage |
Minimal infra work; immediate feedback in editor |
Weaker centralised controls; harder to enforce org-wide guardrails |
Why centralise agents behind a Cloudflare Workers monorepo?
This pattern starts from two design constraints:
- GitHub must be read-only for agents — no agent should hold a GitHub token with write access to production repos.
- Agent execution must be isolated — code should run in a sandboxed environment without access to corporate networks or long-lived secrets.
Vercel’s AI SDK 7 positions HarnessAgent as the piece that orchestrates coding agents with sandbox integration AI SDK 7 is now available. The sandbox abstraction in the AI SDK repository notes that any sandbox provider implementing the interface can be used, not just Vercel Sandbox sandbox-abstraction.md · vercel/ai. Vercel Sandbox is a GA product providing on-demand, isolated Linux microVMs for untrusted or user-generated code, with current documentation and changelog entries indicating session runtimes up to 24 hours on Pro and Enterprise plans and shorter limits on Hobby Vercel Sandbox, Vercel Sandbox can now run for up to 24 hours. This combination lets you keep the heavy lifting inside isolated microVMs.
Cloudflare Workers then become the globally distributed coordinator. Cloudflare’s documentation describes Workers as a serverless functions platform where functions scale automatically, billed on CPU time rather than wall-clock I/O Cloudflare Workers - Global Serverless Functions Platform. Cloudflare’s Workers Paid plan is listed at $5 per account per month and includes 10 million Worker requests and 30 million CPU‑milliseconds per month across the account before overages, with additional requests and CPU‑ms billed at the rates shown on the Workers pricing page Pricing · Cloudflare Workers docs, Usage-based billing · Cloudflare Billing docs. For a central control plane that primarily proxies and orchestrates, this cost is close to a fixed tax at current pricing levels.
For teams that need to reason about how this Workers-first pattern compares to GitHub Actions–centric designs, the CI-focused guide Run AI coding agents in GitHub Actions safely walks through a similar mirror-and-promotion model without Cloudflare in the loop.
Blast radius and access control
With this architecture, it is possible to implement three hard boundaries:
- Secret boundary — only Cloudflare Workers hold long-lived secrets (GitHub read-only tokens, Anthropic/OpenAI keys, Vercel Sandbox credentials). Sandbox microVMs receive short-lived scoped tokens or signed URLs.
- Network boundary — Workers are configured to talk only to GitHub, Vercel Sandbox, and AI APIs. Sandbox microVMs have outbound access restricted to necessary endpoints or proxies, according to the sandbox provider’s capabilities.
- Write boundary — agents can write only inside the sandbox filesystem and, optionally, to the Cloudflare Workers monorepo or a staging repo via deliberately exposed tools.
Every promotion into your real repos happens via PRs opened by the Worker using a bot account. The agent never sees the PAT or SSH key; it just emits patches or a branch name within the sandbox.
Secret and billing exposure
Anthropic’s help center explains that if an ANTHROPIC_API_KEY environment variable is set, Claude Code will authenticate with that API key instead of a Claude subscription (Pro, Max, Team, or Enterprise), so usage is billed against Claude API credits at current list prices rather than drawing from a subscription’s included usage Use Claude Code with your Pro or Max plan, How do I pay for my Claude API usage?. OpenAI similarly bills per token for models like GPT‑4.1 and o3‑mini Pricing | OpenAI API, o3-mini Model | OpenAI API. Putting these keys only in Cloudflare Workers lets teams:
- Rate-limit or budget at the control plane level.
- Rotate API keys centrally without touching developer laptops or sandboxes.
- Ensure that sandbox compromise does not leak long-lived keys.
Workers’ CPU-based billing means the cost of proxying to external APIs is dominated by the CPU work performed, not wait time on network Workers Pricing: Compute-to-zero. For a lightweight orchestration Worker, Cloudflare costs stay predictable relative to token spend.
How the HarnessAgent + Cloudflare + Sandbox flow works
The concrete flow for a ticket might look like:
- Developer creates a task — via an internal UI or a POST to the Workers API, specifying repo, branch, and intent (e.g. “refactor this Worker to use Durable Objects”).
- Cloudflare Worker validates and schedules — checks quotas, picks a HarnessAgent harness (Claude Code or Codex), and enqueues a job (e.g. in a Cloudflare Queue or durable store).
- Worker starts a Vercel Sandbox session — calls the Vercel Sandbox API to spin up a microVM with a pre-baked image containing Node, Git, and the HarnessAgent runtime.
- Repo mirror is created — either by:
- the Sandbox startup script cloning a read-only mirror from GitHub using a short-lived token, or
- the Worker pre-building an archive (tarball) of the repo and granting the Sandbox a signed download URL.
- HarnessAgent boots inside the Sandbox — entrypoint code imports AI SDK 7, constructs a
HarnessAgent instance bound to the mirror path and the chosen harness, and connects back to the Worker or a logging endpoint.
- Agent session runs — the harness (Claude Code or Codex) issues tool calls (edit file, run tests, search), all confined to the mirror. Vercel’s guide shows how to wire
@ai-sdk/harness-claude-code and @ai-sdk/harness-codex into HarnessAgent with a Vercel Sandbox provider Investigate GitHub issues with HarnessAgent and Vercel Sandbox.
- Results are returned — HarnessAgent summarises patches, diffs, and logs. The sandbox sends them back to the Worker (e.g. via HTTP callback or polling).
- Worker applies promotion policy — it may push the patch into a staging repo, open a PR against your real monorepo, or park the diff for human review.
Claude Code vs Codex harness specifics
The Claude Code harness adapter is designed for repository-centric sessions where the harness can see environment variables and keys appropriate to that repo context, as described in Anthropic’s guidance on Claude Code environment variables and API keys Manage API key environment variables in Claude Code. In the sandboxed HarnessAgent setup, those environment variables come from the sandbox, not from the developer’s machine.
The Codex harness has a particular integration detail: the @ai-sdk/harness-codex package exposes a CodexHarness factory that requires teams to provide skills explicitly, rather than auto-discovering them from a directory. The npm documentation explains that skills are injected into the prompt each turn @ai-sdk/harness-codex - npm. This fits well with a centralised Workers control plane, because it is possible to choose which skills to enable per task or per repo, and codify that policy in Worker code.
For teams still deciding between Claude Code and Codex as the primary harness, Claude Code vs Codex (2026): Which AI Coding Agent Is Safer on a Real Repo? walks through strengths, limits and safety trade-offs on production repositories.
Cost analysis: Workers vs token spend vs Sandbox
The real cost driver in this architecture is model tokens, not Cloudflare Workers or even the Workers for Platforms tier.
Cloudflare Workers pricing and limits
- Workers Free — up to 100,000 requests per day with lower CPU limits, suitable for small experiments Limits · Cloudflare Workers docs.
- Workers Paid — currently listed at $5/month, including 10 million requests and 30 million CPU-milliseconds across all Workers on the account before overages Pricing · Cloudflare Workers docs, Usage-based billing · Cloudflare Billing docs.
- Workers for Platforms — a separate product with pricing documented in the Workers for Platforms pricing reference. The reference notes that subrequests from a Worker are not billed separately, but exact current pricing and limits depend on the account and should be taken from the official docs rather than secondary materials Workers for Platforms pricing.
Given that the Worker primarily:
- authenticates requests,
- calls GitHub and Vercel Sandbox APIs,
- forwards messages to HarnessAgent in the sandbox,
the CPU cost stays low compared to the included 30 million CPU-ms on the Paid plan at current documented limits.
Claude and OpenAI token pricing
Anthropic’s public pricing sheet lists Standard global rates of $3.00 per 1M input tokens and $15.00 per 1M output tokens, with Batch processing rates at $1.50 per 1M input tokens and $7.50 per 1M output tokens for supported Claude models Anthropic Model Pricing — 2026‑05‑27. OpenAI’s pricing similarly charges per 1M tokens for models like GPT‑4.1 and o3‑mini, with model-specific rates and optional extras like web search blocks Pricing | OpenAI API.
Illustrative cost scenarios
The following scenarios apply those published prices to typical HarnessAgent usage patterns. Vercel Sandbox pricing is metered but not fully specified in the referenced material, so it is treated as an additional variable cost.
Scenario 1: solo builder, light usage
Assumptions:
- 500 HarnessAgent sessions/month.
- 10 Worker requests/session (start, stream, logs, finalize) ⇒ 5,000 requests/month.
- Each session uses 50k input tokens and 15k output tokens across multiple turns.
- Claude API Standard tier pricing.
Token arithmetic:
- Total input tokens = 50,000 × 500 = 25,000,000 tokens.
- Total output tokens = 15,000 × 500 = 7,500,000 tokens.
Cost:
- Input: 25,000,000 ÷ 1,000,000 = 25 units × $3.00 = $75.00.
- Output: 7,500,000 ÷ 1,000,000 = 7.5 units × $15.00 = $112.50.
- Total Claude tokens ≈ $187.50/month.
- Cloudflare Workers Paid plan: $5.00/month; 5,000 requests is well under the 10M included requests, and CPU use is light.
Result: infra cost for Workers is essentially the fixed $5; token spend dominates. The HarnessAgent + Workers architecture adds negligible marginal infra cost at this usage level.
Scenario 2: small team, moderate usage
Assumptions:
- 3,000 HarnessAgent sessions/month across 5–10 engineers.
- 10 Worker requests/session ⇒ 30,000 requests/month.
- 80k input tokens and 30k output tokens per session on average.
Token arithmetic:
- Total input tokens = 80,000 × 3,000 = 240,000,000.
- Total output tokens = 30,000 × 3,000 = 90,000,000.
Cost:
- Input: 240,000,000 ÷ 1,000,000 = 240 units × $3.00 = $720.00.
- Output: 90,000,000 ÷ 1,000,000 = 90 units × $15.00 = $1,350.00.
- Total Claude tokens ≈ $2,070.00/month.
- Cloudflare Workers Paid still at $5.00/month; 30,000 requests is far below the 10M included.
Result: even at this heavier usage, Workers costs remain almost negligible relative to token spend. Any optimisation should focus on session length, model choice or Batch usage.
Scenario 3: conservative team, Workers Free for experimentation
Assumptions:
- 100 HarnessAgent sessions/day during a short trial.
- 10 Worker requests/session ⇒ 1,000 requests/day (under the 100,000/day Free cap).
- 20k input tokens and 8k output tokens per session.
- Trial runs for 7 days.
Token arithmetic:
- Tokens per day = (20,000 + 8,000) × 100 = 2,800,000.
- Tokens for 7 days = 2,800,000 × 7 = 19,600,000.
Cost:
- Input: 20,000 × 700 = 14,000,000 ⇒ 14 units × $3.00 = $42.00.
- Output: 8,000 × 700 = 5,600,000 ⇒ 5.6 units × $15.00 ≈ $84.00.
- Total Claude tokens ≈ $126.00 over a week-long experiment.
- Workers Free plan stays within the documented limits; no Workers cost.
Result: it is feasible to trial the architecture on Workers Free; even in that limited period, token costs exceed infra, reinforcing that Cloudflare spend is not the primary variable.
What you actually implement in the monorepo
The Cloudflare Workers monorepo becomes the control surface for agent operations. A practical layout could be:
/workers/agent-control — a Worker handling API requests (HTTP) to start and monitor sessions./workers/webhook — optional Worker to receive webhooks from Sandbox or GitHub./packages/agent-client — shared TypeScript client for calling the Workers API from internal tools./packages/harness-config — shared definitions of harness options, allowed skills per repo, timeout configurations.
Cloudflare’s monorepo support is a matter of build tooling and deployment scripts rather than a Workers limitation. Workers themselves are deployed as individual entrypoints.
Key Worker responsibilities
Inside the agent-control Worker, a typical implementation includes:
- Authentication and authorisation — ensuring only internal systems or authenticated users can schedule agent runs.
- Task normalisation — converting high-level inputs (ticket ID, repo, path) into a structured spec for HarnessAgent.
- Sandbox orchestration — starting and stopping Vercel Sandbox sessions, passing minimal secrets.
- Logging and observability — logging each step (session creation, token estimates, patch results) to Cloudflare logs or external observability tools.
- PR automation — opening, updating, or commenting on GitHub PRs using a bot account.
Because Workers are billed on CPU, any heavy computation (linting, test execution) remains inside the sandbox while the Worker only orchestrates.
Sandbox runtime responsibilities
In the Vercel Sandbox microVM image, a typical setup embeds:
- A Node.js runtime with AI SDK 7 and harness packages installed.
- A small “agent runner” entrypoint that:
- Clones or downloads the repo mirror.
- Constructs a
HarnessAgent with the configured harness (e.g. Claude Code) and skills.
- Streams logs back to the Worker or a logging endpoint.
- Serialises the final diffs and summary to send back before shutting down.
Vercel’s Sandbox documentation and changelog indicate that microVMs can run for extended periods, including up to 24 hours on Pro and Enterprise plans Vercel Sandbox, Vercel Sandbox can now run for up to 24 hours, which is more than enough for typical coding sessions.
Developer ergonomics and latency
Compared with IDE-native agents like Cursor or Claude Code running locally, this architecture introduces additional latency:
- Time to schedule and boot a Sandbox microVM.
- Network hops via Cloudflare to Sandbox and AI APIs.
- Serialisation overhead for diffs and logs.
In exchange, developers gain:
- Consistent, auditable runs tied to tickets.
- No need to expose corporate GitHub or Cloudflare credentials on laptops.
- A shared control surface where operations can set policies and budgets.
Vercel’s AI SDK reference positions HarnessAgent within a broader set of UI and workflow components AI SDK Reference Index (GitHub). In practice, teams can build an internal UI that calls the Workers API, replacing some of the immediacy of IDE agents with a structured workflow. For a more general end-to-end blueprint for shipping AI-powered features safely, see AI development workflow that actually ships code.
Observability and auditability
Because all scheduling and promotion goes through Cloudflare Workers, logging and tracing can be attached at the control plane:
- Log every session request with repo, branch, harness type, and estimated tokens.
- Store session outputs (summaries, diffs) in a database or object store, keyed by task ID.
- Correlate Sandbox lifetime with Workers logs using session IDs.
Cloudflare’s billing and usage docs make it straightforward to track requests and CPU-ms per Worker Usage-based billing · Cloudflare Billing docs. On the AI side, Anthropic’s API dashboard and OpenAI’s usage pages show token usage, which can be mapped back to sessions via per-request metadata.
Who should adopt this pattern
The architecture is most appropriate for:
- Cloudflare-first teams — teams already building APIs, automation, or websites on Cloudflare Workers, and comfortable treating Workers as a first-class control plane.
- Security- or compliance-conscious organisations — where centralising secrets, enforcing read-only GitHub for agents, and having a clear audit trail are non-negotiable.
- Teams standardising on HarnessAgent — planning to use Claude Code, Codex and future harnesses behind a single abstraction.
Who should skip or delay
This pattern is probably not worth the overhead if:
- You are a solo dev comfortable with local agents and strict personal discipline.
- Your team does not use Cloudflare Workers and does not plan to; a Vercel-only HarnessAgent backend is simpler.
- Your use case is code review and suggestions only, with no need to run code against live or staging infra; CI-only agents or GitHub Apps are simpler.
- Your compliance rules forbid Vercel and you are not ready to implement your own sandbox provider.
What changes the decision
The choice to adopt this architecture is sensitive to a few scenario changes.
- If you only need agents to propose patches or comments — a HarnessAgent-in-CI setup running in GitHub Actions with disposable mirrors may be enough. You avoid Workers and the Sandbox control plane, keeping agents inside CI.
- If Cloudflare is not a core runtime for your organisation — pushing HarnessAgent control through Workers adds a platform and cost when a Vercel-only architecture can serve as both execution and control plane.
- If your developers primarily use Cursor or Claude Code locally — and there is no plan to centralise agents, then strict branch protections and local guardrails may be a better use of effort than building a Workers-based monorepo.
- If you need long-running Cloudflare-native agents — as Cloudflare’s own agent or container runtimes evolve, they may become more attractive than delegating execution to Vercel Sandbox, especially where Durable Objects and Queues are central.
- If Vercel Sandbox is not permitted — AI SDK’s sandbox abstraction supports alternative providers; a compatible provider would need to be implemented on internal infrastructure instead of using Vercel.
- If your repos are very large and sessions are deep — mirroring huge repositories into short-lived sandboxes for long sessions may be inefficient. Long-lived VMs or specialised IDE agents could be more economical.
Comparison criteria and what this article is based on
The evaluation in this article is based on vendor documentation, pricing pages and public reference implementations, not on private benchmarks or production tests. In particular:
All quantitative comparisons (cost scenarios, request volumes) are normalised estimates derived from these published prices and limits. They are intended to show order-of-magnitude trade-offs rather than precise forecasts.
Practical next steps
For teams where the pattern fits the constraints, a pragmatic rollout looks like:
- Start with a small scope: pick one Cloudflare Workers repo and one HarnessAgent harness (Claude Code or Codex) for a limited class of tickets.
- Deploy a basic
agent-control Worker that can request a sandbox session and log session metadata without yet wiring PR creation.
- Integrate AI SDK 7 and the harness into a minimal Sandbox runtime that accepts a spec from the Worker and runs a single bounded agent session.
- Add GitHub read-only mirroring and simple diff-returning to validate the blast radius model.
- Only then add automatic PR creation and multi-repo support, once observability and budgeting are in place.
Implemented this way, the HarnessAgent + Cloudflare Workers monorepo pattern provides a controlled runway to give Claude Code and Codex realistic access to Cloudflare infrastructure, without letting any agent touch real GitHub repos or long-lived secrets directly. As your usage matures, you can pair this Workers control plane with CI-centric patterns from one HarnessAgent GitHub Actions workflow for CI agents to keep your entire stack aligned on the same mirror-and-PR safety model.