Every Repository Got Its Own Coding Agent

Every Forge repository now gets one durable coding agent with two compute tiers. **Instant** answers from bounded evidence at an exact commit without a shell, network access, secrets, or repository writes. **Workspace Alpha** can edit and test inside an allowlisted sandbox, but it cannot publish with inherited credentials.

Both tiers continue the same Forge-owned thread. Moving from an Instant answer to a Workspace change does not change the repository, accepted source revision, actor, budget, approval policy, or event history. More compute changes what the coding agent can do; it does not change who owns the work.

The more capable tier started with an unusually explicit prohibition: do not revive the abandoned local-only Codex prototype, and do not let the sandbox inherit the credentials that make publication easy.

<aside class="forge-blog-transcript" aria-label="Excerpt from the Workspace Alpha coding thread">
<div class="forge-blog-transcript__line"><span class="forge-blog-transcript__speaker">User</span><blockquote>“Implement Forge Agent Workspace Alpha […] Use Forge’s existing production substrate […] The sandbox may edit and test only.”</blockquote></div>
<div class="forge-blog-transcript__line"><span class="forge-blog-transcript__speaker">Codex</span><blockquote>“The Alpha slice is now concrete: Workspace requests remain explicit […] and the allowlist supplies the only writable paths, test commands, dependency hosts, and GitHub installation metadata.”</blockquote></div>
<footer>Codex working thread · Aug 5, 2026 · excerpts shortened with omissions marked</footer>
</aside>

That prohibition defines the coding-agent boundary. Workspace Alpha can return a tested change on a fenced branch only after Forge independently inspects the stopped filesystem, repeats declared tests in a trusted checkout, and reconstructs the publication.

One repository owns one coding agent

The tempting design was one account-level agent that could roam across every repository a user could access. It would make cross-repository tasks easy to demo. It would also collapse repository permissions, secrets, branch rules, costs, and audit records into one oversized runtime.

Forge takes the opposite approach. Every thread, message, run, event, approval, artifact, spend reservation, and receipt carries a repository ID. Continuing a thread preserves that scope. Selecting a stronger compute profile preserves it too.

The public thread handle is Forge-owned:

```text
agent_thread_0123456789abcdef0123456789abcdef
```

It is not an OpenCode session ID or a Workers AI request ID. A different execution driver can continue the same Forge thread because the provider session is an implementation detail, not the conversation's public identity.

This also gives future multi-repository work a clear shape. A coordinator may receive explicit grants for repositories A and B, then delegate separate runs to their agents. Repository C remains inaccessible. Coordination composes narrow grants; it does not create a master credential.

A run describes one exact tree

A durable thread alone is not enough. If a run reads `main` while commits continue to land, its answer may describe several revisions at once.

Forge resolves the requested ref before dispatch and stores the resulting 40-character Git SHA on the run. The message, queued run, source SHA, first event, and dispatch intent are accepted together. Follow-up messages reuse the conversation, but each run records the source it actually inspected.

This distinction matters when an answer becomes a change. A provider cannot prove its result by saying that it edited the latest branch. Forge needs an accepted base SHA, an independently reconstructed diff, test evidence, and an output ref whose parent is that base.

Retry identity stays separate from conversation identity. A client may attach `client_message_id` to one message. Reusing that ID with the same normalized message, source, and execution request returns the existing run; changing any of those inputs produces `409 message_conflict`. Forge does not overload an HTTP idempotency header into a thread primitive.

Instant is the read-only tier

Most repository questions do not need a virtual machine. Instant runs in the Forge API Worker and can explain architecture, locate an implementation boundary, or summarize build configuration without a shell, network access, secrets, tests, or repository writes.

Its evidence path is deliberately bounded. At the accepted SHA, Forge traverses the Git tree, ranks likely source paths, and reads at most two relevant excerpts of up to 10,000 characters each. Explicitly named files take priority. Sensitive paths, symlinks, binary files, and oversized files are rejected. The model must return citations drawn from the evidence Forge supplied; a citation to an unseen path fails grounding.

Recent messages provide conversational context, not repository proof. On a follow-up turn, Forge can reuse a prior citation only when it belongs to the same source SHA, then re-read that object. This prevents a plausible answer from silently carrying evidence across revisions.

Those limits are real tradeoffs. Instant cannot exhaustively analyze an unfamiliar monorepo in one turn, execute a failing test, or inspect three explicitly named files at once. It asks the user to narrow the question instead of pretending that bounded context is complete coverage.

