Skip to content
v0.1.0Open source, MIT licensed

Your AI software engineer, in the terminal.

Forge explores your codebase, plans the work, writes the code, runs the tests, and iterates until the task is done.

$ curl -fsSL https://forge.tusharumbarkar.space/install.sh | sh

macOS and Linux · Python 3.11+ handled for you · no account required

A real session

One task in, tested code out.

Not a mock-up of a chat window. This is the CLI's own output.

~/projects/api - forgeworking
01

It looked first

Status, layout, entry point - before touching a file.

02

The suite failed

A non-zero exit and the assertion came back as a result.

03

It fixed the cause

Named the wrong assumption, corrected it, re-ran.

The difference

Not a chatbot.

A chat window returns an answer. Forge is judged on whether the repository works afterwards.

Chat
promptansweryou do the rest
Forge
taskexploreedittestiterateworking code
The loop

From task to tested code.

Seven stages, and the last one feeds back into the middle. That is the whole reason it finishes work instead of describing it.

  1. 01

    Understand

    The task arrives as one sentence, resolved against the repo you started in.

    gather_environment()
  2. 02

    Explore

    It reads the layout, the toolchain, and the git state before touching anything.

    read_file · list_directory · search_files
  3. 03

    Plan

    It states what it believes is wrong, then makes the smallest change that tests that.

    form a hypothesis before editing
  4. 04

    Implement

    Targeted edits, whole files, or patches - every path confined to the workspace.

    edit_file · write_file · apply_patch
  5. 05

    Test

    Done means a command proved it works, not that an edit applied.

    shell
  6. 06

    Inspect

    Exit codes, stdout, and stderr come back as data, not as a crash.

    exit_code · stderr
  7. 07

    Iterate

    It reads the failure and adjusts, up to a hard iteration ceiling.

    max_iterations
  8. A failure goes back to Explore, not to you. It never claims a success it did not verify.

Capabilities

What it actually does.

All of it is in the CLI today. Anything that is not, says so.

Repository understanding

It finds your toolchain, layout, and git state before the first edit.

Autonomous execution

Runs your tests, builds, and linters, and reads what came back.

Code modification

Exact edits, whole files, or unified diffs - confined to the workspace.

Test and verification

A task is done when a command proves it, not when an edit applies.

Git awareness

Status, diffs, staging, commits, branches. Never push - that stays yours.

Developer control

Three approval modes and a risk level on every call.

Also: Docker sandboxing, --json output for CI, and any Anthropic-compatible gateway.Coming soonMCP servers.

Terminal-native

The terminal is the interface.

Not an editor plugin. Your tests, linters, and git are already on your PATH, so Forge uses them directly - and composes with pipes, scripts, and CI the same way anything else does.

shell
# a session in the repo you're standing inforge # one task, then exitforge "fix the failing test in tests/test_auth.py" # somewhere else, approving every write yourselfforge -C ~/work/api --cautious "add a /healthz endpoint" # machine-readable, for CI or a git hookecho "run ruff and fix what it reports" | forge run --json

exit 0 completed · 1 unfinished · 2 misconfigured · 130 interrupted

Control

You stay in control.

Every tool call is routed through a permission check before it runs - not an instruction in a prompt the model can talk itself out of.

modereadwritedestructive
cautiousautomaticaskask
autodefaultautomaticautomaticask
yoloautomaticautomaticautomatic

Some commands are refused in every mode, including --yolo: git push, sudo, rm -rf /. Your config can add to that list; it cannot shorten it.

Or hand it a container instead of your machine - --sandbox docker caps CPU, memory, and processes, and turns networking off.

approval - git reset --hardworking
Architecture

One path from request to result.

Every call the model makes goes through the same pipeline, in this order. No tool skips the permission check because skipping it was convenient.

  1. tool callwhat the model asked for
  2. lookupunknown → error result
  3. permissiondeny · allow · ask
  4. validateagainst the schema
  5. executetimeout-guarded
  6. resultback into the loop

An unknown tool, bad arguments, a refusal, a timeout, a crash - each becomes a result the model can read and recover from, never an exception that ends the run. How it is put together.

Install

Install in seconds.

One command. It installs uv if you need it, fetches its own Python if you need that too, and leaves the rest of your system alone.

$ curl -fsSL https://forge.tusharumbarkar.space/install.sh | sh

Installs uv if needed, then installs Forge as an isolated tool. macOS and Linux.

Rather read it first? curl -fsSL https://forge.tusharumbarkar.space/install.sh -o install.sh - it is one plain sh file.

then
export ANTHROPIC_API_KEY="sk-ant-..."export ANTHROPIC_MODEL="claude-sonnet-4-5" forge

No account and no server of ours. You bring a model credential, Forge uses it directly.

macOS and Linux (Windows via WSL2) · Python 3.11+ · v0.1.0 · MIT

Roadmap

Version 0.1.0, and it says so.

Everything on the left runs today. Nothing on the right is claimed anywhere else on this site.

Today

shipped
  • Terminal-native agent loop with an interactive session and a scriptable one-shot mode
  • Filesystem tools confined to the workspace root
  • Shell execution with timeouts and truncated, structured output
  • First-class git tools with typed schemas and shell-quoted arguments

Next

not built yet
  • Additional model providers behind the existing provider interface
  • MCP server support, registered through the tool registry
  • Explicit plan/act separation for larger tasks
The full roadmap

Free and open source.

MIT licensed. No accounts, no seats, no telemetry. You pay whoever provides your model, and that is the whole cost.