Clay Studio: a self-hosted workspace that turns local coding agent CLIs into a shared team
A self-hosted workspace where people and coding agents work together across projects, sessions, and providers.
At a glance
- What is it?
- Clay Studio wraps the coding agent CLIs you already have installed behind a browser workspace with shared sessions, persistent agent identities, and disk-based storage. It is a coordination layer, not a model provider, and its value depends entirely on which runtimes you already run.
- Who is it for?
- Adopt Clay Studio if you already run at least one supported coding agent CLI on a machine you control and you want several people looking at the same live session instead of passing a terminal around. Do not adopt it if you have no agent CLI installed and authenticated, or if you expect it to supply model access on its own.
- Can I use it commercially?
- Yes, with strict conditions. AGPL-3.0 is a network copyleft licence: if people use a modified version over a network, for example as a hosted service, you must offer them its source code under the same licence.
- Is it still maintained?
- Yes. The repository last received commits 1 day ago.
- What is it written in?
- Mainly JavaScript, 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 problem Clay Studio addresses is not model access, it is coordination
Running a coding agent CLI is a single-user activity by design. The process reads a terminal, writes to a terminal, and the conversation lives in that process. Clay Studio's stated goal is to change that shape: it describes itself as a self-hosted workspace where people and coding agents work together across projects, sessions, and providers. The README lists the pain points it targets directly: teammates gathering around one terminal, permission requests that nobody sees, and sessions that become disposable chats whose context is lost when the next task starts. That is a narrower claim than it first appears. Clay Studio does not offer a model, an inference endpoint, or a hosted backend. It assumes you already have at least one supported coding agent CLI installed and authenticated, and it puts a shared browser layer in front of whatever you have. The audience follows from that assumption: small teams or individuals who already pay for one or more agent CLIs and want several people to see and steer the same work, without moving the workspace into a vendor cloud. If you are a single developer running one CLI in one terminal, the coordination surface Clay adds has little to do.
Browser to daemon to runtime: the request path and where state lives
The README gives the normal request path as a single line: browser to Clay Studio daemon to the selected coding-agent runtime to the model provider. Clay Studio sits in the middle of that chain and does not relay project traffic through a Clay-hosted cloud. Code leaves the machine only when the selected runtime sends it to its model provider, which is the same exposure you would have using that CLI directly. State is stored on disk in portable JSONL and Markdown rather than a proprietary database, and the README frames this as the reason you can change coding agents without migrating the workspace around them. A component called YOKE is described as giving supported coding agents a common session interface and carrying project instruction files across vendor boundaries. That is the mechanism behind cross-provider continuity: rather than a translation layer at the model protocol level, it appears to standardize the session surface and the instruction files that agents read. The documentation referenced from the README (docs/guides/architecture.md and docs/guides/MCP-IMPLEMENTATION.md) is where the details would live; the README itself stops at the diagram and the storage claim.
Ten runtimes, one detection step, and no bundled model
Clay Studio currently includes integrations for Claude Code, Codex, Grok Build, Kimi Code, GitHub Copilot CLI, Qwen Code, Junie CLI, Antigravity CLI, OpenCode, and Kiro CLI. The README states that Clay detects locally installed runtimes and exposes the ones available on your machine. Each runtime keeps its own authentication and may expose different models, modes, and capabilities. That last sentence is the honest boundary of the product: Clay does not normalize what a runtime can do, so a feature you rely on in one CLI may simply not exist in another. The README also carries a disclaimer that Clay Studio is not affiliated with the providers of the coding agents it supports, and that users are responsible for complying with the terms of their selected providers. If you are planning to fan a single task across several of these CLIs, read that disclaimer as a real constraint rather than boilerplate. Ten integrations is a wide surface for a project whose latest push and latest release are the same day, and the README does not claim feature parity across them.
Getting it running: one npx command, a port, and a project list
The requirements are Node.js 20 or later and at least one supported coding-agent CLI installed and authenticated. The quick start is a single command: npx clay-server. The default port is 2633, and the README notes you can open the URL or scan a QR code from another device. The common CLI commands are given as follows. npx clay-server starts the daemon on the default port. npx clay-server -p 8080 uses a different port. npx clay-server --add . adds the current directory as a project. npx clay-server --list lists registered projects. npx clay-server --shutdown stops the daemon. The README points to npx clay-server --help for the complete command reference, which is the right place to look for flags not shown here. For access outside your local network, the README recommends a private network such as Tailscale rather than exposing the daemon directly. The d.clay.studio hostname used for local HTTPS is described as a DNS-only service with no application data passing through it, and the README points to the clay-dns directory for the implementation and threat model. That is a claim worth reading in the source if local HTTPS is part of your setup.
Mates, worktrees and Ralph Loops: the features that carry real operational weight
The capability list is longer than the quick start suggests, and a few items change how a team would actually work. Persistent Mates are AI collaborators with their own identity, instructions, knowledge, memory, direct messages, and roles in structured debates. That means the unit of work is not only the session but the agent persona, and the README says Mates retain their roles and knowledge between conversations. Parallel work is handled through git worktrees, paired sessions, spawned workers, scheduled tasks, and Ralph Loops, with the README claiming visibility into what is running. Collaboration features include presence, cursors, mentions, and handoffs, plus the ability for a teammate to enter the same session and respond to permission requests. The workspace is reachable from a desktop browser or as an installed PWA on mobile, with push notifications for approvals, failures, and completed work. File browsing and editing, diffs and history, terminals, skills, MCP servers, and project knowledge all sit in the same interface. The volume here is the main risk: each of these is a surface that has to keep working across ten runtimes, and the README does not say which capabilities are runtime-specific.
Where Clay Studio is the wrong tool
The clearest failure mode is stated by the project itself: Clay Studio needs a supported coding-agent CLI installed and authenticated. There is no bundled model and no fallback. If your runtime of choice is not on the list of ten, or if it is installed but not detected, the workspace has nothing to drive. A second limitation is the network model. The README recommends a private network such as Tailscale for access outside the local network, which tells you the daemon is not designed to be a public-facing multi-tenant service. If your team is distributed and you cannot put everyone on one private network, the deployment story gets harder, and the README does not describe an alternative. Third, the project is on 4.1.0 beta releases, with three beta tags published within roughly six hours on the same day as the last push. That cadence suggests active development rather than a frozen surface, and the README does not include a stability or compatibility policy for the JSONL and Markdown formats. A team that needs a fixed interface to build against should treat the storage format as something to verify on disk rather than assume. Finally, the README says each runtime keeps its own authentication and may expose different models and modes, so Clay cannot smooth over provider differences. If your workflow depends on one runtime's specific behaviour, Clay adds a layer without removing the dependency.
The alternative is running the CLIs directly, and the difference is state
The obvious alternative is what most teams do now: each person runs their coding agent CLI in their own terminal, in their own checkout, with their own conversation history. That approach has no daemon to operate, no port to expose, and no shared surface to keep in sync. It also means sessions are not shared, permission requests are visible only to the person whose terminal is open, and the context built up in one conversation does not carry to the next task or to a colleague. Clay Studio's answer to that is the combination of shared live sessions and persistent Mates backed by JSONL and Markdown on disk. The trade is operational: you take on a daemon, a network path, and a set of runtime integrations in exchange for shared presence and retained context. A second alternative is a hosted agent platform, where the coordination problem is solved for you but the workspace and its history live in someone else's system. Clay Studio's README is explicit that it does not relay project traffic through a Clay-hosted cloud, and that the daemon runs on infrastructure you control. That is the actual differentiator, not the feature list.
Licence, maintenance and what the MIT grant does and does not cover
Clay Studio is MIT licensed, which permits commercial use, modification, and redistribution provided the licence and copyright notice are retained. That covers the Clay Studio code. It does not cover the coding agent CLIs Clay drives, and the README's disclaimer states that product names and trademarks belong to their respective owners and that users are responsible for complying with the terms of their selected providers. Those are separate agreements with separate terms, and nothing in the MIT grant changes them. On maintenance, the material shows a project that is actively moving: the last push and the newest release share a date, and the release sequence for 4.1.0 runs through three beta tags published hours apart. The practical cost of that cadence is upgrade work on the storage and session formats, which the README describes as portable JSONL and Markdown but does not version or document for migration. The README points to a CHANGELOG and a CONTRIBUTING file, and there is a community-built Clay Stream Deck plugin linked from the README, which suggests an extension surface exists outside the core repository. None of this is a guarantee about release frequency going forward, and the README makes no support commitment.
Editorial conclusion
Adopt Clay Studio if you already run at least one supported coding agent CLI on a machine you control and you want several people looking at the same live session instead of passing a terminal around. Do not adopt it if you have no agent CLI installed and authenticated, or if you expect it to supply model access on its own. Before committing, verify three things: that your chosen runtime appears after Clay detects local installs, that the JSONL and Markdown files under your workspace directory are readable without Clay, and that you are comfortable running a daemon you expose to teammates over Tailscale rather than the public internet.
Community notes