Skip to main content

Documentation Index

Fetch the complete documentation index at: https://mintlify.com/Emanuele-web04/synara/llms.txt

Use this file to discover all available pages before exploring further.

Synara is built around a provider model: every AI coding session is driven by a CLI agent that runs as a child process on your machine. Synara orchestrates the full lifecycle — launching the process, routing messages, surfacing approvals, managing context windows, and checkpointing changes — while each provider retains its own authentication, model roster, and tooling. You bring the CLI; Synara brings the workspace.

​
Supported providers

Eight providers are available today. Click any card to read the full setup guide.

Codex

OpenAI Codex CLI — GPT-5 series models with configurable reasoning effort.

Claude Code

Anthropic’s Claude Code CLI — Opus, Sonnet, Haiku with extended thinking.

Gemini

Google Gemini CLI — Gemini 2.5 and 3 series with thinking levels.

Grok

xAI Grok CLI — Grok Build models with reasoning effort control.

OpenCode

OpenCode — open-source multi-model coding agent.

Cursor

Cursor Agent — Cursor’s AI coding agent interface.

Kilo

Kilo — Kilo Code’s agentic coding engine.

Pi

Pi — lightweight local coding agent.

​
Common provider concepts

Every provider in Synara shares the same configuration shape and runtime contract. Understanding the shared concepts makes it easy to move between providers or run several side by side.

​
Binary path

Each provider exposes a binaryPath setting in settings.json under providers.<name>.binaryPath. This is the command Synara uses to spawn the provider process. The default value is the conventional binary name for each CLI (e.g. "codex", "claude", "gemini", "grok"), which works when the binary is on your PATH. Set a full absolute path if your installation lives elsewhere or if you want to pin to a specific version. 
{
  "providers": {
    "codex": {
      "binaryPath": "/usr/local/bin/codex"
    }
  }
}

​
Approval policy

ProviderApprovalPolicy controls when Synara interrupts a running session to ask you whether a proposed action (file write, shell command, etc.) should proceed.
ValueBehaviour
untrustedEvery action requires explicit approval before it runs.
on-failureSynara approves actions automatically; you are asked only if a step fails.
on-requestThe provider itself signals that approval is needed; Synara surfaces the prompt.
neverActions are never held for approval — the agent runs fully autonomously.

​
Sandbox mode

ProviderSandboxMode defines the filesystem and execution scope granted to the provider process.
ValueBehaviour
read-onlyThe provider may read files but cannot write, create, or delete.
workspace-writeThe provider may read and write within the project workspace root.
danger-full-accessNo restrictions — the provider process inherits your full user permissions.

​
Session status lifecycle

Every thread has an associated OrchestrationSession whose status field reflects where the provider process is in its lifecycle. idle → starting → ready → running → interrupted → stopped → error Synara surfaces the current status in the thread sidebar so you can tell at a glance whether a provider is warming up, actively processing, or has encountered an error.

​
Model selection

Each thread carries a ModelSelection that binds a specific provider and model slug together with optional model-level options (reasoning effort, thinking level, context window size, etc.). You can change the model selection per thread at any time; the new selection takes effect on the next turn. See the individual provider pages for the full model roster and available options for each provider.

​
Provider discovery on startup

When Synara starts, it probes each enabled provider to confirm the binary is reachable and, where supported, to discover the models available from the live CLI. For Gemini, this involves an ACP (Agent Communication Protocol) handshake; for Codex, Synara checks the installed CLI version against the minimum supported version (0.37.0). The result of each probe is reflected in the provider status indicator in the Synara UI. Providers that are disabled (via "enabled": false in settings) are skipped entirely during discovery. See Configuration & Settings for the full settings reference.
You must have each provider CLI installed and authorized on your machine before Synara can use it. Synara never stores your API keys or tokens — authentication is handled entirely by the provider CLI itself.

Build docs developers (and LLMs) love

Get started for freeTalk to us