> ## Documentation Index > Fetch the complete documentation index at: https://docs.corbits.dev/llms.txt > Use this file to discover all available pages before exploring further. # Intercode > Intercode is a terminal-based coding agent built on the Corbits agentic platform — the flagship example app that proves the runtime primitives in production. 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](/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. ```bash theme={null} 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. 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. 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. 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. 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: A seasoned-architect reviewer — checks design, constraint ownership, and backwards compatibility. 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 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`. 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. 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. 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 * Custom **reactor directors** for stall detection, plan adherence, and completion discipline * A **permission, secret, and authorization** system enforced as tool middleware * An **Ink-based terminal UI** with a live event log, diff view, and modals * Workflows, hooks, plugins, skills, and reviewer sub-agents The same primitives that make Intercode fast, safe, and resumable are the ones the platform exposes to you. The runtime primitives Intercode is built on, and how they fit together. The permission, secret, and authorization model that keeps agents in bounds. Where you build, run, and observe agents on the platform.