What these tools are, in their own words
Claude Code invites you to “Hand Claude a bug fix, test, or multi-day migration” and to “Steer and review from your terminal, IDE, Slack, or web.” It “builds the plan, asks clarifying questions, and handles work that runs for hours or days”, and it “asks for permission before making changes to your files or running commands.” Since August 2026 it “runs in auto mode by default on Pro, Max, and Team plans, so it can work longer while still catching risky commands”, and Projects let you “run and easily supervise multiple Claude agents at once.” (Source: claude.com/product/claude-code .)
Codex runs in your terminal, your IDE and the cloud, with an OS-enforced sandbox and an explicit approval policy — “When Codex must ask you before it executes an action.” By default “the agent runs with network access turned off”, and it “asks for approval to edit files outside the workspace or to run commands that require network access.” Its full-access mode is labelled “Elevated Risk” and "(not recommended)." (Source: developers.openai.com/codex .)
Both are extremely good at what they do. If you are writing code with your hands on the keyboard, neither this page nor Forge is trying to take that away from you.
The sentence that this whole page is about
It is in Codex’s own security documentation, and it is the correct advice:
“Treat Codex suggestions like any other PR: run targeted verification, review diffs, and document decisions.”
Read it again as an operations statement rather than a safety note. Verification, review and documentation are assigned to you. Claude Code says the same thing in a different register: it asks permission before it acts, and it describes you as the architect and orchestrator. Notion’s co-founder, quoted on Claude Code’s own page, puts the consequence plainly:
“A big part of my job now is to keep as many instances of Claude Code busy as possible.”
That is a real and productive way to work. It is also a description of a job that does not scale past one attentive person, and that stops entirely when that person closes the laptop.
The difference in one table
| Claude Code / Codex | Forge | |
|---|---|---|
| What an agent is | One highly capable general agent, running your task | Named roles with job descriptions — PM, architect, developer, tester, reviewer, researcher, writer — each a persona with its own memory |
| Who judges the work | You, at the approval prompt and at review time | A management agent on every handoff: pass, send back with rework instructions, or escalate to a person |
| What starts the work | You, in a session you are attending | A webhook, a schedule, a chat message, or a labelled issue |
| Where it runs | The machine you are sitting at (or the vendor’s cloud) | Your own self-hosted runners, or managed — not tied to your laptop being open |
| What is left afterwards | A diff, and a scrollback you will close | A branch: spec, brief and every role’s handoff as commits, authored by the persona |
| A rejected step | You re-prompt, and the earlier attempt is gone | A new commit; the first attempt stays in history and git diff shows what changed |
| Escalation to a human | Every risky command, to whoever is at the terminal | Only when the management agent judges a person is needed — to Telegram or Slack, with the decision attached |
| Scope | Software | Software delivery, plus research, content and operations on the same engine |
Where Forge is different
It is a team of people, not an agent
This is the part that reads as marketing until you look at a run. A Forge delivery run is not five copies of one assistant with different instructions pasted on top. It is five characters: a product manager who surfaces ambiguity instead of inventing an answer, an architect, a developer, a tester and a reviewer. Each has a name, a written job description, a stat sheet, accumulated experience and its own memory of previous work in your organisation. See Character Agents and Custom Roles .
The practical effect is not flavour. Because the roles are distinct people with distinct jobs, the handoff between them is a real event that can be inspected, judged and rejected — which is exactly what does not exist when one agent does everything in one context window. And because each handoff commit is authored by the persona, you come to know them: which one tends to over-scope, which one catches the edge case, which one keeps asking the question everyone else skipped.
Somebody independent reads the work before it moves on
Between every pair of roles sits a management agent that reads the handoff and decides: pass it on, send it back with specific rework instructions, or escalate to a person. It is not the agent that produced the work grading itself, and it is not you at 11pm. See Multi-Agent Pipeline .
This is the mechanism a single agent structurally cannot have. An agent working alone can double-check itself — and both of these tools do — but the checker and the author share a context, a plan and a set of assumptions. The whole point of a reviewer is that they do not.
Autonomy is what happens while nobody is watching
Both tools now run for hours. The difference is what starts the work and who is present. A Forge run begins because an issue was labelled, a schedule fired, a message arrived in Telegram, or another run finished — not because somebody opened a terminal. It executes on runners you own, inside credentials scoped to the run, and comes back with a pull request and a report. See Autonomous Scheduled Workflows and Isolated Stacks .
When it genuinely needs a person, it says so and waits — in Telegram or Slack, with the specific decision attached — rather than blocking on an approval prompt in a terminal nobody is looking at. See Telegram Control Plane .
The reasoning is in your repository
Every run gets a branch — forge/workflow/{workflowId}/run/{runId} — holding the spec, the original brief, and each persona’s handoff as its own commit. Six months later you can read why a decision was made, not only what shipped. You can diff a second attempt against the first, or intervene mid-run by committing a corrected handoff yourself. See Git-Backed Audit
.
It is not only software
The same engine, the same management agent and the same audit trail run a research team that verifies its own sources, a content team that publishes weekly, or an operations rotation. Software delivery is the most mature shape because it is how Forge builds itself — but it is one shape. See the jobs teams hand over .
The number a single agent cannot report
A local agent can tell you how many suggestions you accepted. It cannot tell you how often the work was sent back, because the reviewer is you and nobody is counting. Here is what it looks like when the reviewer is part of the system.
| Twelve weeks of Forge building Forge | |
|---|---|
| Runs dispatched | 322 |
| Handoffs judged by a management agent | 1216 |
| Sent back to their author for rework | 56 |
| Escalated to a human | 24 |
| Runs where the supervisor stopped at least one handoff | 51 |
| Runs that completed | 215 |
| Runs that failed, escalated or were cancelled | 103 |
| Median wall-clock, dispatch to finished run | 39 minutes |
| Median handoffs per completed run | 5 |
| Pull requests merged, across 7 repositories | 202 |
Where these came from. One workflow — Main Forge SDLC, the one that builds Forge — every run it made in twelve consecutive weeks, counted from the control plane’s own records. Not a sample and not a pilot.
Forge stopped its own work 80 times. 56 handoffs went back to their author with specific rework instructions; 24 went to a person. One run in six was interrupted by its own supervisor before any human looked at it. That is the review both vendors’ documentation correctly assigns to you — here it is priced at one model call per edge, and counted.
103 runs did not complete. We are showing you that number on the same page as the good one, because a team you can trust is one that tells you when it failed.
What we are not claiming
We are not claiming Forge writes better code. A Forge role turn is executed by exactly this class of coding agent — the difference is not the model, it is the structure around it.
We are not claiming you should stop using them. For work you are doing right now, with your hands on the keyboard and your judgement in the loop, a local agent is the better tool and Forge does not replace it. Most of our own engineers have one open.
The claim is narrower and, we think, the one that matters: the moment the work should continue without you sitting there, somebody has to hold the standard. Today that somebody is you, in a terminal. Forge makes it a role — an independent one, on every handoff, with the verdict written down.
Sources
- claude.com/product/claude-code — hero copy, auto mode, permissions, Projects, customer quotes.
- developers.openai.com/codex — approval policy, sandbox defaults, the review guidance quoted above.
- Forge claims on this page link to the corresponding feature pages , which describe the mechanism in detail.