Skip to main content

Configuration

OrbCode CLI stores its state and configuration under ~/.orbcode/. Two files live there:
  • config.json — state written by the app itself (login token, chosen model, approval defaults). Created on first save, mode 0600.
  • settings.json — user-managed configuration, Claude-Code style. Created automatically as an empty {} on first run so it’s easy to find. A project-level .orbcode/settings.json in the working directory layers on top of the user-level file.

Lifecycle hooks

Block, auto-approve, rewrite, or inject context at fixed points in the agent loop

Install & authentication

First-run setup, login, and troubleshooting

File layout

Override the config directory with MATTERAI_CONFIG_DIR.

settings.json (full reference)

All keys are optional.

Precedence

For the same key, the order is:
  1. Environment variables (always win, e.g. MATTERAI_TOKEN, MATTERAI_MODEL).
  2. Project .orbcode/settings.json (in the working directory).
  3. User ~/.orbcode/settings.json.
  4. config.json (state the app wrote for itself).
For hooks, user and project files are merged — projects can add hooks without clobbering yours (see Where hooks live).

Environment variables

For the device flow, MATTERAI_BACKEND_URL and MATTERAI_APP_URL are useful against a local stack.

Custom models

customModels entries appear in the /model picker alongside the built-in Axon models. Each entry needs an id, a display name, a contextWindow, and maxOutputTokens. Optional inputPrice / outputPrice (per token) drive the status-bar cost display.

Other providers (Anthropic, OpenAI-compatible)

The Axon models go through the MatterAI gateway. A customModels entry that sets a provider is instead served through the Vercel AI SDK, reusing the same agent loop, tools, and approvals — auth is the provider’s own key (env var or apiKey), not the MatterAI login.
  • provider: "anthropic" → native /v1/messages (@ai-sdk/anthropic). Key from ANTHROPIC_API_KEY (or apiKey on the entry). Adaptive thinking and reasoning streaming are on by default; effort (lowmax) tunes depth; prompt caching breakpoints are set on the system prompt and conversation prefix automatically. Thinking blocks are preserved across turns (stored with the session and replayed with their signatures), so interleaved thinking with tool use round-trips correctly. Set "reasoning": false to disable thinking.
  • provider: "openai-compatible" → any OpenAI-compatible endpoint; requires baseUrl. Key from apiKey on the entry.
Anything without a provider (or provider: "matterai") keeps using the MatterAI gateway untouched. baseUrl only applies to the gateway path; for a custom provider, set baseUrl on the entry itself.

MCP servers

OrbCode connects to external tools via the Model Context Protocol (MCP). Servers are configured in three scopes (user, project .mcp.json, local) and their tools appear alongside the native tools as mcp__<server>__<tool>. Manage them with the orbcode mcp subcommand or the /mcp slash command. The full reference — configuration scopes, server types (stdio/http/sse), the orbcode mcp add/remove/list CLI, OAuth and static-header auth, the interactive /mcp manager, and headless-mode behavior — is on the MCP servers page.

Skills & AGENTS.md memory

  • Skills — reusable instruction sets the model loads on demand. Place a SKILL.md under ~/.orbcode/skills/ (user) or .orbcode/skills/ (project); the catalog is injected into the system prompt and use_skill loads the full body when a task matches.
  • AGENTS.md memory — project- and user-level instructions (build commands, code style, conventions) injected into every system prompt. OrbCode’s equivalent of Claude Code’s CLAUDE.md, using the open AGENTS.md filename. The repo-level file lives at .orb/AGENTS.md — the same folder the Orbital IDE extension reads — so a single source of truth covers your terminal and your editor. Use /init to generate or refine a starter file.
The full reference — creating skills, the SKILL.md format, how skills are used, AGENTS.md discovery order, and @include directives — is on the Skills & memory page.

Linked repositories

The repo-level .orb/ folder is shared with the Orbital IDE extension. It holds the two project-level files OrbCode reads ahead of every session:
  • .orb/AGENTS.md — the project’s cold-start memory (see Skills & memory). Use /init to generate or refine it.
  • .orb/links.json — linked repositories: other repos whose AGENTS.md should be considered when working in this one. Use the /link slash command (or the IDE’s /link) to add or remove entries.
links.json schema:
Resolution and validation of each path happens at read time, so links written by the CLI or the IDE stay portable. At session start, OrbCode walks the links, reads each linked repo’s AGENTS.md (from .orb/, .orbital/, or .orbcode/), and pulls them in ahead of time into the agent’s environment details — so a change here is checked for impact on, or propagated to, the linked repos.

Sessions

Sessions are stored in ~/.orbcode/sessions/<id>.json and power /resume and --resume <id>. Each session records the conversation, tool results, task title, and cost. The backend-generated task title is fetched once per task and shows in the status bar, the session file, and the terminal window title (<title> (orbcode)).

Hooks (summary)

settings.json can also declare hooks, a per-event list of shell commands that run at fixed points in the agent loop. They use the same contract as Claude Code’s hooks (stdin JSON, exit-code protocol, JSON output schema). The full reference — every event, the JSON output schema, the exit-code protocol, a copy-paste cookbook, debugging, and security — is on the Hooks page.
Project-level hooks (.orbcode/settings.json inside a repo) are disabled until you approve them in a one-time trust prompt, since they run shell commands from a repo. See Security on the Hooks page.

Troubleshooting