Skip to main content
Intercode is a single-process, terminal-based coding agent. You give it a task in plain English and it works autonomously — reading files, writing code, running tests, and driving a feature to completion — backed by an OpenAI-compatible LLM. It is also the clearest proof that the Corbits agentic platform holds up under real load. Intercode is not a demo stub: it is a production coding agent assembled entirely from the platform’s runtime primitives, then layered with the discipline, safety, and UX that make an agent trustworthy. If you want to see what you can build on the platform, this is the reference.
Intercode is built on the same Corbits/Interchange runtime documented across the platform overview. It is a consumer of those primitives, not a fork — the same building blocks are available to you.

​
Run it

Point Intercode at a repository and describe the work. It launches a full-screen terminal UI seeded with your task and starts implementing. 
intercode "Add JWT auth to the API"
From there you steer in chat: answer the agent’s clarifying questions, approve consequential actions, and follow along in the live event log as it edits files and runs commands.

​
What makes it different

Most coding agents stall. They loop on “thinking,” re-read the same files, drift from their own plan, or never signal that they are done. Intercode replaces the open-ended chat loop with a deterministic event loop governed by a custom reactor director — a policy layer that watches every turn and decides what happens next.

Progress or intervention

Every turn is expected to make progress. The director counts consecutive turns that produce no tool call, checkpoints state, and steps in to break a stall rather than spinning forever.

Re-read blocking

The director tracks which files were read on which turn. Redundant re-reads of a file it already has are blocked, so the agent spends its context moving forward instead of re-scanning.

Plan as contract

The agent commits to a structured plan up front. That plan lives in durable director state — not just the chat transcript — so it survives context shifts and stays enforceable across a long run.

Deterministic loop

The reactor processes one event at a time and yields a single, deterministic next action. Policy is code, not a suggestion buried in a prompt.

​
Safety you can’t talk it out of

Intercode enforces safety at the tool layer, as middleware wrapped around every tool call — not as advisory text in a prompt the model can reason around. One layer owns each constraint, and the agent cannot evade a constraint by rewording its request.
Read-only tools (reading files, searching, listing directories) run freely. Every consequential tool — file writes, edits, shell commands — is gated. You approve with Allow Once or Allow Always, scoped to a file, a directory, or a command shape. “Allow Always” choices persist per repository, so repeat actions stop interrupting your flow.
Sensitive files — .env, private keys, .ssh, credential stores, and Intercode’s own settings files — can never be read or written by the agent. This is a hard deny that runs before the permission gate, so it holds even under --dangerously-skip-permissions. Template files like .env.example are exempt.
A curated set of unrecoverable commands is blocked before it runs — filesystem creation (mkfs), raw disk writes (dd to a device), recursive deletes that target the filesystem root, your home directory, or a system tree, writes that clobber system paths like /etc, privilege escalation (sudo), power-state changes (shutdown, reboot), fork bombs, and piping a network download straight into a shell (curl … | bash). Like the secret guard, this deny cannot be overridden — not even with --dangerously-skip-permissions. Everyday destructive commands like rm -rf ./build aren’t hard-denied here; they go through the permission gate like any other consequential command.
Path arguments are resolved against the working directory; paths that escape it are blocked. After every write or edit, the file is re-read and compared to confirm the change actually landed.
Consequential actions run through an ask/auto behavior at the permission gate, so you decide how much to approve interactively versus let run. Whatever that setting, the secret and catastrophic guards remain non-negotiable.

​
Resume where you left off

Conversation context persists to a git-backed store, and director state (turns used, plan, tasks, files read) is snapshotted alongside it. When you relaunch in a repository, Intercode can present a session picker in the TUI so you pick up a prior run from exactly where it stopped — no lost context after a Ctrl+C, a crash, or a walk away from the desk.

​
Reviewer sub-agents

Intercode ships built-in sub-agent profiles the agent can dispatch for a self-contained subtask on a separate inference source:

greybeard

A seasoned-architect reviewer — checks design, constraint ownership, and backwards compatibility.

critique

A code-quality reviewer — tests assumptions, hunts edge cases, and flags security smells and untested paths.
You can add your own profiles in the project tree or through agent plugins; the agent discovers them and picks the right specialist for the job.

​
Integrations

MCP servers

Connect Model Context Protocol servers over stdio (launched as a subprocess) or HTTP (a remote Streamable-HTTP endpoint, authorized via OAuth). Configure them per repo and inspect connected servers with /mcp.

Lifecycle hooks

Config-driven postTurn and postRun hooks — shell or TypeScript — run automatically. postTurn receives aggregated turn context; postRun receives a run summary. Discovered per repo and globally.

Plugins and skills

Opt-in capabilities enable per workspace — web search, additional tools, workflow recipes. Skills are Markdown capability packages the model loads on demand rather than commands you invoke.

Slash commands

An extensible in-TUI command surface — /model, /settings, /permissions, /plugins, /login, /mcp, /clear, and more. Plugins can register their own.

​
Configuration and credentials

Intercode reads its provider and credential configuration from settings files only:
Global settings live in ~/.intercode/settings.json (providers and credentials). A per-repo .intercode/settings.json handles selection only — it chooses a provider and model and rejects stored secrets.
Credentials come exclusively from these files. There is no environment-variable override and .env files are not loaded, so a stale or exported key can never silently shadow the configured provider. Both settings files sit on the secret-guard denylist — the agent cannot read its own credentials.

​
Built on the platform

Intercode is the honest test of the platform: everything the runtime provides, it composes; everything it adds sits cleanly on top. That layering is the story.
  • Agent loop — the event-driven reactor and agent lifecycle
  • Inference — OpenAI-compatible inference with an SSE adapter
  • Tools — sandboxed POSIX shell, file read/write/edit, grep, and search
  • Persistence — git-backed context and state storage for resume
The same primitives that make Intercode fast, safe, and resumable are the ones the platform exposes to you.

Platform overview

The runtime primitives Intercode is built on, and how they fit together.

Guardrails

The permission, secret, and authorization model that keeps agents in bounds.

Workbench

Where you build, run, and observe agents on the platform.