Buckle was built to give AI agents cross-device access without full device access. Please join the early access and provide feedback, ideas, and anything else that helps make it a better cross-device access MCP!

Why Buckle?

Buckle is a remote execution harness that runs on your machines. It gives AI agents scoped access to a machine's environment, whether that is a container, a remote server, or your laptop. Connect the device that runs the AI agent to Buckle over HTTP, and let the agent do the work for you.

I'm building a bigger ecosystem for AI agents, 5straps, to provide a centralized, auditable agent network for enterprise use. Buckle is one of the components on the way there.

The Problem Buckle Solves

Buckle has one end goal: simplify and scope the same AI agent's access to the environments you give it.

Examples:

  • For personal use: Give the AI agent in your coding server container access to your laptop to run autonomous browser testing, and to set up and deploy the project on the VPS you rented. Duplicate the repo and setup on another device you own, for working on the go.

  • For teams and enterprises: Expose your test servers only through the tools your team's AI agents need to run inspections and deployment fixes. More support for teams and enterprises comes later.

One agent working across three Buckle environments: a server and two browsers

One agent, three Buckle environments. The server runs npm test and npm run build but refuses a curl install that is not on its command allow list, browser A reads the nodejs.org page title, and browser B is blocked from following a link to iana.org.

How Buckle Works

It hosts an MCP server over HTTP (or stdio for local use) with the tools and approval rules you set, such as file access, a sandboxed shell, web fetch, a browser, and Git once you turn it on.

For new or unknown actions, the user can approve or deny them.

An agent's rm -rf is held until a person denies it

Left, an agent's MCP calls. Right, me in buckle approvals --watch. The agent's rm -rf dist is held. I see the whole action and deny it. The agent gets PERMISSION_DENIED, lists dist and finds the files intact, then tries a web_fetch to github.com and is refused: not on the approved list.

How the Rules Work

Every call is allowed, asked, or denied before anything runs. Deny wins.

  • Command globs: buckle policy allow-command 'pnpm {build,test} *' lets only matching command lines run. deny-command refuses a pattern. A built-in floor asks before sudo, rm -r, git push --force, and similar.
  • Approved URL list: buckle policy allow-url nodejs.org adds a host. web_fetch, browser navigation, and forge pushes reach only what the list names, and the default fresh browser blocks clicked links to hosts off it. A host off the list is refused, never asked. With no list, public hosts are reachable.
  • Mounts: buckle init shows your project to the agent at /workspace, and a path outside it and its mounts is refused. buckle workspace mount add ~/docs:/docs:ro shares another folder read-only. The first write to each directory asks.
  • Credential files: .env, .ssh/, and *.pem ask every time, even inside a folder I already granted.
  • Secret references: the agent writes {{file:.env.local:NAME}} in a command, a browser fill, or a request header, and sees [secret:NAME] where the value would come back. Dotenv files only.
  • Full action on every ask: the approver sees the node, rule, working directory, every effect, and every argument, uncut, with common credential shapes hidden. The decision binds the exact call. I answer once, for the session, or always; a destructive command never offers always.
  • Audit log: buckle log reads what Buckle did. It is append-only, not tamper-proof.

Try It! 

npm i -g @5straps/buckle # Node.js 24 or newer cd ~/some/project buckle init claude mcp add buckle -- buckle mcp

In a second terminal, in the same folder:

buckle approvals --watch

Limits

  • Platforms: Tested in Linux and partially in Windows. Note: Linux runs commands in sandbox via bubblewrap, while no sandbox for other platforms.
  • Command reading: Buckle asks about or refuses a command it cannot read whole. A script file on disk is not read: bash deploy.sh is judged by those two words.
  • Credential hiding: covers common shapes, and only in what the approver sees.
  • URL list: blocking clicked links holds in the default fresh browser, not with a profile folder or an attached Chrome.
  • Service: buckle service install starts the node at login.

Next

  • More tools through plugins, starting with desktop control on agent-desktop.
  • Simpler deployment.
  • Exportable rules.
  • Enterprise support on request.

Feedback

What would stop you from using it? Report bugs and request features in GitHub issues. Ask questions and share ideas in Discussions. If you run agents on real machines and can spare 15 minutes, say so there.

Repo: wuiyang/5straps-buckle, Apache-2.0. Package: @5straps/buckle.