Content

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 token

Then 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" and url. 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_workspace on. Your config.json lives outside the workspace, so with the sandbox on, the agent can't edit the file to switch exec back on.
  • Scheduled jobs lose commands too. PicoClaw's scheduled jobs run commands through the same exec tool, so they stop running commands as well.
  • Chat users get exec by default. PicoClaw lets people messaging it on a chat channel use exec unless 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