同步工具

Install

macOS only, deliberately. The window is drawn against macOS materials — the underWindowBackground material behind the frame, the title bar the header occupies, the traffic lights placed by hand, the Dock menu, the system speech synthesiser. Some of that degrades honestly on other platforms and some of it does not, and nobody has yet launched a Linux or Windows build to find out which. Shipping an installer nobody has opened would be a worse answer than shipping none. The pipeline still builds one from a single matrix row — see docs/releasing.md.

Sync updates itself: it looks once at each launch, verifies what it finds against a key compiled into the binary, installs it and says nothing. The next launch is the new version, and the menu bar item offers a restart to anybody who would rather not wait. Nothing about that flow is reachable from the window's content.

The iPhone application is built from source. It lives in src-mobile/ — its own Cargo workspace, showing the same static export the Mac shows — and this release page carries the macOS installer only. `pnpm tauri ios dev "iPhone 17 Pro"` puts it on a simulator. The two carry one version deliberately: somebody holding both should be able to say which is older without learning two numbering schemes.

Upgrading from the earlier Sync? Read If you came here looking for the old Sync first: the two share no settings and no data, and one thing does break on the agent's side.

Building it

Prerequisites: macOS 13+, Xcode Command Line Tools, Node.js 20.9+ (built on 22), pnpm 11 (corepack enable picks up the packageManager field), and Rust 1.91 or newer — the floor the workspace states, because Cargo resolves one graph against the lowest one in it and a lower floor picks dependency versions the engine cannot build with.

pnpm install       # from the lockfile
pnpm tauri dev     # build and run the application
pnpm tauri build   # produce the installer

pnpm lint          # eslint
pnpm typecheck     # tsc --noEmit
pnpm api:check     # the extension surface, and the number it is promised under
pnpm prose:check   # the prose rules a machine can hold — see AGENTS.md
pnpm build         # static export to ./out

pnpm tauri:build is the same bundle with the system's PATH in front: the step that clears the quarantine attribute calls xattr, and a different one earlier on your path fails the build after everything has compiled.

For the Rust side, from src-tauri:

cargo fmt --all -- --check
cargo clippy --workspace --all-targets -- -D warnings
cargo test --workspace

The phone is a second application rather than a second target of the first, so it has its own workspace and its own commands, which go through scripts/tauri.mjs:

pnpm tauri ios dev "iPhone 17 Pro"   # onto a simulator
pnpm tauri ios build                 # onto a device

Build the memory sidecar before bundling. sync-mcp ships inside the bundle as a Tauri externalBin; it links the memory engine as a library rather than spawning it, and serves three doors from one dispatcher — an agent gets MCP, the window and the clock get a channel of product operations that is not MCP and appears in no tools/list, and a paired device gets that same channel over an encrypted connection.

./scripts/prepare-sidecar.sh                        # build it from this workspace
./scripts/prepare-sidecar.sh --from /path/to/binary # stage one already built

The engine is pinned to a tag in sync-mcp's manifest and resolved from GitHub like any other dependency, so a clean checkout builds exactly what a release is cut against and needs no directory beside it. In development, point Sync at your own build with SYNC_MCP_BINARY=/path/to/sync-mcp — there is no search of PATH, because a stray sync-mcp would carry a different engine inside it and nothing would say so.

A desktop environment where agents do the work

⬇  Download for macOS · sync.buzz · Write an extension · How it is put together

</div>

<img src="assets/brand/window-anatomy.png" alt="The Sync window drawn as four labelled columns — the primary sidebar holding the areas a package added, the context navigator holding what belongs to the selected area, the workspace holding the record as the text it is, and the context inspector holding what is true of it. Beneath them: what a project knows is kept in the repository's own Git objects, agents reach it over MCP or are driven from the window over ACP, and every piece of subject matter arrives as a package.">

Open a folder on your Mac and it becomes a project. The agent you already use works inside it, and everything the project learns is written to that folder's own Git repository — where it branches, merges, travels to whoever clones it, and belongs to you.

What kind of work is up to you. Sync is a shell. It holds what every kind of work needs — projects, the agents that act on them, the permissions those agents run under, a clock that keeps going when the window is closed, and a store of what the project knows that says when it has gone out of date. What a project is about comes entirely from the packages installed into it.

