Tutti: a shared real-time workspace for Claude Code, Codex and other coding agents

The problem Tutti targets: you as the messenger between agents

The README states the case plainly. Claude Code is good at one thing, Codex at another, and the moment a workflow needs a handoff, a person becomes the transport layer. Its example: Claude finishes an API, then you paste the API docs into Codex, explain where things stand, and re-explain the design decisions before the frontend work can start. If the UI needs assets, you summarize again, generate images somewhere else, download them, upload them into the next agent, and restate the requirements.

The audience is developers who already run more than one agent and have improvised a handoff workflow, often with Markdown files. The README lists that as a symptom rather than a solution: "You've copied context between agents more than once, maybe even built your own Markdown-based handoff workflow." Tutti's answer is not a better agent. It is a shared place where the agents and their outputs sit next to each other, so the handoff is a file or a task the next agent can already see, not a paragraph you retype.

How the shared workspace works, as far as the repository shows

Tutti is a pnpm monorepo, not a single app. package.json declares workspaces over apps/*, packages/*/*, services/tuttid/builtin-apps/tutti-onboarding and tools/fixtures/*, and the build script compiles TypeScript packages, then runs pnpm generate:builtin-apps, then builds five Go modules in sequence: packages/appcli/core, packages/workspace/files, packages/workbench/service, services/tuttid and apps/cli. The presence of go.work and go.work.sum at the repository root confirms a multi-module Go side alongside the TypeScript UI.

That layout tells you where the pieces sit. services/tuttid is the daemon-like service, packages/workspace/files handles workspace files, packages/workbench/service backs the workbench, and packages/appcli/core plus apps/cli provide the agent CLI layer. Built-in apps are generated at build time rather than fetched at runtime, which matters for a local-first desktop product: image generation, design and docs apps ship with the build. The README describes the result as a workspace where "context, files, running tasks, and apps all connected", and says any output, including what apps generate, can flow between agents and be used in the next step. The repository does not document the wire protocol between the desktop app and tuttid in the files shown here; check:api-generated in package.json suggests an OpenAPI description is generated and checked, so the API surface is versioned somewhere under tools/scripts.

Installing Tutti on macOS or Windows

The README's Quick Start does not use a package manager. It points at two direct downloads: a universal macOS .dmg and a Windows x64 .exe, both linked from tutti.sh under the name Tutti · Local. There is no Homebrew formula, no winget entry and no npm install path documented for end users. If you want the hosted multi-user build instead, the README links Tutti · VM for macOS or Windows and notes that downloading it or joining someone else's Room does not require an invite code; only creating a Room does.

Building from source is a different route and is documented in CONTRIBUTING.md rather than the README. The root package.json pins the toolchain: pnpm 10.11.0 and Node 24 or newer. The Makefile wraps the common loops and resolves a matching Node from nvm before calling corepack:

make dev-gui
make dev-cli
make dev-web

The three targets map to pnpm dev:gui, pnpm dev:cli and pnpm dev:web respectively. dev-gui shells out to tools/scripts/dev-gui.sh, so that script is the place to look if the GUI does not come up. A full build is heavier than a dev loop:

pnpm build

That runs the recursive package build, generates the built-in apps, and then compiles the five Go modules listed above, so expect a Go toolchain to be required in addition to Node and pnpm. The repository also carries .node-version, which the Makefile reads to pick the Node version, so a version manager that respects that file will save you a mismatch.

Where Tutti stops: the open-source build versus Tutti · VM

The README's comparison table is the most important page in the project, because it draws a hard line through the feature list. The open-source column checks four items: connect existing agents, use existing subscription credits, built-in apps, and a big @ that reaches across your own agents. Everything collaborative is a dash in that column and a check in the Tutti · VM column: group chat, work with others, work with others' agents, simultaneous editing, agent borrowing, across devices, and no-deploy sharing.

So the honest description of the open-source build is single-user. It connects your agents and gives them one workspace, and that is the whole of it. If your reason for looking at Tutti was the phrase "multi-user, multi-agent, real-time collaboration space" from the top of the README, that phrase describes the hosted product, not the repository you clone. The VM build is in Early Access, and creating a Room there requires an invite code from a waitlist page.

There is a second boundary worth naming. The Quick Start offers macOS and Windows only. The topics list macos-app, and no Linux download appears in the README, so a Linux workstation is not a supported target for the desktop build as documented. A source build may still be possible, but the README does not promise it, and the Go modules plus generated built-in apps make it a real build rather than a quick one.

Tutti compared with a plain shared repository and a Markdown handoff file

The realistic alternative is not another agent orchestrator. It is the setup most people already have: one Git repository plus a handoff note that each agent reads and rewrites. That approach is free, it works with any agent that can read files, and it survives a tool going away. Its weakness is exactly the one the README describes: nothing is live. The note is a snapshot, the agents do not see each other's running tasks, and generated assets have to be written to disk and pointed at manually.

Tutti's difference is that the workspace is the interface rather than a file inside it. Files, running tasks, apps and their outputs share one place, and the README claims Codex can pick up Claude's output "as if they shared one brain". Treat that as a design goal, not a measured result; the repository does not publish a benchmark for context transfer. What you can verify from the layout is that the pieces exist: a workspace file service, a workbench service, a tuttid service, and a CLI layer for agents. If your handoff file already works and your agents are cheap to re-prompt, the shared repository is less machinery for the same outcome. If you keep losing time to restating context, the live workspace is the part worth testing.

Maintenance, licence and the cost of keeping up

The repository is not archived, and the last push was on 2026-09-05, the same day as the v0.2.33 release. The release list shows v0.2.32 on 2026-09-03 and v0.2.33 two days later, plus a stable channel entry, so the project is moving in short increments rather than on a long cadence. There is a .changeset directory, which means changesets are used to record and version releases; expect the version number to move often.

Upgrade cost is mostly a function of the toolchain, not the app. Node 24 or newer and pnpm 10.11.0 are pinned, and a source build also compiles Go modules, so an upgrade can require a Node bump, a pnpm bump and a Go build in the same step. The .node-version file plus the Makefile's nvm lookup is the project's own answer to that, and it is worth using rather than fighting. The project ships a Makefile with dev-cli, dev-gui and dev-web targets, so the daily loop is short once the toolchain matches.

The licence is Apache-2.0, with a LICENSE file and a NOTICE file at the repository root. Apache-2.0 is permissive and includes an explicit patent grant, and the NOTICE file means attribution obligations can travel with redistributions. That is the shape of the licence, not advice about your situation; if you plan to redistribute a modified build, read LICENSE and NOTICE yourself. One more thing to check before depending on it: the README does not document a rollback path between releases, so pin the version you install if you need to return to it.

Editorial conclusion

Adopt Tutti if you already run two or more coding agents on one machine and you are tired of pasting context between them; the open-source build is a local-first desktop app, so the worst case is a wasted afternoon. Do not adopt it if your main need is several people and their agents working in the same live session: the README puts group chat, simultaneous editing, agent borrowing and cross-device work in the Tutti VM column only, and creating a Room there needs an invite code. Before installing, check that the machine has Node 24 or newer, because package.json sets engines.node to >=24, and open docs/README.md to confirm the current build and run steps for your platform.

Frequently asked questions

Official sources

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