Codync: message your coding agents from your phone as if they were teammates

The host is one Rust binary that every client talks to

The architecture is easier to understand from the bottom up, and the bottom is a single program.

The README states that `codync-host` is one small, fast Rust binary for macOS, Windows and Linux, static on Linux so it runs on any distro, and that it drives every agent, keeps the transcripts and serves every client. That is the whole server side. There is no cluster of microservices behind it, and the transcripts live wherever the host runs, on the machine that has the agents installed.

That is the point of the design. The agents Codync talks to, Claude Code, Codex, Cursor, Pi, OpenCode, Grok Build, Gemini and Copilot, are tools that live on a developer's own machine and run against that machine's projects and accounts. Codync does not replace them or host them. It fronts them.

The clients are separate and native per device kind. The iPhone app is SwiftUI, the desktop app for Mac, Windows and Linux is Electron with a menu bar or tray, and there is a terminal UI for SSH. The Rust toolchain pin lives in a `rust-toolchain.toml` at the repository root, and the top level shows the full shape of the project: `apps/` for the clients, `host/` for the Rust binary, `relay/` and `cloud/` for the hosted relay, `web/`, `docs/`, `packaging/`, `marketing/`, `discord/`, `metadata/` and `tools/`.

The Windows desktop entry notes one gap in the current state: iPhone pairing is supported but remote screen is not yet available on Windows, while the macOS app carries the full feature set.

Bot identity comes from the ACP registry, not from a hardcoded list

The list of supported agents is the interesting engineering decision, and it is worth understanding how it works.

The README says Codync can bring any coding agent, naming Claude Code, Codex, Cursor, Gemini, Copilot, OpenCode, Pi, Grok Build and roughly forty more, and describes them as everything in the ACP registry, the Agent Client Protocol. Installed agents are found automatically, and the rest are fetched on first use, with every bot picking its own. The topics list `acp` and `agent-client-protocol`, which confirms the protocol is the integration surface.

That is a different approach from an app that ships adapters for each agent. A hardcoded list means every new coding agent needs a code change in the app before it can be used. A registry means the list of usable agents grows without the app changing, and an agent can be added upstream and simply appear.

The trade-off is that the protocol has to fit. ACP agents that behave slightly differently, or that a registry implementation describes incompletely, will show up as a bot that works for some tasks and not others. The README does not describe a compatibility matrix per agent, so the practical expectation is that behavior is uniform where the protocol is uniform and varies where it is not.

The other structural point is the group chat. Several bots can sit side by side, each with its own agent, project folder and approvals, all working at once, and several can be put in a group chat where they answer in turn like a team channel, with `@name` picking who replies. Reply works on any message, yours or a bot's.

Getting the host onto a machine means a release download, not a build

The README does not describe a build from source in the visible portion, and the distribution path is downloads. There are badges for macOS, Windows x64, Linux x86_64 and Linux ARM64, each pointing at a release asset, and the projects site lists macOS as Apple Silicon plus Intel with a DMG, a Windows x64 installer, and a Linux AppImage. There is also a Homebrew tap at leepokai/homebrew-codync and an App Store listing for the iPhone app, plus an iOS app and a Discord invite.

The platform requirements are stated as badges. iOS 18 or newer, macOS 14 or newer, Windows x64, and Linux on x86_64 or arm64. The language and framework badges read Rust for the host, SwiftUI for the iPhone, and Electron for the desktop.

That set of requirements is a constraint rather than a detail. macOS 14 and iOS 18 are recent floors, so a managed Mac on an older release will not run the current client, and the Rust host being static on Linux is what makes the single binary work across distros rather than requiring a per-distribution build.

For someone evaluating the project rather than installing it, the release cadence is the more useful signal. The three most recent releases are v2.20.2 and v2.20.1 on 2026-10-20, and v2.20.0 on 2026-10-19, so two patch versions and a minor version shipped within two days. The last push was on 2026-10-20 and the repository is not archived.

The hosted relay forwards ciphertext and can be skipped on a LAN

