Poco-claw: a Claude Code agent behind a team chat UI and a container sandbox
A more beautiful and easier-to-use alternative to OpenClaw. It features a nicer Web UI, built-in IM support, a sandboxed runtime and channel-based team collaboration. Under the hood, it is powered by a Claude Code–based agent.
At a glance
- What is it?
- Poco-claw wraps a Claude Code based agent in a FastAPI and Next.js application with channels, a Docker sandbox and mem0 memory. The README is detailed on features and thin on configuration, so adoption means reading the deployment guide before trusting the quickstart.
- Who is it for?
- Adopt poco-claw if you want a Claude Code style agent reachable from DingTalk, Feishu or Telegram and you are willing to run the Docker stack yourself. Do not adopt it if you need a published configuration reference, an audited permission model for host directory mounts, or a project that has stopped renaming itself.
- Can I use it commercially?
- Yes. MIT 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 last received commits 41 days ago.
- What is it written in?
- Mainly Python, 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
What problem poco-claw is actually solving
Claude Code is a terminal program. It runs where you run it, it stops when you close the laptop, and the only person who can see its output is the person sitting in front of it. Poco-claw takes that agent and puts it somewhere else: a long-lived server with a web interface, chat channels, and a container in which the agent does its work. The README describes the goal as a safer, more beautiful and easier-to-use alternative to OpenClaw, and the feature list reads like a product spec for a shared coworker rather than a personal coding assistant.
The intended user is a small team that wants one agent instance several people can address. The README's channel collaboration section describes mentioning persistent agents in a conversation, turning messages into trackable tasks, watching progress in an execution drawer, and publishing outputs into shared files that both people and other agents can reuse. That is a different shape from a coding assistant in a terminal. It is closer to a chat bot with a job queue and a filesystem.
If you only ever run one agent for yourself on one machine, the channel and shared file machinery is overhead you will not use. The parts that would still matter are the sandbox and the artifact rendering, and those are available in simpler tools.
The architecture the repository implies
The badge list is the most concrete architectural statement in the README: Python 3.12 or newer, FastAPI 0.115 or newer, Next.js 16, and Docker. That points to a backend service exposing an API, a separate frontend application, and a container runtime underneath both. The README does not publish a diagram, a port map beyond the localhost:3000 address for the UI, or a description of how the frontend talks to the backend, so the exact wiring is something you would confirm from the deployment guide or the source tree.
The agent layer is described as a native Claude Code experience, which the README enumerates as Slash Commands, Plan Mode and AskQuestion. Preset runtime configuration is the mechanism for reuse: model, capability, tool and sub-agent settings are stored once and applied across projects and sessions. Project level defaults cover model, preset, Git repository, local mounts and project files. Memory is delegated to mem0, which the README says holds preferences, project context and past interactions.
Sandboxing is the load-bearing claim. The README states that all tasks run in an isolated container and that you can install dependencies, modify files and execute commands without affecting the host. Local directory mounting is called out as self-hosted only, which is a sensible boundary but also the point where the isolation story becomes a policy question rather than a technical guarantee. The README does not describe how mounts are scoped or revoked.
Getting it running: one script and a lot of unknowns
The quickstart is a single command, run from the repository root:
./scripts/quickstart.sh
The README describes it as an interactive setup script that generates configuration and starts services, and says the UI is then available at http://localhost:3000. That is the entirety of the setup documentation in the README. There is no list of environment variables, no compose file excerpt, no description of what the script writes or where, and no indication of which ports the backend uses.
The README points to a deployment guide at docs.poco-ai.com for detail and troubleshooting. Note that the repository also carries a homepage link to poco-docs.vercel.app, and the badge in the README points at docs.poco-ai.com. Two documentation hosts for one project is a small thing, but it means you should check which one is current before following instructions.
What the README does specify is the runtime floor: Python 3.12 or newer and Docker. The IM integrations named are DingTalk, Feishu and Telegram, described as embedded backend messaging with push notifications and event subscriptions. How credentials for those are supplied is not stated in the README. If you plan to connect a chat platform, budget time for reading the deployment guide before the first run.
Where the sandbox boundary gets blurry
The strongest claim in the README is isolation. The weakest part of the documentation is the same claim. Local directory mounting is described as letting the agent work with your real project files directly, and it is marked self-hosted only. Both of those are reasonable, but neither answers the question an operator will ask: what stops the agent from writing outside the mount, and what does revoking a mount actually do to files the agent already created?
There is a second boundary problem in the interaction layer. The README advertises background execution and scheduled triggers, meaning the agent keeps running after you close the browser. Combined with a mounted host directory and an inbound chat channel, you have an agent that can be triggered by a message from a chat platform, run unattended, and write to a directory on your machine. The README does not describe an approval step for channel-originated tasks. Plan Mode exists as a feature, but the README does not say it is enforced for messages arriving from DingTalk, Feishu or Telegram.
This is not an argument against the design. It is an argument for treating the sandbox as one control among several and reading the deployment guide's security notes, if it has them, before connecting a chat platform to a host mount.
The alternative, and where the two diverge
The obvious comparison is OpenClaw, which the README names directly as the thing poco-claw is an alternative to. The README's stated differences are a nicer web UI, built-in IM support, a sandboxed runtime and channel-based team collaboration. Those are real differences in shape, not just polish: OpenClaw as described here is the baseline the author is reacting to, and poco-claw's pitch is that the agent should live in a shared, browser-reachable place rather than a terminal.
A second, less direct alternative is running Claude Code itself, which is what poco-claw is built on. The README says the agent is Claude Code based, so the honest comparison is between the raw tool and this wrapper. Raw Claude Code gives you the native experience with no server, no channel layer and no container boundary. Poco-claw gives you the server and the boundary at the cost of a stack you have to operate: FastAPI, Next.js, Docker, and whatever the quickstart script writes.
If your work is one developer on one machine, the wrapper is a net loss. If your work is three people who want to ask an agent for a report in a group chat and get a file back, the wrapper is the point.
Maintenance, naming and the MIT licence
The release cadence visible in the material is tight: 0.5.5 on 2026-06-12, 0.5.6 on 2026-06-13, 0.5.7 on 2026-06-18, with a last push to main on 2026-08-06. Frequent patch releases at the 0.5.x line usually mean the surface is still moving. For an operator that translates to upgrade work: you should expect to re-read the deployment guide when you bump versions, and you should not assume the quickstart script's generated configuration survives an upgrade unchanged.
There is a naming problem worth flagging. The repository is poco-ai/poco-claw, the README title is Poco, the DeepWiki badge points at poco-ai/poco-agent, and the star history chart references poco-ai/poco-agent. Whether that is a rename in progress or two related projects is not stated in the material. Until it is clear, pin the commit or tag you deploy rather than tracking main.
The licence is MIT, which is permissive and places few obligations on how you redistribute or modify the code. That is a statement about the repository's licence file, not legal advice, and it says nothing about the licences of the model, the mem0 dependency, or any third-party service you connect through DingTalk, Feishu or Telegram. Those are separate questions and the README does not address them.
Who should run this, and what to check first
Poco-claw is aimed at a team that wants a Claude Code style agent reachable from a chat platform, running in a container, with outputs collected into shared files. The README's screenshots show exactly that workflow: a channel message mentions an agent, a task appears in an execution drawer, and the artifact lands in a shared file view grouped by agent. If that is the workflow you want, the feature set maps onto it directly.
It is the wrong tool if you need a stable configuration reference today. The README documents one command and one URL. Everything else about running it lives off-repository. It is also the wrong tool if you cannot accept an agent that writes to a mounted host directory under triggers you did not personally initiate. The README does not describe a channel-level approval gate, and Plan Mode is listed as a feature rather than as a mandatory step for inbound messages.
Before deploying, confirm three things. First, that the documentation host you are reading is the current one, since the README points at both docs.poco-ai.com and poco-docs.vercel.app. Second, that the image or build produced by scripts/quickstart.sh corresponds to the tag you intend to run, given the 0.5.x release pace. Third, that you have a way to remove a host directory mount and audit what the agent wrote under it. The README does not tell you how to do the third, so treat it as a gap you close yourself before the first channel message arrives.
Editorial conclusion
Adopt poco-claw if you want a Claude Code style agent reachable from DingTalk, Feishu or Telegram and you are willing to run the Docker stack yourself. Do not adopt it if you need a published configuration reference, an audited permission model for host directory mounts, or a project that has stopped renaming itself. Verify first that the container image referenced by scripts/quickstart.sh matches the repository you cloned, that the DingTalk, Feishu or Telegram credentials you intend to use are accepted by the current release, and that mounting a host directory is something you can revoke cleanly. The repository's own links split between poco-ai/poco-agent and poco-ai/poco-claw, and that ambiguity is the first thing to resolve.
Community notes