No package is privileged, and the application ships none. Nothing is bundled and nothing is unpacked at launch: every package in the catalogue arrived the way yours will — built outside this repository, declared in a manifest, fetched from a registry and installed into a project that asked for it. There is no src/extensions/ directory here and CI fails the build if one appears, so the shell cannot name a section in a type or a constant even by accident. That rule is the whole design — it is what makes the environment yours to shape rather than ours to extend on your behalf.

What the shell guarantees, so a package does not have to:

- A project is a repository, and everything it knows is written to that repository's own Git objects. It branches, merges, travels to whoever clones it, and belongs to you. No account, no server of ours. - What it knows says when it has rotted. A record names the files its claim is about; the engine reconciles them against the repository's history and marks the claim stale when they move. Not a review date somebody set and forgot — derived, every time it is read. - Agents, in both directions. Seven clients are connected with one control and work against the project through Sync's own server — Claude Code, Codex CLI, Grok CLI, Claude Desktop, Cursor, Visual Studio Code and Zed. Or drive an agent from the window over ACP, with its plan, its tool calls and its permission prompts drawn as part of the interface: five CLIs are measured and raised by name. - Work outlives the window. A package can declare handlers on a clock and order work that runs with nothing open, under permissions it declared and a person approved, attributed to whoever asked for it. A conversation can hand work to another conversation and be handed back the answer. - What a package needs of the machine, it asks for by name. Fourteen capabilities, each a promise about behaviour rather than a switch: the network with its hosts written out and no wildcard, a corner of the system keychain, a shell in a folder, a handler on a clock. A missing one is a refusal with a sentence a person can act on, never a silent degradation. - The window is not only at the desk. The iPhone application shows the same window arranged for a phone, and every call it makes is answered by the very function the Mac's own window calls — so a conversation started at the desk is continued on the phone, because there is only ever one conversation.

Structured knowledge that stays honest, agents that act on it, and an environment you assemble rather than accept.

Pre-1.0 and under active development. Used daily on the machine it is built on, and not finished. What is here works; what is absent is absent rather than stubbed. See Where it stands.

Everything a project can do is a package

Sync is a shell. There is no src/extensions/ directory in this repository, and CI fails the build if one appears — every section of the project's window is a package, built elsewhere, installed through the same path a stranger's extension is installed through. One row of the sidebar is the window's own, and it is the catalogue: where a person decides which sections the project has. That rule is the whole design: a window that could name one section in a type or a constant would treat that section differently from yours.

A package declares what it needs, and a build publishes what it can do. The fourteen capabilities today:

records · agents.acp · markdown.plugins · native-menu · folders · sheets · net · net.write · vault · background · schedule · work.agent · agent.tools · terminal

A missing one is a refusal with a sentence a person can act on, never a silent degradation. net is the one that is a capability and a list: a package that wants the network names the exact hosts, without wildcards, and every redirect is checked against the same list. Four of the fourteen are things that have to happen where the screen is — raising a session, a keychain, a shell, a system menu — so a phone honours ten, and a package that needs one of the other four is drawn in its list with the reason it cannot open there. It stays installed: what a manifest is checked against is a project, and a project is one repository open on more than one machine.

The surface a package compiles against carries its own version, moving on its own clock rather than the application's, and a manifest states a range over it. It is 3.10.0 today, and pnpm api:check fails a build where the surface moved and the number did not.

What is published so far. All of it is installed from the catalogue in the window, and none of it is inside the application:

This is where contributions are most welcome. You do not have to work on the core to add something real — an extension is a package with its own types, its own screen, its own background work and its own clock, and it installs into any project without this repository changing:

- The contract is published as @sync-buzz/extension-api. It carries the types, the version your manifest states a range against, and a CLI that packs and checks an archive. - The packages above are built in sync-buzz/sync-extensions and are worth reading as worked examples. - docs/writing-an-extension.md builds one from nothing, with every file it contains. - docs/extension-architecture.md is the seam drawn rather than argued: four boundaries, the manifest field by field, each lifecycle as a sequence, and every refusal with the place it is heard. - docs/extensions.md is the whole of how a package is built, loaded, permitted, published and updated, and docs/background.md is the half of one that runs with no window open.

Ideas that need nothing from us: a reader for a document format, a review surface, a dashboard over a type you invented, a section over whatever your team already keeps in a folder.