Synara: a local-first desktop shell for driving coding agents

Four layers that explain how the application is organised

The README opens with a table that does more explanatory work than most architecture sections. Four layers, each with one responsibility: the project holds repository context, settings and related work; the thread holds the task specific conversation, state, files and history; the provider session is the authenticated coding agent runtime actually executing the task; and workspace tools cover changes, terminal, browser, files, editor, previews and Git.

That is a useful mental model because it separates things that are easy to conflate. A thread is not a chat window, it carries files and state. A provider session is not the app, it is someone else's runtime that Synara talks to. Once you read it that way, the rest of the feature list stops looking like a shopping list of unrelated checkboxes.

The naming is also consistent with what agent tooling has converged on elsewhere. Project, thread, worktree and handoff are all terms a user will meet in other tools, so someone moving between Synara and a coding agent's own interface is not learning a new vocabulary.

The project is TypeScript, MIT licensed, on the `main` branch, with 1845 stars, 294 forks and 319 open issues, last pushed on 2026-09-20. That issue count relative to the star count is worth noticing, and comes back later.

Nine provider runtimes, none of them bundled

The integration table is the centre of the product. Codex through its CLI and app server, Claude Code, the Cursor agent runtime, Antigravity CLI, Grok Build, Factory Droid, OpenCode, Pi and Devin CLI, each described as a local integration.

The crucial detail is what the table does not say. Synara does not ship models, does not proxy requests and does not manage your subscription. It uses the provider installations and subscriptions already configured on the local machine, and the installation section says plainly that you install and authenticate the runtime you intend to use before starting a session, pointing at the Codex CLI setup for that case.

That is a defensible architecture and it has a clear consequence. Adopting Synara does not replace your existing agent setup; it sits on top of it. It also means the ceiling on what you get is the ceiling of whichever runtime you have authenticated, and that the browser automation, review and worktree features are Synara's contribution while the coding judgement stays with the provider.

The provider and model selection happens per task, so different threads in one project can run on different providers. The handoff feature exists for the same reason: moving a task to a different runtime without losing project context.

Workspace tools that sit beside the conversation

The second capability group is the reason an agent shell is more than a chat box. Five surfaces stay available from the same task view: Changes for diffs, changed files and review state, Terminal for running commands in the project environment, Browser for local previews and semantic WebMCP tools, Files and Editor for browsing and editing project files in context, and Git for branches, commits, pushes and pull requests.

The browser entry is more than an embedded preview. The README describes keeping local previews next to the thread and letting agents use semantic or page declared WebMCP tools, which is a stronger claim than screenshotting a page: the agent can be given a structured description of the interface rather than pixels. Split views and device previews, including a screenshot showing an iOS simulator next to a thread, are how the result stays part of the working context rather than something you switch away to check.

The v0.8.4 release notes add detail on the editing side, with workspace text files editable from Explorer and the full editor, and the working side editable directly from supported Git diff views, using the same Pierre and Shiki stack as the diff rendering. Review being an editing surface rather than a read only diff is a real design choice, and it is the direction the whole category is moving.

The tree shows where this lives: `apps/`, `packages/`, `scripts/`, `docs/`, `benchmarks/`, `audit/`, `evidence/` and `patches/`.

Running from source needs Bun, Node and an unusual Effect pin

The development checkout is pinned to specific toolchain versions, which is the first thing that tells you this is a project with a strict setup: Bun 1.4.2 and Node.js 24.13.1.

git clone https://github.com/Emanuele-web04/synara.git
cd synara
bun install
bun run dev

The `package.json` is the root of a Bun workspace monorepo named `@synara/monorepo`, with workspace globs for `apps/*`, `packages/*` and `scripts`. Scripts are filtered by package name through turbo: `dev:marketing`, `start:desktop`, `build:desktop` and similar each target `@synara/marketing`, `@synara/desktop`, `@synara/cli` or `@synara/server`.

The most interesting part of that file is the dependency catalog, and it deserves attention before you commit to this codebase:

