PicoClaw runs on a $10 board. Change one setting before it touches Stripe.
PicoClaw worked with Swytchcode on the first try in Docker. Running directly on a board, its shell tool could still reach Swytchcode's rules. One line in its config closes that.
PicoClaw is a personal AI assistant written in Go by Sipeed, the hardware company. It's tiny: it runs on $10 boards with around 10MB of memory, boots in milliseconds, and talks to you on Telegram, Discord, Slack, WeChat and more. It has 30,000 stars on GitHub.
An agent that small ends up in places you don't watch closely, like a board in a drawer, running scheduled jobs. That's exactly where its API calls need limits. So we connected PicoClaw to Swytchcode, which runs the agent's calls with your keys, holds every write for your approval, and keeps rules the agent can't change.
In Docker, it worked on the first try. Running directly on the machine, it needed one change.
In Docker: the config, line by line
With PicoClaw in Docker and Swytchcode on the host, the whole setup is one block in PicoClaw's config.json. First, start Swytchcode and get a token (you need a Swytchcode account, and approvals need the Business or Enterprise plan):
npm install -g swytchcode
swy init --operator --editor=none --project ~/agent-swy
swy login
swy mcp serve --profile operator --project ~/agent-swy --transport http -d
swy mcp tokenThen add this under tools in docker/data/config.json:
"mcp": {
"enabled": true,
"servers": {
"swytchcode": {
"enabled": true,
"type": "http",
"url": "http://host.docker.internal:5476/mcp",
"headers": { "Authorization": "Bearer <token>" }
}
}
}What each part does:
"enabled": true(the outer one). MCP is off by default in PicoClaw. This is the one line people miss."enabled": true(the inner one). Turns this one server on."type": "http"andurl. PicoClaw reaches Swytchcode on the host. Inside the container, there's no rules file and no keys.headers. The token that lets PicoClaw use Swytchcode's 11 tools, and nothing more.
Copy the skill into docker/data/workspace/skills/, which teaches the agent how to use Swytchcode, and restart. PicoClaw lists the skill by name and reads it when a request needs it.
That's it. All seven of our checks passed on the first try: reads ran, writes waited for approval, pasted keys were refused, and the agent couldn't loosen the rules, which live outside its reach.
On the board itself: turn exec off
On a $10 board, you probably won't run Docker. You'll run PicoClaw directly, with Swytchcode on the same machine. That's where the one change comes in.
PicoClaw has a sandbox that's on by default, called restrict_to_workspace. It keeps the agent's file tools inside its workspace folder, and it held against every path we tried: absolute paths, ../, all of it.
The exec tool, which runs shell commands, is different. It checks the text of a command, not where the command ends up. So a command can still find its way out of the workspace, and in our test, that was enough to rename the approval rule in a copy of Swytchcode's rules file. We're sharing the details with the PicoClaw team rather than spelling them out here.
The fix is to turn exec off, in ~/.picoclaw/config.json:
"exec": { "enabled": false }With that set, every one of our 12 attempts was refused, and all seven checks still passed. Three more things worth knowing:
- Keep
restrict_to_workspaceon. Yourconfig.jsonlives outside the workspace, so with the sandbox on, the agent can't edit the file to switchexecback on. - Scheduled jobs lose commands too. PicoClaw's scheduled jobs run commands through the same
exectool, so they stop running commands as well. - Chat users get exec by default. PicoClaw lets people messaging it on a chat channel use
execunless you change it. One more reason to turn it off.
For the native setup, add Swytchcode as a local command in config.json, and copy the skill to ~/.picoclaw/workspace/skills/. The PicoClaw setup guide has both setups in full, plus connecting your first app.
What we didn't test
We tested PicoClaw 0.3.1 from its Docker image, with a scripted model and a mocked Stripe, using its command-line chat. Our native run was in the same small Linux image, not on a real board. We haven't tested a real model, its chat channels, its web launcher, the Android app, or a real approval on a phone.
Small agent, small change
PicoClaw is careful in the ways that matter most. Its sandbox is on by default, its file tools stay put, and MCP is off until you ask for it. The one gap is a shell tool that trusts the words of a command more than where it goes.
In Docker, that gap doesn't matter, because there's nothing to reach. On a board, one line closes it. Either way, PicoClaw can keep running quietly in its drawer, and anything that moves money still waits for you.
More content
How to Debug an AI Agent That Called the Wrong API
Working backwards from the response your agent got to the tool-selection decision that caused it, which is where most of the real debugging time goes.
iPaaS Was Built for Integrations, Not Agents
Deterministic trigger-action versus non-deterministic tool choice, and why the governance model that works for one doesn't transfer cleanly to the other.
Build Your Own MCP Server or Buy an Execution Layer
The real cost line isn't the connectors. It's the maintenance of the stitching layer underneath them, and that bill doesn't stop arriving after launch.
