Lody: a shared workspace layer for coding agents over ACP
Share coding agents with your team on phone and desktop
At a glance
- What is it?
- Lody connects the machines and coding agents a team already runs, then exposes their conversations across desktop, mobile, web and CLI. The interesting part is the ACP adapter and the per-session worktree isolation; the weak part is that most of the collaboration surface is still a plan.
- Who is it for?
- Adopt Lody if your team already runs ACP-compatible agents on machines you control and the bottleneck is handoff between people, not model quality. Skip it if you need a single-vendor agent with no adapter layer, or if you cannot run a daemon on the machines that hold your code.
- Can I use it commercially?
- Yes. Apache-2.0 is a permissive licence: you can use, modify and sell software built on it, as long as you keep its copyright and licence notices.
- Is it still maintained?
- Yes. The repository received new commits within the last day.
- What is it written in?
- Mainly TypeScript, according to GitHub's language statistics.
Answers come from the project's GitHub data, last synced on September 15, 2026, and from our analysis. They are not legal advice.
DEEP OPEN-SOURCE ANALYSIS
The handoff problem Lody is aimed at
Most coding agent tooling assumes one operator at one terminal. The moment two engineers need to look at the same agent run, the transcript leaves the tool: someone pastes logs into Slack, screenshots a diff, or re-runs the prompt on their own machine and gets a different answer. Lody's README frames the target directly, calling itself "a shared workspace for the coding agents your team already uses." The unit of sharing is the conversation, not the model or the subscription. Teammates open the same conversation and see the transcript, runtime status, files and code changes, then add instructions in place.
The second half of the problem is machine ownership. Agents run on laptops, workstations, servers and cloud VMs, each with its own logins, models and permission modes. Lody does not ask you to move that configuration. The README states that machines remain private until their owner shares them with the workspace, which means the sharing decision sits with the person who owns the hardware. That is a deliberate boundary, and it shapes who the tool fits: teams with heterogeneous machines and existing agent subscriptions, not teams looking for a hosted agent they do not have to run themselves.
ACP is the load-bearing abstraction
The mechanism that makes any of this work is ACP. The README says you can "bring any coding agent through ACP" and names Claude Code, Codex, Kimi and OpenCode as examples of ACP-compatible agents. So Lody is not an agent. It is an adapter and a coordination layer sitting between a client surface and whatever process actually executes the work.
That choice has consequences. Anything that does not expose an ACP interface is out of scope, and the README does not document a fallback path for wrapping a non-ACP agent. The advantage is that Lody inherits the permission model of the underlying agent rather than inventing one. The README notes that permission requests stay visible across surfaces, and the mobile section mentions approving permission requests from an iPhone Live Activity. The approval still belongs to the agent's own permission mode; Lody is relaying it.
Above the adapter sits a conversation graph. Lody gives agents tools to create or reuse other conversations, read their status and history, send follow-up instructions, cancel running work, and bring results back. The README describes the intended pattern plainly: one conversation acts as coordinator, delegating investigation, implementation and testing to separate conversations running in parallel. Child conversations stay independent while preserving a link to the conversation that created them, and an @ mention can reference a conversation across sessions. This is orchestration by convention rather than by a scheduler, and it depends on the agent being willing to call those tools.
Worktrees, diffs and the preview loop
Parallel agent work collides on the filesystem before it collides anywhere else. Lody's answer is Git worktrees: the README says sessions can be given their own worktrees so agents work in parallel without mixing changes, and that a session can be forked into another conversation or worktree to explore a different approach. That is the right primitive for the problem, because worktrees share the object store and only duplicate the checkout.
The inspection surface follows from it. You browse project files and read per-turn or full-session diffs beside the conversation, add line-level comments, and follow pull request status and CI without leaving the session. A screenshot in the README shows a pull request and its CI status next to an agent conversation. For frontend work there is a preview loop: open a running web app inside the session, switch between responsive viewports, and send element-level visual annotations back to the agent.
What the README does not describe is how worktree lifecycle is managed. There is no documented command for pruning worktrees after a session is archived, and no statement about where they are created on disk. If your repository is large, that omission matters more than the diff viewer does.
Getting a machine onto the workspace
The entry point is one command, run on the machine that will execute work:
npx lody daemon start
The README states that this opens a sign-in link, connects the machine to the workspace, and keeps it available for work dispatched from desktop, mobile, web or CLI. Everything else in the product assumes that daemon is running. If it stops, the machine disappears from the dispatch list.
Dispatching from a terminal uses the same CLI, which is broader than the daemon. According to the README you can register local projects; inspect workspaces, machines, linked repositories and agent configs; create and message sessions; read history and status; and archive or restore sessions. The README gives this example:
npx lody session create --workspace my-team --agent-config codex --repo owner/repo "Fix the failing test"
and a companion listing command:
npx lody session list --workspace my-team
The flags visible here are --workspace, --agent-config and --repo, with the prompt as a positional argument. The README also notes that commands supporting --json can feed Lody workspace data into your own tools, which is the integration path for anyone wiring this into existing dashboards or CI. The full command reference lives at lody.ai/docs/cli, and the README does not reproduce it, so treat the flag set above as illustrative rather than complete.
Where Lody is the wrong tool
The first limitation is that the collaboration features are the newest part of the product and the thinnest in the documentation. The README's "Beyond conversations" section is explicitly forward-looking: documents and document sandboxes are described as something the project plans to add, not something that exists. The stated goal is shared team context for understanding not only what changed but why. Anyone evaluating Lody for requirements capture or decision records should read that section as a roadmap, not a feature list.
The second limitation is architectural. A shared conversation means shared visibility into the code and diffs that conversation touches. The README says machines stay private until their owner shares them, which handles machine access, but it does not describe per-conversation access control or any audit trail of who dispatched what. If your constraint is that certain repositories cannot be visible to the whole workspace, the material supplied here does not show a mechanism for scoping that.
The third is the ACP dependency again, viewed from the other side. A team standardized on a single agent that does not speak ACP gets nothing from the adapter layer, and would be paying the cost of running a daemon and a workspace for a sharing feature they could approximate with a shared terminal session. The README offers no non-ACP integration path.
How this differs from running agents behind a shared server
The obvious alternative shape is a central agent server: one long-running process, one set of credentials, and everyone connects to it as a client. That model is simpler to reason about because there is exactly one place where work happens and one place to audit.
Lody inverts it. Execution stays distributed across machines the team already owns, and the workspace is the coordination point rather than the runtime. The README is explicit that you keep using the subscriptions, logins, models and permission modes configured on your laptops, workstations, servers and cloud VMs. The practical difference shows up in two places. Cost: a central server model usually means provisioning capacity for the whole team, while Lody reuses hardware and subscriptions that already exist. Failure modes: a central server has one outage domain, while a distributed model has as many outage domains as machines, and a laptop that sleeps takes its agent offline.
Neither is strictly better. The central model wins when you need uniform policy enforcement and a single audit point. Lody's model wins when the team already has capable machines and heterogeneous agent setups, and the friction you are trying to remove is human handoff rather than infrastructure.
Licence, maintenance and what to check first
Lody is Apache-2.0 and written in TypeScript, with the repository at LodyAI/Lody on the main branch and no archived status. Apache-2.0 includes an express patent grant and permits commercial use and modification, with the usual obligations around preserving notices and stating changes. That is a permissive licence, and it does not by itself tell you anything about the project's governance or release cadence. No releases were retrieved for this review, so there is no version history to reason about here, and the README does not describe a support policy or a compatibility guarantee for the ACP surface it depends on.
That last point is the real maintenance question. Lody's value is proportional to how many agents speak ACP and how stable that interface stays. An upstream change in an agent's ACP implementation is a change Lody has to absorb, and nothing in the supplied material describes how that is handled. There is also an operational cost that is easy to underestimate: every machine you connect runs a daemon, and every session that uses isolated worktrees creates a checkout. Neither is documented in terms of resource use. The README mentions usage visibility for context, token and quota consumption plus machine and agent resource consumption, so there is at least a place to look, but the material does not say what that view reports or how often it samples. Start by connecting one non-critical machine, running npx lody daemon start, and confirming that session list reflects what you expect before you point it at a repository you care about.
Editorial conclusion
Adopt Lody if your team already runs ACP-compatible agents on machines you control and the bottleneck is handoff between people, not model quality. Skip it if you need a single-vendor agent with no adapter layer, or if you cannot run a daemon on the machines that hold your code. Before committing, verify three things against your own setup: that your agent of choice actually speaks ACP, that the daemon's sign-in flow fits your network policy, and whether the documents and document sandboxes the README describes as planned have shipped by the time you evaluate.
Community notes