Synara
A local-first desktop workspace that keeps coding-agent threads, terminals, browser previews, and review tools on one surface.
- Source repo
- Emanuele-web04/synara
- Stars
- ★ 2.1k
- Last updated
- 2d ago
- License
- MIT
- Primary language
- TypeScript
- FA score
- 52/100 · Major gaps
At a glance
- How it runs
- Works with
- Portable with changesCodex · Claude Code
- Cost
- Free software; you pay for model usage
- Setup effort
- Medium · a few setup steps
- You'll need
- Typical use
- A solo developer who already has Claude Code or Codex CLI installed and wants a GUI to run several coding sessions side by side.
- Not a fit if
- Users who don't want to install and authenticate each provider CLI separately
- Teams needing stable, settled APIs — the project calls itself early-stage
- People who want a zero-install browser experience
- Source review
- 52/100 · Major gaps
What does this agent do, and when should you use it?
Synara is a local-first desktop application for coding agents that organizes work around Projects, Threads, authenticated Provider sessions, and workspace tools. It ships no model of its own; instead it connects to coding-agent runtimes already installed and authenticated on your machine — Codex CLI/app-server, Claude Code, Cursor, Antigravity CLI, Grok Build, Factory Droid, OpenCode, Pi, and Devin CLI. Each Thread holds its own conversation, state, files, and history, with provider and model selectable per task. The surrounding surfaces stay in view: Changes for diffs and review state, Terminal for project commands, Browser for local previews with semantic or page-declared WebMCP tools, Files/Editor for project files, and Git for branches, commits, pushes, and pull requests. Managed worktrees isolate parallel work and provider handoffs carry context when a task moves to another toolchain; Automations run agents on a schedule and external MCP gives other local clients scoped, user-approved access. Releases target Windows x64, macOS Intel/Apple Silicon, and Linux x64, with server and web modes plus an MIT license, and the README states the software is early-stage with APIs still in flux.
A Project anchors repository context; each task becomes a Thread bound to one authenticated Provider session (Codex CLI, Claude Code, Cursor, and others) that actually executes the work. The Changes surface reads diffs, changed files, and review state from the workspace; Terminal runs commands in the project environment; Browser keeps local previews beside the thread and lets agents call semantic or page-declared WebMCP tools; Files/Editor browses and edits project files; Git handles branches, commits, pushes, and pull requests. Split views and device previews place the conversation next to the surface it is modifying. Threads run in a local checkout or an isolated managed worktree to prevent parallel edits colliding, and a handoff moves an unfinished task to another provider without losing project context. Automations trigger recurring runs and attach outcomes to projects and threads, while external MCP integration exposes scoped, user-approved project access to other local clients as described in docs/external-mcp.md.
- A solo developer who already has Claude Code or Codex CLI installed and wants a GUI to run several coding sessions side by side.
- A full-stack engineer who wants to review diffs and pull requests in a split view while the agent keeps editing code.
- A mobile developer validating agent changes against an iOS simulator device preview without leaving the thread.
- A team running several tasks on the same repository that needs managed worktree isolation to avoid overwriting each other.
- A user who wants to hand an unfinished task from Codex to Claude or Cursor while keeping its project context.
- A maintainer who wants scheduled agent runs and their outcomes tracked against projects and threads.
How do you install or deploy this agent?
The primary path is a desktop build. Current native release targets are Windows x64, macOS Intel, macOS Apple Silicon, and Linux x64:
https://github.com/Emanuele-web04/synara/releasesRunning from source requires Bun 1.4.2 and Node.js 24.13.1; workspace Git features require Git 2.29 or newer:
git clone https://github.com/Emanuele-web04/synara.git
cd synara
bun install
bun run devBefore starting a session, install and authenticate the runtime you intend to use; for Codex sessions follow the Codex CLI setup:
https://github.com/openai/codexType checking uses the repository's named scripts rather than a bare tsc:
bun run typecheckHow do you use this agent?
Install and log in to at least one coding-agent runtime first. Open Synara, create or pick a Project pointing at your local repository, then start a Thread and choose the provider and model. Work in the Changes panel to inspect diffs and review state, run commands in Terminal, check local builds in Browser, and use Git for branches, commits, pushes, and pull requests. Enable split views or device previews when you want the conversation next to the surface it is changing. Use provider handoff to continue a task under another runtime, follow docs/external-mcp.md to pair other local clients with scoped project access, and set up Automations for recurring runs.
What are this agent's strengths and limitations?
- Wraps nine coding runtimes (Codex, Claude Code, Cursor, Antigravity, Grok, Droid, OpenCode, Pi, Devin) behind one interface that switches per thread.
- Keeps diffs, terminal, browser preview, files, and Git next to the conversation, so review stays in the same task surface.
- Managed worktrees give parallel threads an isolation boundary instead of racing on one checkout.
- External MCP access is gated by pairing, project scope, and user approval rather than being open by default.
- Native installers for Windows, macOS Intel/Apple Silicon, and Linux x64, plus source, server, and web modes.
- MIT licensed, so the code can be audited and modified.
- No bundled model: you must install and authenticate each provider CLI yourself, and capability tracks whatever those runtimes support.
- README labels it early-stage software with APIs and interface details still under active development.
- Workspace Git features need Git 2.29+, and ahead/behind counts can lag up to 60 seconds after a background refresh.
- Building from source needs both Bun 1.4.2 and Node.js 24.13.1, and per-workspace tsc invocations are not supported.
- The native Effect checker does not currently enforce the importFromBarrel rule, and the legacy check is not run in CI.
How does this agent compare with similar options?
Key facts side by side with the most closely related agents.
| Agent | Source review | Form / cost | Stars | Updated | Language | Full support on |
|---|---|---|---|---|---|---|
| Synara This agent | 52 · Major gaps | Desktop appFree + model costs | ★ 2.1k | 2d ago | TypeScript | Codex · Claude Code |
| zerostack | 57 · Major gaps | CLIFree + model costs | ★ 1.7k | today | Rust | OpenAI API · Claude API |
| iPolloWork | 44 · Major gaps | Desktop appFree + model costs | ★ 7.1k | 1d ago | TypeScript | — |
| Forge Terminal Coding Assistant | 46 · Major gaps | CLIFree + model costs | ★ 7.6k | 1d ago | Rust | OpenAI API · Claude API |
How does FollowAgents rate this agent?
Why each dimension lost points
Least privilege: README and CUA docs show Computer/AppSnap requesting Accessibility, Input Monitoring and Screen Recording on demand, with status checks not triggering capture or control (2). User confirmation: external MCP is 'scoped, user-approved', Computer must be explicitly enabled per chat, and approval requests surface in the task (2). Data-flow transparency: only general local-first and local-provider-credential statements; no concrete description of data destinations, logs or telemetry (1). Sensitive data: docs note tokens and provider credentials are not persisted in the routing file, but there is no systematic credential storage/encryption description (1). Dependency security: package.json pins many Effect packages to pkg.pr.new commit snapshots plus several patchedDependencies, an unreproducible/unaudited source; overrides pin some transitive deps but the deduction stands (1). External effects: Git push/PR and terminal execution are paired with diff review guidance, but automation and background-refresh side effects are thinly described (2). Rollback: worktree isolation, diff review and a canary rollback script exist, but no user-facing undo/recovery guidance (1). Source attribution: MIT and copyright holders are clear, but publisher is unverified and many 'local tests passed' claims lack external corroboration (1).
Self-consistency: README, quickstart and CUA docs describe the workflow and permission flow consistently, and explicitly flag historical vs current guides (2). Dependency availability: reliance on pkg.pr.new Effect commit snapshots, patchedDependencies and specific Bun/Node versions makes offline or upstream-change availability uncertain (1). Failure messages: CUA docs record concrete TCC failures, cdhash mismatch and missing-module errors with recovery paths (2).
Audience and scenarios: targets developers using local coding agents; quickstart gives a five-step flow with an example task (2). Capability boundaries: lists supported provider runtimes, platform targets and 'no separate model plan', and states the local capability is not a sandbox (2). Trigger precision: automation trigger conditions and MCP tool-call boundaries are not precisely specified (1). Environment fit: states Windows/macOS/Linux targets, Git 2.29+, Bun/Node versions (2).
Information architecture: README is well layered with TOC, capability tables and install sections (2). Install notes: desktop download, source run, provider setup and typecheck scripts are documented (2). Naming stability: README self-describes as early-stage with APIs and UI under active development (1). Examples and FAQ: quickstart example task exists, but no FAQ (1). Known limitations: explicitly lists early-stage status, native typechecker missing importFromBarrel, and CUA boundary (2). License: full MIT text with copyright holders (3). Versioning/changelog: no CHANGELOG, only an external changelog link (1). Maintenance responsibility: copyright holders named, but publisher unverified and no clear maintainer/SECURITY contact (security disclosure is a TODO draft) (1).
Output usability: workflow centers on diff review, test re-run and commit, producing shippable output (2). Marginal value: integrates multi-provider sessions, worktree isolation and review tools, adding value for multi-agent workflows (2). Cost-benefit: snapshot dependencies and a complex toolchain raise maintenance cost; docs do not quantify resource or billing impact (1).
Claim traceability: CUA docs cite specific commits, PRs, cdhash and log paths; README cites Git release notes (2). Cross-source corroboration: verification is mostly local logs, and in-repo tests mainly cover marketing-site UI, not core agent behavior (1). Fact/inference separation: docs explicitly distinguish verified vs unverified, e.g. 'no live permission prompts performed' and 'does not prove a real TCC transition' (2).
- Many dependencies point to pkg.pr.new Effect commit snapshots and patchedDependencies, making builds non-reproducible and unaudited; assess supply-chain risk yourself.
- Publisher identity is unverified and the security disclosure policy is still a TODO draft, with no usable reporting channel or named owner.
- Computer use can capture the screen and deliver synthetic input; docs admit it is not a sandbox against same-user malware, so confirm permission scope before enabling.
- In-repo tests mainly cover marketing-site UI; core agent behavior and permission flows are verified only via local logs and cannot be independently checked.
- README self-describes as early-stage with APIs and UI subject to change, and there is no CHANGELOG or versioning documentation.