Lody: a shared workspace for the coding agents your team already runs

The problem Lody addresses: agents run on one laptop, decisions happen in five places

A coding agent is usually bound to the machine it runs on. The subscription, the login, the model and the permission mode all live on that laptop or server, and the conversation lives there too. When a teammate needs to see what the agent did, the transcript gets screenshotted, the diff gets pasted into chat, and the approval request arrives as a message that says "can you approve this?" with no context.

Lody's README frames the project as "A shared workspace for the coding agents your team already uses." The stated goal is to open the same conversation with teammates so they can see the full transcript, runtime status, files and code changes, then add instructions without passing around screenshots or logs. The audience is a team that already has agents running and wants the collaboration layer, not a replacement agent. That distinction matters: Lody does not ship a model or an agent of its own. It connects machines and brings agents through ACP, the Agent Client Protocol, so the subscriptions and logins you already pay for stay where they are.

How the daemon, workspaces and ACP fit together

The architecture visible in the README is a daemon plus a workspace. You run Lody on a workstation, server or cloud VM, and that machine becomes available for work dispatched from any surface. The README is explicit that machines remain private until their owner shares them with the workspace, so joining a workspace is not the same as exposing a machine to it.

Agents enter through ACP. The README names Claude Code, Codex, Kimi and OpenCode as examples and says "or another ACP-compatible Agent," which means the integration boundary is the protocol, not a per-vendor plugin. The repository layout supports this: the package.json scripts reference acp-extension-claude and acp-extension-codex as separate workspace packages, and the typecheck script runs a prepare:acp-adapters step before typechecking. So adapters are generated or prepared at build time rather than hand-maintained.

Above the daemon sits the workspace, and above that sits the session. Sessions can be given their own Git worktrees so parallel agents do not mix changes, and a session can be forked into another conversation or worktree. Agents also get tools to create or reuse conversations, read status and history, send follow-up instructions, cancel running work and bring results back. That is what makes one conversation a coordinator and the others workers. The README states that Lody keeps each child conversation independent while preserving its relationship to the conversation that created it, and that conversations can be referenced with an @ mention.

Installing Lody and dispatching a first session

There is no source build needed to try it. The README's connect-a-machine step is a single npx command that runs the daemon on the machine you want to make available:

npx lody daemon start

According to the README, that command opens a sign-in link, connects the machine to your workspace, and keeps it available for work dispatched from desktop, mobile, web or CLI. Expect a browser sign-in rather than a token you paste.

Once a machine is connected, the CLI is the fastest way to create real work. The README gives this example, which creates a session in a named workspace using a named agent config, against a repository, with a first instruction:

npx lody session create --workspace my-team --agent-config codex \
  --repo owner/repo "Fix the failing test"

To confirm the session exists, list the sessions in that workspace:

npx lody session list --workspace my-team

The README says the CLI can also register local projects, inspect workspaces, machines, linked repositories and agent configs, create and message sessions, read their history and status, and archive or restore them. Commands that support --json can feed workspace data into your own tools, which is the part worth checking early if you plan to script against Lody rather than click through it.

If you would rather not use the CLI, the README links Google Play, the App Store, and a download page for macOS, Windows and Linux. The desktop app is built from apps/electron, and the repository's build script targets that directory.

What Lody does not do, and where it is the wrong tool

The biggest constraint is that a connected machine has to stay reachable. Work is dispatched to a machine running the daemon, so a closed laptop is an unavailable worker. The README does not document an offline queue or a fallback execution path, and it does not describe what happens to a dispatched session when the target machine drops mid-run.

The second constraint is the ACP dependency. If your agent does not speak ACP, Lody has nothing to connect to. The README names four agents and leaves the rest to the protocol, so an agent with only a proprietary interface is out of scope until someone writes an adapter.

Third, this is a coordination tool, not a sandbox. Lody inherits the permission modes configured on each machine, and the README describes surfacing permission requests for approval rather than defining its own policy layer. If your requirement is that no agent action can touch production without a central policy engine, Lody is not that engine. It shows you the request and lets a human approve it.

Finally, the README's own framing of what is missing is worth reading literally. It says shared conversations are "Lody's starting point, not the whole workspace," and that documents and document sandboxes are planned, not shipped. Anything you need beyond conversations, diffs, terminals and previews should be treated as unbuilt.

Lody compared with running agents directly or through a hosted sandbox

The obvious alternative is what most teams do today: each developer runs their agent locally and shares results through Git and chat. That costs nothing new and requires no daemon, but it loses exactly the things Lody is built around. There is no shared transcript, no live runtime status, no way for a teammate to add an instruction mid-run, and no approval path other than a message asking someone to approve something on their own machine.

The second alternative is a hosted agent environment, where the agent runs in a vendor's cloud and the team shares that. That removes the always-on machine problem, because the vendor keeps the runtime up. It also removes the thing Lody is preserving: your own subscriptions, logins, models and permission modes, on your own laptops, workstations, servers and cloud VMs. The README is direct that machines remain private until their owner shares them, which is a different trust model from handing the runtime to a third party.

The third alternative is a general remote-development setup, where you tunnel into a machine and drive a terminal. That gets you access to the machine but not to the conversation as a first-class object. Lody treats the session as the unit: it can be listed, searched, pinned, archived, forked, given its own worktree, and referenced by an @ mention. A tunnel gives you a shell; it does not give you a shared, addressable conversation that another agent can read and continue.

Maintenance, upgrade cost and the Apache-2.0 licence

The repository is not archived, and the last push was on 2026-09-10, so the codebase is being changed. There are no retrieved releases, which means there is no published changelog to read before upgrading. That is a real cost: without releases you are tracking the main branch or the npm package, and you will not get a curated list of breaking changes between versions.

For anyone running Lody across a team, the upgrade surface is wider than a single binary. The repository is a pnpm workspace with apps/ and packages/ directories, a patches/ directory for patched dependencies, and a pnpm-lock.yaml. The package.json preinstall script runs scripts/check-node-runtime.mjs and scripts/guard-nested-workspace-install.mjs, so an unsupported Node runtime or a nested workspace install fails before anything else happens. If you build from source rather than using npx, budget for the Electron app build under apps/electron, which the build script invokes through corepack pnpm.

On licensing, Lody is Apache-2.0, which permits commercial and private use and includes an express patent grant. The repository also carries a THIRD_PARTY_NOTICES.md file, which is where the dependency licences you inherit are recorded. Apache-2.0 does not grant trademark rights, so the Lody name and logo are not covered by the code licence. That is a description of the licence text, not legal advice; have your own counsel review anything you redistribute.

Editorial conclusion

Adopt Lody if your team already runs Claude Code, Codex, Kimi, OpenCode or another ACP-compatible agent on machines you control and you want shared transcripts, diffs and permission approvals instead of pasted logs. Do not adopt it if you need a single hosted agent with no local runtime, or if you cannot accept that each connected machine stays online for work to be dispatched to it. Before rolling it out, verify two things: that your agent speaks ACP, and that the Node runtime on every machine satisfies the check in scripts/check-node-runtime.mjs, which runs as a preinstall step.

Frequently asked questions

Official sources

1. Issues
2. License: Apache-2.0
3. LodyAI/Lody on GitHub
4. Project website
5. README