Sandboxed CLI

7 actions

Connect Claude to Bash

Run shell commands in the project's own sandbox, or read files, list directories and search the filesystem under a narrower read-only grant. Toolspoke puts 7 of its actions behind one MCP endpoint that Claude, Cursor, and Codex all speak.

Connect View pricing

Connection: Sandboxed CLI
Authentication: None
Actions exposed: 7
Cost per call (typical): 5 credits
Adapter: Maintained by Toolspoke

Connected in three steps

1
Install Bash
Open the marketplace in your workspace, add Bash to the project your agents work in, and it appears on the gateway immediately.
2
Connect the credential
Nothing to connect. Bash needs no credential.
3
Point your agent at the gateway
Give your client one address, https://toolspoke.com/mcp. Claude Code takes it as a command, Claude and Claude Desktop add it as a custom connector, and Cursor, Codex and VS Code each read it from a config file of their own.

.mcp.json

{
  "mcpServers": {
    "toolspoke": {
      "type": "http",
      "url": "https://toolspoke.com/mcp"
    }
  }
}

One block covers every tool you have installed. Bash shows up in the client as soon as your policy allows it, and so does everything else you install later.

Where the address goes, per client

Claude Code: Run it in your project, then /mcp to sign in
claude mcp add --transport http toolspoke https://toolspoke.com/mcp
Claude and Claude Desktop: Settings, then Connectors, then Add custom connector
https://toolspoke.com/mcp
Cursor: ~/.cursor/mcp.json, or .cursor/mcp.json for one project
{ "mcpServers": { "toolspoke": { "url": "https://toolspoke.com/mcp" } } }
Codex: ~/.codex/config.toml
[mcp_servers.toolspoke] url = "https://toolspoke.com/mcp"
VS Code: .vscode/mcp.json, or the MCP: Add Server command
{ "servers": { "toolspoke": { "type": "http", "url": "https://toolspoke.com/mcp" } } }

What Bash asks for

Bash needs no credential. There is nothing to go and fetch: the settings below are optional, and they are configuration rather than secrets.

Working directoryOptional: Optional. Every operation starts here and relative paths resolve against it. /workspace is the only writable directory in the sandbox, so leave this blank unless you want the shell pinned to a subdirectory of it.; /workspace

What Claude can do in Bash

7 actions, each one declared and named by the connector rather than discovered at runtime. A workspace policy grants a person all of them, a hand-picked selection, everything on the read side, everything on the write side, or none.

Reads: 5Reads
Writes: 1Writes
Destructive: 1Destructive

Reads

Fetches data and changes nothing.

sandbox_info
Report what this sandbox is: bash version, kernel, working directory, free space, and which of the common command-line tools are installed. Call this first when you are unsure whether a tool you want to use exists.
list_directory
List one directory in long format, including dotfiles. The path is passed to the shell as data, so this can never run a command - it is safe to grant on its own. Use find_files to search a tree.
read_file
Return the contents of one text file, optionally from a starting line. The path is passed to the shell as data and cannot become a command. Output is truncated at 100,000 characters, so page through a large file with start_line.
search_files
Search file contents recursively and return matching lines as path:line:text. The pattern is an extended regular expression (grep -E); binary files are skipped. No matches is a successful empty result, not an error.
find_files
Find files and directories by name under a directory tree, using a shell glob such as "*.test.ts". Searches names only - use search_files to search contents.

Writes

Creates or updates something on the other side.

write_file
Create or overwrite one file with the given text, creating parent directories as needed, and report the byte count written. Only /workspace is writable. This replaces the file without warning and cannot append - read it first if you need to keep what is there.

Destructive

Deletes or permanently alters something. Worth granting on purpose.

run_command
Run an arbitrary shell command line in the sandbox and return its stdout, stderr and exit code. One self-contained line or `&&` chain: the process is discarded afterwards, so a cd, an export or a background job does not carry over to the next call. Killed at 20 seconds. A non-zero exit is raised as an error carrying stderr, and that call's stdout is lost - append `2>&1 || true` when you need the output of a failing command.

What it will not do

Enforced by the gateway rather than left to convention, which is why each of these can be stated flatly.

It cannot call anything else: The 7 actions above are the whole of it. A call to any other name is refused before it reaches Bash rather than forwarded on, and connecting your account does not add to the list: it is fixed by the connector, not discovered at run time.
It reaches no further than your credential: Toolspoke holds no access to Bash of its own. Every call carries the credential you stored and nothing besides, so whatever that credential cannot reach, this connector cannot reach either.
It never hears from Bash: Nothing is pushed to it. There is no webhook, no subscription and no polling, so this connector cannot notice by itself that something changed in Bash. An agent has to ask.
It does not smooth over provider limits: Toolspoke does not retry, queue or back off around Bash's own rate limits. A call that Bash refuses comes back to the agent as a failed call.

Using Bash with an agent

Written by whoever built this connector. Agents read the same text on demand through read_guide, so what is below is what they see.

Bash

Every tool below runs one command in this project's sandbox container. Read this first - the sandbox does not behave like a terminal you have open, and the two differences that matter (no state between calls, a hard 20 second limit) will otherwise be discovered by a call that silently does nothing.

What the sandbox is

A per-project container built from node:22-bookworm-slim: Debian bookworm, running as an unprivileged user (uid 10001) with no sudo. /workspace is the writable directory and the default working directory; the rest of the filesystem is readable but should be treated as read-only. The container is attached to the sandbox and egress networks only - the public internet is reachable, Toolspoke's own database and application network are not.

