shell-0
shell-0 is an unsandboxed MCP server providing direct access to the local machine's filesystem, Python runtime, Node.js runtime, and shell, with a forensic audit trail for all actions.
fs — Filesystem Operations
Read (50 MB cap), write, append, insert, or replace lines; auto-fixes code fences and smart quotes on write
Edit files with targeted
[{old_text, new_text}]patchesList directories, generate tree views, stat files
Search/grep with regex or substring, context lines, and glob filters
Copy, move, delete files/directories, create directories, touch files
Diff two files or strings, compute SHA256/MD5 checksums, find duplicate files by hash
Read just the head or tail of a file
python_exec — Run Python Code
Execute arbitrary Python with full standard library and any installed packages
Unsandboxed: file I/O, network access, subprocess execution all permitted
Persistent module-level state across calls
Optional pre-import of numpy/pandas via
extended_imports30s default timeout, 8 GB memory limit (POSIX)
terminal — Run Shell Commands
Execute any shell command (bash on Unix, cmd.exe on Windows) with full system privileges
Supports pipes, redirects,
&&,||, background jobs (start, poll, kill viatask_id)Up to 600s timeout for long-running tasks
js_exec — Run JavaScript (Node.js)
Execute JavaScript in a real Node.js environment with
require(), async/await, and ES6+Persistent
stateobject saved to.shell0_js_state.jsonacross calls30s default timeout (up to 600s), 100 KB output cap; requires Node.js on PATH
Forensic Audit Log (on by default)
Logs all filesystem changes (with before/after snapshots), code executions, and shell commands
Stored under
./data/, self-pruning at 50 MBFor accountability only — not a security sandbox; disable with
SHELL0_AUDIT_DISABLE=1
Configuration & Integration
Tune timeouts, memory limits, output caps, and audit paths via environment variables
Communicates over stdio; optional HTTP bridge (
mcp-http-bridge) availableWarning: fully unsandboxed — do not expose over a network
Click on "Deploy Server".
Wait a few minutes for the server to deploy. Once ready, it will show a "Started" state.
In the chat, type
@followed by the MCP server name and your instructions, e.g., "@shell-0 run 'df -h' to check disk space"
That's it! The server will respond to your query, and you can continue using it as needed.
Here is a step-by-step guide with screenshots.
shell-0
An MCP server that gives a model direct, unsandboxed access to the local machine: files, a Python runtime, a Node.js runtime, and a shell. Four tools, full system access, no guardrails.
This is deliberately not sandboxed. Point it at a machine you control, and understand the blast radius before you wire it into an agent.
Tools
fs- filesystem access: read, write, edit, copy, move, mkdir, rmdir, list, tree, search, grep, stat, diff, hash, touch, head, tail, and duplicate detection. 50 MB read cap (FS_MAX_READ_BYTES), no file-watcher race conditions. Content is written as sent: an existing file keeps its line endings and encoding (UTF-8, UTF-8 BOM, UTF-16, Latin-1), and new files get exactly what was sent, except.bat/.cmd, which use CRLF. Only.pyand.jsonget repairs (code fences, smart-quote delimiters), only when the content doesn't parse, and a repair is kept only if it makes the content parse. A Python write that still won't parse is rejected; other file types are never rewritten.editreplaces exact text with no re-indenting and fails ifold_textmatches more than once, unlessreplace_allis set.python_exec- run Python with the full standard library and whatever is installed in the server's environment. Code runs in a persistent worker subprocess, so module-level state survives across calls and a timeout is a realSIGKILLof the worker, not a best-effort nudge - the next call just gets a fresh one. Broken code gets fence and quote repairs, kept only if the result parses.js_exec- run JavaScript in a real Node.js process. Astateobject persists across calls, loaded from and saved to a JSON file on disk; concurrent calls are serialized so they can't race that file. Requires Node.js on PATH.terminal- run shell commands (cmd.exe on Windows, bash elsewhere), with optional background jobs you can poll and kill. A timeout kills the whole process tree it spawned, not just the top-level command. cmd.exe refuses multi-line commands, because it would silently run only the first line. On Windows,shell='wsl'runs the command as a bash script in WSL with no cmd quoting in between, so%, quotes and multi-line scripts are safe, and its timeouts and kills stop only that command's own processes. Output decodes correctly from UTF-8, the Windows OEM code page, or UTF-16, and keeps its indentation.
Related MCP server: maic-server-fs-mcp
Forensic audit (on by default)
Every filesystem change and every code or command execution is written to a rolling on-disk audit log, so nothing the tools do is silently lost:
Every write mode (overwrite, append, insert, replace_lines), edit, copy, move, and delete is snapshotted with its previous contents before the change - including whatever an overwriting
copy/moveis about to clobber at the destination - so any of them is recoverable.Reads, greps, filename searches, and touches are timestamped in an access log.
Python, JavaScript, and shell executions are saved with their source, status, and output.
Logs live under ./data/ next to the server, split into per-session folders, and self-prune at 50 MB (oldest first, checked on every write - not just at startup). This is accountability, not sandboxing. The tools still do whatever you ask; you just get a full paper trail of it. The one exception: rmdir refuses to delete drive roots, UNC roots, or your home directory outright, with no override - the only hardcoded guardrail in an otherwise unrestricted tool.
Move it with FS_AUDIT_ROOT / EXEC_AUDIT_ROOT, or turn it off entirely with SHELL0_AUDIT_DISABLE=1. Each tool module (tools/filesystem.py, tools/python_runner.py, tools/js_runner.py, tools/terminal_exec.py) carries its own copy of this audit logic rather than importing a shared one - deliberately, so any single tool file can be lifted out and dropped into another project with nothing else to bring along.
Install
Requires Python 3.10 or newer (tested on 3.12).
Install as a package to get a shell-0 command on your PATH (recommended - an isolated installer keeps it off your system Python):
pipx install git+https://github.com/cutlerbenjamin1-cmd/shell-0
# or run it ad-hoc without a checkout:
uvx --from git+https://github.com/cutlerbenjamin1-cmd/shell-0 shell-0From a local checkout: pip install .
Or skip packaging entirely, install the one dependency, and run server.py directly:
pip install -r requirements.txtFor js_exec, install Node.js from https://nodejs.org and make sure node is on your PATH. python_exec(extended_imports=true) can pre-import numpy/pandas if you add the extra: pip install "shell-0[extended]".
Use it with an MCP client
shell-0 speaks MCP over stdio. If you installed the package, point your client at the shell-0 command:
{
"mcpServers": {
"shell-0": {
"command": "shell-0"
}
}
}If you did not install it as a package, point python at server.py with an absolute path instead:
{
"mcpServers": {
"shell-0": {
"command": "python",
"args": ["/absolute/path/to/shell-0/server.py"]
}
}
}On Windows, if the command is not found, use the full path to the installed shell-0.exe (in your pipx/venv Scripts directory) or to python.exe, with forward slashes or escaped backslashes. There is a ready-to-edit copy in example_config.json.
Running over HTTP (optional)
shell-0 speaks stdio. If your MCP client wants HTTP instead (llama.cpp's web UI, OpenWebUI, and similar), there is a companion bridge that serves shell-0 over MCP streamable HTTP: mcp-http-bridge. Run it from this directory and point your client at http://127.0.0.1:8818/mcp.
WARNING: do not expose shell-0's tools over the network without thinking hard first.
shell-0's tools (
terminal,python_exec,js_exec,fs) run unsandboxed with your full privileges. Serving them over HTTP on anything other than127.0.0.1hands remote code execution to anyone who can reach the port - and even on127.0.0.1, a web page in any browser tab can reach a loopback port, which is why the bridge validates theOriginheader. The bridge ships a filter that disables every execution tool andfsby default (arbitrary file write is RCE-equivalent), rejects unknown browser origins, and supports a shared-secret header. Leave those defaults unless you have put real authentication and TLS in front of it, and even then only enable what you actually need.
Configuration
All optional, set as environment variables:
SHELL0_AUDIT_DISABLE- set to1to turn the audit off (default: on).FS_AUDIT_ROOT/EXEC_AUDIT_ROOT- move the audit logs somewhere other than./data.FS_AUDIT_MAX_MB/EXEC_AUDIT_MAX_MB- audit size cap before pruning (default: 50).FS_MAX_READ_BYTES- full-file read cap in bytes forfs(action="read")with nolimit(default: 50MB). Chunked reads (offset/limit) stream instead of loading the whole file, so they aren't subject to this cap.FS_MAX_TREE_DEPTH- max directory depth fortree,search, andgrep(default: 15).OUTPUT_MAX_CHARS- hard cap on a single tool result before it gets truncated (default: 15000).PYTHON_EXEC_TIMEOUT-python_exectimeout in seconds (default: 30).PYTHON_EXEC_MAX_MEMORY-python_execworker address-space cap in bytes (default: 8GB). POSIX only (RLIMIT_AS); no-op on Windows, which has no equivalent cheap hard cap.PYTHON_EXEC_MAX_OUTPUT- max captured stdout/stderr chars perpython_execcall before clipping (default: 1,000,000).JS_EXEC_TIMEOUT-js_exectimeout in seconds (default: 30).MCP_DEBUG- set totruefor stderr debug logging.
A word on safety
These tools run with your privileges and no sandbox. terminal and python_exec can do anything you can do from a shell. That is the whole point, but it means you should only connect shell-0 to agents and inputs you trust, on a machine where that access is acceptable. The audit log helps you see what happened after the fact. It does not stop anything from happening.
License
MIT. See LICENSE.
Testing
shell-0 has a pytest suite (coverage + regression + a live-stdio smoke layer) and
an interactive driver. Full details, including the regression provenance table,
are in tests/README.md.
pip install -e ".[test]" # test deps, into a venv
pytest # full sweep
pytest -m regression # only the guards for bugs actually hit
python manual.py # drive the real server by hand over stdioThe suite is hermetic: every test runs in a temp dir with the forensic audit
redirected, and never touches paths outside it. The js_exec tests skip
automatically when Node.js isn't on PATH.
Available Tools
4 toolsfsA
Full shell filesystem access (UNSANDBOXED, 50MB read limit). Use for all file operations. Doesn't encounter race conditions with file watchers. grep contains all the functionality of bash + powershell filesystem search. Auto-fixes code fences and smart quotes on write. Actions: read, write, edit, delete, copy, move, mkdir, rmdir, list, tree, search, grep, stat, diff, hash, touch, head, tail, duplicates. edit: [{old_text, new_text}]. grep: regex search in directories. diff: compare files/strings. hash: SHA256/MD5 checksums. duplicates: find duplicate files by hash.
Inputs: action (required), mode, path, edits, +27 more.
js_execA
Execute JavaScript code in a full Node.js environment. Returns an object with keys: success (bool), output (combined stdout/stderr), stdout, stderr, exitCode, and outputTruncated (bool if output exceeded 100KB). Use this tool when: (1) manipulating JSON data where JavaScript's native handling is cleaner than Python, (2) testing algorithms where JS syntax is preferred, (3) using npm packages not available in Python, (4) working with Node.js-specific APIs. Do NOT use this tool when: (1) generating visualizations - Node.js has no DOM, canvas, or browser APIs (use python_exec with matplotlib instead), (2) the task is equally achievable in Python (prefer python_exec for consistency). The tool provides persistent state across calls via a state object that is automatically loaded from and saved to .shell0_js_state.json in the working directory. Assign values to state.myKey to persist them between invocations. Limitations: 30-second default timeout (configurable up to 600s), 100K character source limit, 2000 line limit, 100KB output cap. On timeout the process is killed. Syntax errors return in stderr with line numbers. Requires Node.js on PATH.
Inputs: code (required), timeout.
python_execA
Execute Python code with full system access. Returns {success, output, result, error}. Use for: data processing, file operations, API calls, system automation, any Python task. Prefer over js_exec unless JS-specific features needed. UNLOCKED: all imports (os, subprocess, requests, pathlib), file I/O, network access. Persistent state via module-level variables across calls. Limits: 30s timeout (PYTHON_EXEC_TIMEOUT env), 100k chars, 2k lines, 20k AST nodes.
Inputs: code (required), extended_imports.
terminalA
Execute shell commands. Returns {success, output, exit_code, duration_seconds}. Use for: git, npm, pip, system commands, anything requiring shell. UNRESTRICTED - full privileges, no sandboxing. Windows: cmd.exe, Unix: bash. Timeout: 120s default, 600s max. Background: run_in_background=true returns task_id. Use bg_status/bg_kill/bg_list to manage. For file ops prefer fs; for Python prefer python_exec.
Inputs: cwd, bg_kill, bg_list, command, +4 more.
Tool Schema Changelog
Recent tool additions, removals, and schema changes observed during successful MCP inspections.
Loading tool schema changelog…
TDQS
Scored across 4 tools
Tools are generally distinct but have overlapping capabilities: terminal can run scripts that js_exec and python_exec handle, and fs operations can be done via terminal as well. Descriptions provide guidance, but an agent might still be uncertain about which tool to use for mixed tasks.
Naming is inconsistent: 'fs' and 'terminal' are noun-based, while 'js_exec' and 'python_exec' follow a language+verb pattern. This mix makes the set less predictable.
4 tools is appropriate for a general-purpose shell server, covering files, two scripting languages, and raw command execution. It is slightly on the lower side but not insufficient.
The tool surface covers the core domain of shell operations: file management, code execution, and system commands. Missing features like persistent state sharing across executors or advanced process control are minor gaps.
Maintenance
Related MCP Connectors
Remote MCP server exposing your Node Command fleet (files, shell, processes, browser) to AI hosts.
Use a person's computer after they approve it there: files, Terminal, browser, local MCP.
Use a person's computer after they approve it there: files, Terminal, browser, local MCP.
Your org's AI agents, tasks, runs, search, and brain files as MCP tools and resources.
Related MCP Servers
- FlicenseBqualityNot gradedmaintenanceProvides unrestricted access to your development environment with filesystem operations and shell command execution capabilities, including sudo support for local development machines.49-
- AlicenseAqualityDmaintenanceProvides LLMs with local filesystem operations (read/write files, list directories) and command execution via MCP, enabling file management and task automation within AI clients.715 npmISC
- AlicenseNot gradedqualityBmaintenanceGives MCP-compatible AI clients safe, hands-on access to local codebases: file reading/search, multi-file patches, command execution, interactive sessions, Git inspection, and coordination of local agent providers such as Antigravity and OpenCode.18Apache 2.0
- AlicenseNot gradedqualityBmaintenanceEnables direct local development operations such as shell commands, interactive terminals, file patches, images, and execution history through MCP tools, accessible via HTTP/stdio or a ChatGPT tunnel.8Apache 2.0