Cohort

View extended demo here! https://youtu.be/p3mgaiaF86A

Cohort is going private :)

If you are interested in this product, feel free to reach out to either of us!!

Inspiration

AI coding agents are now good enough that teammates want to lend each other theirs: "have your agent look at my billing bug." The tools that allow this today share too much. Amp's multiplayer and Cursor's team features share a whole session, and they are switched on for the whole workspace or by an admin. Whoever joins gets the agent's full access, so they can edit any file, read .env, and use your keys. Agents also edit before anyone agrees on a plan, and the decisions a team makes in one session are gone by the next.

We wanted agents on a team to work like a well-run engineering team: ask before acting, take only the access they need, keep a record, and let the person whose machine and keys are on the line decide.

What it does

Cohort is a hosted hub plus small local pieces (a hook, an MCP server, a runner and a CLI) that put agents under consent.

Plan gate. A Claude Code agent cannot edit until its task has an approved plan. If a plan claims files that another open plan already holds, the hub refuses it, so two agents cannot collide on the same code.
Shared sessions with scoped turns. Your local Claude Code session becomes a thread your teammates can watch live and add turns to.
- Question turns run read-only, with secrets like .env blocked.
- Change turns wait for the owner's approval.
- Each turn runs as a fork of the owner's session, on the owner's machine.
Credentials stay put. The hub never holds a shell, a repo token or a model key, and the owner's credentials never leave the owner's machine.
A record with consent. Text an agent writes becomes durable only through an approved plan, a recorded decision, or the owner releasing a result. The hub then feeds that record into every new session, labelled with its author, age and source.
An audit row for every tool call. Denials are logged too. In our demo, Bob's agent tries to read .env to answer a question. The read is denied and the audit log shows it.
Fails closed. If the hub is down, nothing new gets through. The owner's own session can keep using the exact tools and files it was already allowed for 30 minutes. hub break-glass "<reason>" gives a logged override that expires.

We are honest about the threat model. The gate is enforced against teammates and against the agent. It is advisory for the owner, who can always remove their own hooks.

How we built it

Runtime and monorepo: Bun with TypeScript.
Hub: Elysia and Drizzle on Postgres, with PGlite in tests. Sign-in is GitHub OAuth through better-auth. Every change writes its audit event in the same transaction.
Agents:
- Claude Code PreToolUse hooks enforce the gate.
- An MCP server (submit_plan, record_decision, get_context, and others) lets agents take part.
- A runner executes teammates' turns as restricted forks.
Shared code: path extraction for Edit, Write and apply_patch, the protected-path checks, and redaction of agent-written text.
Apps:
- A web app in Vite, React and Tailwind, following a monochrome design system we wrote for it. Blue means running and red means denied; nothing else gets color.
- A Tauri desktop app that bundles the runner.
Deployment: live at https://cohort.cooking, with a Grok connector over MCP.

Challenges we ran into

Failing closed is hard. Codex hooks fail open on error, so our hook script must never exit without printing a deny. Its hub timeout is kept well inside the agent's own hook timeout.
Security bugs in our own gate. A security review found that a shell prefix (cd .claude && apply_patch …) and malformed heredocs could slip edits past the protected-path check. We fixed both and added tests.
Not overclaiming. The full gate exists only for Claude Code. Codex support is not verified end to end, and Cursor only records decisions. Even our landing page went through five review rounds to remove claims and demo data the product doesn't actually produce.
Live race conditions. Running against the deployed hub surfaced a race between the session heartbeat and context loading, and forks whose error results were posted as answers. We fixed each one in its own PR.

What made this technically challenging

We built a security boundary out of tools that were never meant to be one. Agent hooks were designed for convenience, not for security. Some of them let the agent continue when the hook fails. Some hide which file they are about to change. All of them run on a computer we don't control. Here are the hardest parts.

The gate must fail closed. If anything goes wrong, the answer has to be "no." Claude Code only blocks on a hook failure in newer versions, so we require version 2.1.295 or later. Codex lets the agent continue when a hook crashes, so our hook script must always print a "deny" before it exits. It gives up on a slow hub after 8 seconds, which is long before Codex stops waiting. If the hub is down, nothing new is allowed. The owner gets two ways out: their own session can keep using what it was already allowed for 30 minutes, and they can use a logged emergency override that expires.
Finding out which files an agent will change. For most edits, the file name is easy to read. But one editing tool, apply_patch, hides its file names inside a shell command. Our own security review found two ways to sneak an edit past our checks: putting a cd command in front of the patch, and ending the patch text early. We fixed both and added tests. Every gap here would be a way around the gate.
Letting a teammate use your agent without giving them your power. A teammate's request runs on the owner's computer, as a copy of the owner's session with fewer permissions and its own git worktree. Questions can only read, and they can't open secret files like .env. Changes wait until the owner approves them. This works even while the owner's laptop is locked, and our server never holds a shell, a code access token, or an AI model key.
Keeping every computer in agreement. Each request moves through the same steps on every machine: waiting for the owner, queued, picked up, running, waiting for release, and released. The server, the runners and the hooks stay in sync through a live event stream. Every change and its audit log entry are saved together, in one database transaction, so the log can never miss a step. When we ran the system live, we found real timing bugs, and we fixed each one.
Stopping two agents from editing the same files. If one agent's plan claims files that another open plan already holds, the server refuses it. This works even when the agents run on different computers.
Hiding secrets everywhere. Results and audit logs are shown to other people. So everything an agent writes is scrubbed for secrets before the server saves it.
Being honest about the limits. We cannot stop the owner from removing their own hooks, because it is their computer. So the gate is enforced against teammates and against the agent, but it is only advisory for the owner. We built the design around that fact, wrote it plainly on our website, and added tests that fail if the website ever claims more.

Accomplishments that we're proud of

An end-to-end consent model: plan → approve → claim → run → release, with an audit row at every step.
A demo in which a teammate's agent tries to read .env, is denied, and the audit log records it.
The whole system deployed at cohort.cooking. The test suite passes in CI: 336 tests across 45 files.
A threat model written down honestly, and tests that fail if the site's copy overstates it.

What we learned

Trustworthy agents depend more on structure than on the model being smart: least privilege, explicit consent, and a log that cannot be skipped.
Agent hook systems differ in quiet but critical ways, such as whether they fail open or closed. You need to read the docs, pin versions, and test every edge.
Being precise about what is enforced and what is only advisory builds more trust than a big claim.

What's next for Cohort

Opening pull requests straight from approved turns, and more polished Claude Code, Cursor and Codex plugin install.
Allow users to create there own plugins for third-party tools by following an instruction set.