Skip to content

Configuration

SuperQode uses two complementary configuration files:

  • superqode.yaml stores project defaults, provider hints, ACP agent definitions, MCP servers, aliases, and gateway settings.
  • HarnessSpec files such as harness.yaml store run behavior: runtime, model policy, tools, sandbox, approvals, checks, hooks, events, and output.

Most developers can start with superqode config init, then run :local init inside the TUI to generate superqode.local.yaml for the machine they are using.

Why There Are Two Files

superqode.yaml answers: what is configured for this project or machine?

Use it for provider definitions, API key environment variable names, local endpoints, MCP servers, memory providers, aliases, and default connection hints. It is created by:

superqode config init

harness.yaml answers: how should this agent run behave?

Use it for the runtime backend, model policy, tool access, sandbox, approvals, checks, hooks, workflow, events, and output contract. It is created by commands such as:

superqode harness init my-coder --template coding --output harness.yaml
superqode local init --repo .

superqode.local.yaml is also a HarnessSpec. It is the local-first harness generated by :local init or superqode local init --repo ..

The files compose at runtime. A harness can say which model family, runtime, tools, and approval policy to use. superqode.yaml supplies the project environment around it, such as provider endpoints, MCP servers, memory configuration, and project defaults. A harness is not active just because it exists. Load one with superqode --harness harness.yaml, superqode --harness superqode.local.yaml, or :harness <path> inside the TUI.

File Purpose Created by
superqode.yaml Project or machine configuration superqode config init, :init
.superqode/harnesses/coding.yaml Starter local-first coding harness created with project config superqode config init, :init
harness.yaml Portable run contract you create and version superqode harness init ..., superqode harness wizard
superqode.local.yaml Hardware-tuned local model harness superqode local init --repo ., :local init
superqode.airplane.yaml No-network local harness for offline work superqode local airplane prepare, :local airplane prepare

Create Project Config

cd /path/to/project
superqode config init

SuperQode looks for config in this order:

Priority Path Scope
1 ./superqode.yaml Project
2 ~/.superqode.yaml User
3 /etc/superqode/superqode.yaml System

Minimal Config

For the local-first default:

superqode:
  version: "1.0"
  team_name: "My Project"

default:
  mode: local
  provider: ollama
  model: qwen3:8b

providers:
  ollama:
    base_url: http://localhost:11434
    recommended_models:
      - qwen3:8b
      - qwen3-coder:30b-a3b
      - gemma4:e4b

For a hosted provider:

superqode:
  version: "1.0"
  team_name: "My Project"

default:
  mode: byok
  provider: openai
  model: <openai-model>

providers:
  openai:
    api_key_env: OPENAI_API_KEY
    recommended_models:
      - <openai-model>
      - <openai-fast-model>

For an ACP agent:

superqode:
  version: "1.0"
  team_name: "My Project"

default:
  mode: acp
  agent: opencode

agents:
  opencode:
    description: OpenCode coding agent
    protocol: acp
    command: opencode

coding_agent is still accepted for compatibility, but new config should use agent for ACP defaults.


Add A Harness

Create a reusable harness when you want the same runtime, tool, sandbox, and approval policy across runs:

superqode harness init my-coder --template coding --output harness.yaml
superqode harness doctor --spec harness.yaml
superqode harness run --spec harness.yaml --prompt "summarize this repository"

Load the same harness in the TUI:

superqode --harness harness.yaml

Or from inside the TUI:

:harness harness.yaml
:harness status

Common Config Commands

superqode config init
superqode config init --force

Harness commands:

superqode harness list-templates
superqode harness validate --spec harness.yaml
superqode harness inspect --spec harness.yaml
superqode harness compile --spec harness.yaml --json

Provider Settings

Providers are configured by ID. API keys should be stored in environment variables, not in YAML.

providers:
  anthropic:
    api_key_env: ANTHROPIC_API_KEY
    recommended_models:
      - <anthropic-model>

  google:
    api_key_env: GOOGLE_API_KEY
    recommended_models:
      - gemini-flash-latest

  ollama:
    base_url: http://localhost:11434
    recommended_models:
      - qwen3:8b

Check setup:

superqode providers doctor
superqode providers doctor openai --json
superqode providers guide ollama
superqode providers recommend coding

MCP Servers

Use mcp_servers for Model Context Protocol servers:

mcp_servers:
  filesystem:
    transport: stdio
    enabled: true
    auto_connect: true
    command: npx
    args:
      - -y
      - "@modelcontextprotocol/server-filesystem"
      - "."

SuperQode also accepts mcpServers for compatibility with common MCP config formats.


Environment Variables

Variable Purpose
SUPERQODE_PROVIDER Default provider for headless runs
SUPERQODE_MODEL Default model for headless runs
SUPERQODE_SANDBOX Local command sandbox mode
SUPERQODE_SEARCH_ROOTS Extra read-only search roots outside the workspace
SUPERQODE_DS4_WARMUP Set 0 or false to skip DS4 warm-up
OPENAI_API_KEY OpenAI API key
ANTHROPIC_API_KEY Anthropic API key
GOOGLE_API_KEY Google API key
DEEPSEEK_API_KEY DeepSeek API key

What Belongs Where

Setting Put it in
Default provider or local model superqode.yaml
API key environment variable names superqode.yaml
MCP server process definitions superqode.yaml
Runtime backend for a repeatable run HarnessSpec
Allowed tools and shell access HarnessSpec
Approval rules and sandbox policy HarnessSpec
Project checks HarnessSpec
Event storage and output schema HarnessSpec

Next Steps