Workspace Alpha is the coding tier

The first version of this design stopped at a reviewed OpenCode adapter. Forge advertised Workspace as `adapter_ready` and rejected execution because the dispatcher and publication boundary did not exist. That was more honest than showing a coding UI backed by no coding authority.

The repository now contains a restricted Workspace Alpha. It remains hidden from general users. A run requires repository write permission, the `agent:write` scope, and a matching server-owned repository/user allowlist entry. Build and Machine profiles remain unavailable.

An admitted Workspace run follows a stricter path than “start a sandbox and trust its diff”:

1. Forge materializes the exact accepted SHA into a run-scoped Cloudflare Sandbox.
2. A pinned OpenCode 1.18.11 driver receives only a short-lived token for a narrow Forge-owned model endpoint.
3. The server policy limits writable paths and allowed dependency hosts. The sandbox receives no Forge personal access token, GitHub installation token, provider master key, or deployment credential.
4. After the driver stops, Forge walks the filesystem itself. It rejects out-of-policy paths, symlinks and other unsafe file types, `.git` mutation, unsafe modes, oversized artifacts, and credential-shaped content.
5. Server-declared tests and `git diff --check` must pass in the execution sandbox. Forge then applies the inspected bytes to a fresh trusted checkout and runs the same checks again.
6. Forge rebuilds a commit whose parent is the accepted SHA, publishes only to a fenced `agent/*` branch, and creates one deduplicated draft pull request.

The duplicated verification is intentional. Output reported by an agent is a claim. Files read by Forge after execution, then reproduced in a fresh checkout, are evidence Forge can accept.

Workspace Alpha is not general availability. The source and focused tests cover admission, artifact policy, cancellation, branch publication, and draft-PR deduplication; they do not prove broad abuse resistance or production reliability. The allowlist remains part of the design, not temporary ceremony to remove once the happy path works.

The driver performs work; Forge accepts it

OpenCode is the current Workspace driver because it supplies sessions, structured events, cancellation, permissions, and usage. The earlier [agent-runtime bakeoff](/blog/the-great-agent-runtime-bakeoff) established why that driver must remain replaceable. It is not Forge's tenancy model, Git authority, approval system, or billing ledger.

That separation keeps the adapter replaceable. A later harness can implement the same driver capabilities without changing thread handles or teaching API clients a provider-specific lifecycle. Conversely, no harness receives authority merely because it exposes a convenient tool.

The same rule applies to clients. The movable repository panel, REST routes, [MCP tools](/blog/forge-agents-will-speak-mcp), and future chat connectors call the same protocol-neutral service. Browser requests use the signed-in Forge session. External clients use a personal access token or a service-principal key with explicit repository grants. A new transport does not create a privileged path.

Durable means knowing when not to retry

Forge reserves bounded platform spend before inference and settles it on completion. The terminal receipt records metadata such as compute profile, backend, driver, model, estimated tokens and cost, runner version, and a SHA-256 digest. Prompts, completions, provider credentials, and raw logs do not belong in the usage receipt.

Failure handling follows the same authority rule. A run whose lease expires before inference begins can be retried. Instant may retry one normalized provider timeout inside the same authoritative run. If inference may have happened but the outcome remains unknown, Forge marks the reservation ambiguous and fails the run instead of issuing an unbounded second job.

This plumbing is less visible than an agent loop, but it is what makes cancellation, budgets, unattended integrations, and future approval waits trustworthy.

The remaining test is operational

Several shortcuts would have produced a faster demo: read a mutable branch tip, expose provider sessions as the API, start a sandbox for every question, or let the driver publish directly. Each shortcut would move authority into a place Forge could not reliably inspect.

The current split is smaller and more useful. Each repository gets one durable coding agent. Instant handles bounded questions with almost no execution privilege. Workspace Alpha reuses the same thread and source contract while returning independently verified bytes on a fenced branch.

The next question is not whether the sandbox can edit a file. It can. The question is whether the policy, cancellation, publication, cost, and abuse boundaries hold under a broader mix of repositories and users. Until that evidence exists, Workspace should remain an Alpha.

Capability tiers will keep growing. The repository, thread, and accepted source should remain explicit, exact, and inspectable across all of them.

Read the [Forge Repository Agents V1 contract](/docs/docs/repository-agent-v1), or inspect the machine-readable [`llms.txt`](/llms.txt).