Reaching a computer from a phone usually means VPN software, port forwarding, or a tunnel. Codync's answer is a hosted relay that the README says is included at no cost, with no Tailscale, no VPN and no port forwarding.

The security claim is specific. Traffic is end-to-end encrypted between the phone and the computer, so the relay only forwards ciphertext. And the routing is conditional: on the same Wi-Fi or over Tailscale, the phone connects directly to the computer instead, and the relay is not in the path at all.

Push notifications get the same treatment. The README says the notification text is sealed to the phone's key, so the push relay never sees what the bots said. That is a meaningful distinction from a design where a server can read the notification body in order to display it, and it is the kind of thing worth verifying against the implementation rather than the badge.

The account model is worth reading closely too, because it is where a hosted relay usually creates a risk. Your iPhone lists every computer on your account, and you tap Ask for access on a computer and confirm a 6-digit code on that computer itself before its bots appear. Each computer approves each device separately, so an account alone never grants access to a computer. That design pushes the trust boundary onto the device rather than onto the account, which is the right way round for something that runs code on a developer's machine.

Approvals, remote screen and voice calls live on the phone

The feature set beyond messaging is what distinguishes Codync from a remote terminal.

Approvals are the load-bearing one. A coding agent that wants to write a file or run a command will ask for permission, and the README says you get a notification when a bot finishes or needs your approval, with approval cards as one of the listed features. On a phone, being able to tap approve without returning to the desk is the difference between a delegation that finishes and one that stalls overnight.

Remote screen lets you see and control the computer from the iPhone over WebRTC with hardware H.264, and the same capability is available to the bots themselves through a built-in `computer` tool, so an agent can drive the screen as well as reading it. Voice calls let you talk to a bot hands-free and hear the replies read aloud, which is a shortcut for the case where the request is a question rather than a task.

Per-bot memory is listed as a feature, along with bots asking each other for help. The second one is notable: a Claude bot can ask a Codex bot for a review, which turns the set of agents from a menu into something that can divide work. It also means the approval surface multiplies, since a bot consulting another bot may trigger that bot's own approval flow.

What the README does not describe is the cost of all this. There is no statement about how transcripts are stored on the host, whether they are encrypted at rest, how a bot's memory is scoped, or what happens to a session when the host sleeps.

Compared with a terminal multiplexer and with a plain SSH session

The alternatives for reaching a long-running agent session from somewhere else are older and simpler, and they are worth weighing before adding a host, a relay and three clients.

A terminal multiplexer is the baseline. Running the agent inside tmux or screen on a remote box, then attaching from the phone through an SSH client, gives you the same ability to start a task and return to it later, and the session survives the connection dropping. What it does not give you is push notifications when the agent wants approval, group chats across agents, a native remote screen, or the option of a native app on the phone.

A plain SSH session is the same idea without the session persistence. It is the least machinery and it works everywhere, including on a locked-down corporate machine where installing an Electron app and a Rust host is not an option.

The difference in approach for Codync is that the remote surface is chat rather than a terminal. The README gives the reason: on a phone, finding the right working session and then picking an environment is too slow, whereas with bots you already know who to hand the intent to. That is a real argument, and it applies to a specific workflow, delegating a scoped task to a known agent and getting a notification when it is done. It does not apply to interactive work, where you want to see and drive the terminal yourself, and for that the SSH route is better.

The other difference is that Codync is agent-aware in a way a multiplexer is not. Bots carry their own agent, project folder and approvals, and the host is the one holding transcripts, so a bot is a persistent identity with a history rather than a window on a screen.

Editorial conclusion

Adopt Codync if you run coding agents on a machine you cannot always sit at, and you want to hand one a task from your phone and get a notification when it needs approval or finishes. Do not adopt it if every session already happens at the desk, since the added surface is a host, a relay and several clients for a workflow that a plain terminal already covers. Verify first that the agents you use appear in the ACP registry or are installed locally, since bots are created from that list, and read what the relay does and does not see before you send anything sensitive through it.

Frequently asked questions

Official sources

1. leepokai/Codync on GitHub
2. License: Apache-2.0
3. Project website
4. README
5. Releases