"effect": "https://pkg.pr.new/Effect-TS/effect-smol/effect@8881a9b",
"@effect/platform-node": "https://pkg.pr.new/Effect-TS/effect-smol/@effect/platform-node@8881a9b",
"@effect/sql-sqlite-bun": "https://pkg.pr.new/Effect-TS/effect-smol/@effect/sql-sqlite-bun@8881a9b"

Those are not released versions. Every Effect package is pinned to a single commit hash, `8881a9b`, on a preview publishing service, from a branch called effect-smol. That is a deliberate choice by a project tracking an unreleased line, and it means `bun install` pulls a moving target rather than a stable release. It also means a future commit hash could disappear from the preview service and break a fresh install of an older checkout.

Type checking is described as TypeScript 7 with the native Effect checker across all seven workspaces, with a `postinstall` script that patches the native TypeScript package.

Automations, external MCP and the permission boundary

Automations support recurring agent runs and keep their outcomes attached to projects and threads, which is the feature that moves a tool from interactive to operational. A recurring run that leaves a trace in the thread is auditable in a way a cron job writing to a log file is not.

External MCP integrations provide scoped, user approved access for other local clients, and the README points at a dedicated document at `docs/external-mcp.md` for setup, pairing, project access and permission boundaries. That the permission story gets its own document rather than a bullet point is a good sign. An MCP server that grants another local process access to your projects is exactly the kind of thing that needs written boundaries, and `REMOTE.md`, `KEYBINDINGS.md` and `CLAUDE.md` at the root suggest the same care about the surrounding details.

Appearance is treated as a real feature area rather than an afterthought, with light and dark themes, typography controls, density preferences and workspace settings, alongside a dev server and web mode described as focused server and web modes in addition to the desktop shell.

The README states plainly that Synara is early stage software and that APIs and interface details remain under active development. Given that, the 319 open issues are less alarming than the raw number suggests: they are partly a record of a fast moving interface. They are also a reason to expect breakage between versions.

Release pace and what to expect from a project this young

The release history is the best evidence about the project's health. v0.8.4 shipped on 2026-09-14 with 108 development commits since v0.8.3, plus release preparation and validation fixes. The notes describe a browser automation foundation, saved browser sessions, guided setup, workspace editing and autosave, richer Git review, selected context conversations, provider recovery, and measured reductions in CPU work, temporary memory and streaming write amplification.

That is a fast cadence for a desktop application, and it cuts both ways. Fast means the feature set is moving quickly and that reported wins on resource use are being measured rather than assumed. It also means the version numbers are a poor guide to stability, and that upgrading weekly is a reasonable expectation rather than an aggressive one.

The native release targets are specific: Windows x64, macOS Intel, macOS Apple Silicon and Linux x64. A four platform matrix for an application coordinating external CLIs means Synara depends on those runtimes behaving consistently across all four, which is a maintenance burden the project has taken on rather than avoided.

The repository structure backs up the early stage claim in an interesting way. Alongside the expected `apps/` and `packages/` there are `benchmarks/`, `audit/`, `evidence/`, `.plans/`, `advisor-plans/` and `plans/`, plus `TODO.md` and `CHANGELOG.md`. Keeping benchmarks and evidence directories in the repository is the practice of a team that expects its performance claims to be checked.

Editorial conclusion

Synara's bet is that the agent runtimes themselves do not need replacing, only a better place to drive them from. It connects to nine provider runtimes that are installed and authenticated locally, then adds the layer most CLIs lack: a project and thread structure that survives across providers, workspace tools beside the conversation, managed worktrees for parallel work, and a review surface before changes leave your machine. It is early stage by its own admission, MIT licensed, with v0.8.4 released on 2026-09-14 after 108 development commits in a single cycle, and a repository last pushed on 2026-09-20. Grab a native build for Windows, macOS or Linux, authenticate one provider you already pay for, and try a task in a scratch repository before letting it near a project you care about.

Frequently asked questions

Official sources

1. Emanuele-web04/synara on GitHub
2. License: MIT
3. Project website
4. README
5. Releases