AstrBot has some of the safest defaults we've tested. One Python bug stands in the way.

AstrBot is an open-source chatbot platform with over 40,000 stars on GitHub. It connects AI agents to QQ, WeChat Work, Feishu, DingTalk, Telegram, Slack and more, with MCP, skills, a knowledge base and over a thousand plugins.

We've been connecting Swytchcode to one self-hosted agent after another. Swytchcode runs the agent's API calls with your keys, holds every write for your approval, and keeps rules the agent can't change. With most agents, the hard part is keeping the agent's own shell away from those rules.

With AstrBot, that part was easy. The hard part was a bug that had nothing to do with security at all.

Safe by default

Out of the box, AstrBot's agent has no shell and no file tools. Those come with a feature called Computer Use, and it's off until you turn it on. So with Swytchcode connected, the agent had Swytchcode's 11 tools and a couple of AstrBot's own messaging tools. Nothing that could reach the rules file.

That's one of the safest defaults we've tested.

The admin catch

Turn Computer Use on with the local runtime, and AstrBot treats two kinds of users differently. Members get file tools inside a workspace folder, and no commands. Admins, which usually means you, the owner, get the whole machine: shell, Python and files anywhere.

As an admin, our test agent renamed the approval rule in a copy of the rules file, read the token it uses to reach Swytchcode, and wiped its own MCP config. The rules are only safe if the agent can't edit them, and an admin's agent could.

The fix is one setting: give admins the workspace scope too.

Who is chatting

Computer Use off (default)

On, default scopes

On, admin set to Workspace

A member

No shell or files

Workspace files, no commands

Workspace files, no commands

An admin

No shell or files

The whole machine

Blocked outside the workspace

With the admin set to Workspace, every attempt we made was blocked. Commands were refused outright, because AstrBot needs bubblewrap to sandbox them and won't run them unsandboxed. Admins can still write to AstrBot's skills folder, so keep an eye on what lands there.

The bug that stopped every call

Here's the surprise. Read-only tools like search worked. But swytchcode_exec, the tool that actually makes API calls, failed every single time with this:

execute() got multiple values for keyword argument 'tool'

The cause is a Python detail that's easy to miss. AstrBot runs an MCP tool with a function shaped like this:

async def execute(cls, tool, run_context, **tool_args):
    ...

await execute(tool=func_tool, run_context=ctx, **tool_args)

The tool's own arguments get spread in as keyword arguments. Our exec tool has an argument called tool, which is the name of the API method to call. So Python receives tool twice, once from AstrBot and once from us, and gives up.

Any MCP tool with an argument called tool, run_context or context would hit the same wall. It's not specific to Swytchcode.

The fix is small. Python has a marker, /, that makes the arguments before it positional only, so they can't clash with keyword arguments:

async def execute(cls, tool, run_context, /, **tool_args):
    ...

await execute(func_tool, ctx, **tool_args)

The same change is needed in two more functions down the chain. With it applied inside our test container, all seven of our checks passed: reads ran, writes waited for approval, pasted keys were refused, and the agent couldn't loosen its rules. That held as a member, and as an admin with the workspace scope.

We're sending the details to the AstrBot team. Until a fix ships, swytchcode_exec won't work in AstrBot 4.29.1, so connect it once the fix is in.

Set it up

These steps run AstrBot in Docker, with Swytchcode on the host. 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

On Linux, add --bind with Docker's bridge address to the serve command, as in our docs page for any other agent.

Add the server to AstrBot's data/mcp_server.json:

{
  "mcpServers": {
    "swytchcode": {
      "url": "http://host.docker.internal:5476/mcp",
      "transport": "streamable_http",
      "headers": { "Authorization": "Bearer <token>" },
      "active": true
    }
  }
}

Use HTTP. AstrBot only starts local MCP servers from a short list of allowed commands, and swytchcode isn't on it.

With Computer Use off, AstrBot lists skills by name but can't open them. So paste the body of Swytchcode's SKILL.md into your persona's prompt instead. If you turn Computer Use on, set the admin scope to Workspace first.

We tested AstrBot 4.29.1 through its Open API, with a scripted model and a mocked Stripe. We haven't tested a real model, its chat platforms, the persona prompt, or a real approval on a phone.

Good defaults, one bad assumption

AstrBot got the hard part right. It starts with no shell, and it sandboxes commands or refuses them. Very few agents are that careful.

What tripped it up was an assumption: that a tool's arguments would never share a name with AstrBot's own. MCP tools come from anywhere, so that's a risky bet. A few small changes make it safe, and once it ships, AstrBot will be one of the easiest agents to run with Swytchcode.