SynaraProvider guides
Install, authenticate, verify, and connect every coding-agent runtime supported by Synara.
Synara works with coding-agent runtimes installed on your machine. These guides explain what each runtime owns, how to verify it independently, and what Synara adds around the provider session.
Provider authentication, subscriptions, API keys, model access, and service availability remain with the provider. Synara supplies the shared workspace, task lifecycle, Git environment, terminal, browser, diff, and orchestration surfaces around that runtime.
Supported runtimes
| Provider | Default executable | Typical authentication | Steer an active turn |
|---|---|---|---|
| Claude Code | claude | Claude account, Console, Bedrock, or Vertex | Yes |
| Codex | codex | ChatGPT account, API key, or configured model provider | Yes |
| OpenCode | opencode | Credentials configured inside OpenCode | No |
| Cursor | cursor-agent | Cursor browser login or API key | No |
| Antigravity | agy | Secure keyring and Google sign-in | No |
| Grok Build | grok | Cached account session or xAI API key | No |
| Kilo Code | kilo | Kilo account or configured model provider | No |
| Pi | pi | Subscription login or provider API key | Yes |
| Factory Droid | droid | Browser device pairing or Factory API key | No |
“Steer an active turn” means Synara can inject a follow-up into supported runtimes while the current provider turn is still running. It does not mean the provider will always accept or act on the message immediately.
Choose a provider
Choose based on the runtime and account you already trust rather than assuming every provider behaves identically.
- Account access: confirm the provider works in its own terminal before debugging Synara.
- Models: Synara shows what the installed runtime and account expose.
- Permissions: approval and autonomy semantics remain provider-specific even when Synara presents them consistently.
- Session behavior: resume, compaction, plan mode, subagents, and live steering vary by provider.
- Updates: an old CLI can be installed and authenticated while still being too old for the integration Synara expects.
Shared connection workflow
Install the official runtime
Use the provider’s official installation method. Avoid similarly named third-party packages.
Authenticate outside Synara
Start the runtime in a normal terminal and complete its own login or credential flow.
Verify the executable
Run its version or status command from a fresh shell. This confirms that the executable is available through the environment inherited by desktop applications.
Enable it in Synara
Open provider settings, enable the runtime, and configure a custom binary path only when automatic discovery does not select the intended installation.
Run a bounded test task
Use a disposable repository or harmless read-only request before granting broad permissions in important work.
Provider guides
When a provider is missing
Start with the provider-specific guide, then continue to Troubleshooting. Report the executable path, version, authentication state, operating system, and the exact Synara message. Remove tokens, keys, account identifiers, and private paths before sharing diagnostics.