The base image carries bash, GNU coreutils, find, grep, sed, awk, tar, plus ca-certificates, curl, git, jq, python3 (with a venv on the PATH), postgresql-client and default-mysql-client. Nothing else is installed, and apt-get install will fail - there is no root. Call sandbox_info if you want the live list rather than this one.

Each call is a new process

There is no session. Every call spawns a fresh bash -c, and when it exits everything about it is gone: the working directory, exported variables, shell functions, background jobs.

Chain what belongs together in one command: cd src && npm ci && npm test, not three calls.
export FOO=bar in one call is invisible to the next. Put it on the same line.
A server started with & is killed when the call ends. There is nothing to connect to later.
Files written under /workspace do survive between calls, for as long as the project's

sandbox stays alive. That is the only state you can rely on, and it is not a guarantee - the sandbox is recreated whenever the project's tool set changes.

Limits

20 seconds per command, wall clock. A longer command is killed. Nothing partial comes

back; prefer head/-n limits and narrower paths over waiting.

stdout is truncated at 100,000 characters, stderr at 10,000. Filter in the shell rather

than asking for everything and reading the tail.

Memory is 512 MB unless the project has a heavier connector installed.
Network egress is allowed, so curl works. Private and loopback addresses are not routable.

Reading the result

A command that exits 0 returns { "stdout": …, "stderr": …, "exitCode": 0 } - check stderr even on success, since warnings land there. A command that exits non-zero is raised as a tool error carrying its stderr, and the stdout it had produced is lost. When you want a failing command's output, capture it yourself: mytool 2>&1 || true.

One quoting rule

The sandbox expands {{name}} in the arguments it is handed, so a command or file content containing a literal {{word}} is rejected with Missing CLI input word. This bites on Handlebars, Jinja, Vue and Mustache templates. Write the braces apart - {'{'}{'{'} in a heredoc, or printf '{%s{name}}' '{' - or build the file with sed. {{ .Field }} (Go templates) and {{#each}} are unaffected, because only a bare identifier matches.

Which tool to reach for

run_command is the general one and it is classified destructive, so it needs a full grant - it can delete the workspace. The others exist so a team can hand out useful shell access without that:

Tool	Kind	Use it for
`sandbox_info`	read	What this sandbox is and which commands exist. Call it first when unsure.
`list_directory`	read	One directory listing.
`read_file`	read	A file, or a line range of one.
`search_files`	read	Content search (`grep -rnIE`, extended regular expressions).
`find_files`	read	Filename search by glob.
`write_file`	write	Create or overwrite one file, parent directories included.
`run_command`	destructive	Anything else.

The five read tools take their path as a positional parameter the shell never re-parses, so they cannot be turned into command execution by a crafted argument - that is what makes a read-only grant on this connector meaningful. Do not route a read through run_command because it is more familiar; a caller holding only a read grant will be refused, and the narrow tool is the one that works for them.

Habits that pay off here

Prefer git, jq and grep over hand-written parsing; they are installed and fast.
Quote every path ("$file"), and use -- before user-supplied paths in your own commands.
Check before you clobber: write_file overwrites without asking.
npm ci on a real project will not finish in 20 seconds. Scope the work.

Before you connect it

What can Claude do in Bash?

7 named actions: 5 that only read, 1 that write and 1 that delete or permanently alter something. They include sandbox_info, list_directory and read_file. Nothing outside that list is reachable: the connector declares each operation by name rather than proxying whatever an agent asks for.

What credentials does the Bash connector need?

None at all. Bash is reachable without one, so there is nothing of yours for Toolspoke to store. The connector does take working directory as optional configuration.

Does the Bash connector work with Cursor and Codex, or only Claude?

Any client that speaks MCP, and every one of them gets the same 7 actions. There is a single address, https://toolspoke.com/mcp. Claude Code adds it with claude mcp add --transport http, Claude and Claude Desktop take it as a custom connector in settings, Cursor reads it from .cursor/mcp.json, Codex from ~/.codex/config.toml, and VS Code from .vscode/mcp.json. Each of them signs in to the gateway itself, so there is no key to paste.

What does the Bash connector not do?

The 7 actions above are the whole of it. A call to any other name is refused before it reaches Bash rather than forwarded on, and connecting your account does not add to the list: it is fixed by the connector, not discovered at run time. Toolspoke holds no access to Bash of its own. Every call carries the credential you stored and nothing besides, so whatever that credential cannot reach, this connector cannot reach either. Nothing is pushed to it. There is no webhook, no subscription and no polling, so this connector cannot notice by itself that something changed in Bash. An agent has to ask. Toolspoke does not retry, queue or back off around Bash's own rate limits. A call that Bash refuses comes back to the agent as a failed call.

Can I limit which actions an agent can call?

Yes, in two places. The project switches Bash's actions on and off one at a time, for everyone in the project at once, and the screen groups them by read, write and destructive so turning off everything that deletes is one click. An individual agent key can then be narrowed further, to particular toolkits in a project and to particular actions in a toolkit. Whatever it was granted, a key never reaches a project its owner cannot.

What gets recorded when an agent calls Bash?

Every attempt, with the agent that made it and the person that agent belongs to, the full request payload, the response payload, the status, the duration, and the credits spent. Values whose key names a secret are masked out before the record is shown to anyone. An operation the connector marks as not retained never has its response body written at all, so the gateway keeps no second copy of what was read.

More developer tools connectors

Browse all of them