HappyClaw

The deciding trait is that it was designed for more than one person from the start. Most tools in this category are a single developer's setup with a login bolted on later, and you feel it the first time two people want the same thing at once. Here the multi-user question was asked before the interface was drawn.

What you take on is running it: a server, an upgrade path and somebody who owns the box. Pick it when the group is real. Pick a terminal agent when you are describing a habit rather than a team.

The containment is real and asymmetric. Regular users get an isolated execution environment, which is the correct default and more than most competitors attempt. Administrators get the host filesystem, which means the security property of the whole system is a role assignment in a database. Anyone who can grant that role can leave the box, and prompt injection reaching an administrator session reaches everything they can reach.

What it does right is refuse to reimplement the agent loop. It runs a version-locked vendor runtime directly, so behaviour tracks what that vendor actually tested.

1. Most implementations conflate these three, which is why they cannot answer what a given agent is permitted to do independently of what it happens to be doing. Separating durable identity from durable resources from ephemeral context makes each question answerable on its own. 2. The workspace is defined as both a file and an execution boundary, so the security scope and the memory scope coincide rather than cross-cutting.

2. No evaluation is published. The claim here is structural and the correct reading is that the decomposition is principled, not that it has been measured.

The distribution choice is the interesting signal. Meeting users inside the messaging platforms they already live in is cheap, effective and completely unownable, because the platforms belong to somebody else and the integrations are the first thing a competitor copies. Eight hundred stars is real early interest and there is no entity, no tier and no revenue line behind it.

Moat: none durable. Likely path: a hosted version appears, or the project stays a very good personal deployment. Position: self-host it, keep your own backups, and assume the maintainer is the roadmap.

Three quarters of my checklist is already here, which is more than I expected. I can see what ran, prove that a result was delivered, read the usage figures per person and restore the whole thing from a consistent backup, and none of that required a tier upgrade or a sales call.

What is missing is identity. There is no single sign-on and no provisioning, so accounts are created and removed by hand and a departure is a manual checklist. Nothing runs in a build pipeline either. Approved with conditions: one team first, and offboarding scripted before the second team joins.

Scoping tool servers and secrets to the same boundary is the configuration I usually have to fake with directory permissions. One workspace, one set of servers, one set of credentials, and no accidental sharing between projects because the boundary is the same object.

Exposing its own tools back over the protocol is the part I did not expect. That makes this addressable from anything else I run rather than only from its own interface, which is the difference between a product and a component. Permissive licence, my hardware, my container.