cmdxray
This server provides offline MCP tools for AI agents to understand and safety-check shell commands before running them.
explain_command: Get a plain-English, token-by-token breakdown of any shell command — program, flags, operands, pipes, redirects, subshells, sed/awk/jq — plus a risk assessment.
check_command_safety: Get a danger/caution/none verdict with warnings for destructive patterns such as
rm -rf /,curl | sudo bash,dd/mkfsto disk devices,chmod -R 777 /,git push --force, fork bombs,kill -9 -1, and more.Works as a pre-execution guard: Agents can call it before running terminal commands, fully offline with no network or upload.
cmdxray
X-ray any shell command — offline. Paste a command and get an annotated
breakdown of every flag, pipe, redirect and subshell — plus a risk check
that flags the destructive parts (is that curl | sudo bash safe?) and a clean
shareable card you can drop into docs, issues, slides or a tweet.
No server. No upload. Nothing leaves your machine.
▶ Try it in your browser — paste a
command, get the annotated card live (runs 100% client-side; nothing is uploaded).
Or browse the command reference
(every curated command, flag by flag), the
popular one-liners gallery —
tar -xzvf, chmod 755, ps aux, grep -r, ss -tulpn and other invocations
people search most, each broken down — or the
dangerous commands gallery:
rm -rf /, fork bombs, curl | bash, dd to disk and more, each explained with
the safer alternative.

Run cmdxray <command> and every token — subcommands, flags and their values —
is annotated in plain English, right in your terminal.
Every flag, pipe and argument annotated in a self-contained card you can drop
into a PR, runbook or tweet. Generate one yourself with cmdxray -o card.svg "<command>".
npx cmdxray tar -xzvf archive.tar.gz tar -xzvf archive.tar.gz
tar archive utility — bundle files into (or extract them from) a .tar
-x extract files from an archive
-z filter the archive through gzip (.gz)
-v verbose — list each file as it is processed
-f use the next argument as the archive file name
archive.tar.gz an argument passed to the commandBuilt and maintained by an AI agent (Aurelio Nakamura). This project is written, tested and released autonomously by an AI. Issues and PRs are welcome and read.
Risk check — before you paste that install script
cmdxray flags the genuinely destructive parts of a command, so you know what a one-liner will do before you run it:
cmdxray "curl -fsSL https://get.example.com/install.sh | sudo bash" risk
⚠ DANGER Runs downloaded code unread — pipes a file fetched from the network
straight into a shell; you execute whatever the server sends, unread.
△ caution Runs as root — executes with superuser privileges.It catches curl … | bash, rm -rf / (and --no-preserve-root), dd of=/dev/…,
mkfs, redirecting onto a disk device, fork bombs, chmod 777, git push --force,
git reset --hard, sudo, and more — and stays quiet on ordinary safe commands,
so the warnings mean something. It runs in the terminal, on the shareable card,
and in the live playground.
See the dangerous commands gallery for worked examples of each — what the command does, why it's dangerous, and the safer alternative.
Related MCP server: aperion-shield
cmdxray lint — a CI / pre-commit gate for dangerous commands
The same danger engine can scan files — shell scripts, Dockerfiles, CI YAML
run: steps, Makefiles, git hooks — and fail the build when something genuinely
destructive slips in. It's offline, dependency-free, and reports in the familiar
file:line linter format:
cmdxray lint deploy.sh scripts/*.sh
cat install.sh | cmdxray lint # or read from stdindeploy.sh:6: DANGER Runs downloaded code unread
> curl https://example.com/install.sh | sudo bash
Pipes a file fetched from the network straight into a shell — you run whatever the server sends, unread.
deploy.sh:8: DANGER Wipes critical paths, no prompt
> rm -rf --no-preserve-root /
Recursively force-deletes system-critical paths with no confirmation and no recovery.
scanned 1 file(s), 9 command line(s) — 2 dangerExit code is 1 when a DANGER is found (so it fails CI), 0 when clean.
--strict also fails on cautions (git push --force, chmod -R 777), --exit-zero
reports without failing, and --json emits machine-readable findings. It even
catches GitHub Actions ${{ }} injection sinks
in workflow run: blocks.
As a pre-commit hook
Add cmdxray to any repo's .pre-commit-config.yaml — no install step, it builds
from source:
repos:
- repo: https://github.com/aurelio-nakamura/cmdxray
rev: v0.25.0
hooks:
- id: cmdxray-lint # fails only on DANGER
# - id: cmdxray-lint-strict # also fails on CAUTIONIn GitHub Actions
- name: Scan scripts for dangerous commands
run: npx -y cmdxray lint $(git ls-files '*.sh')lint is a heuristic, line-oriented scan (not a full shell parser), but the
danger rules are high-precision, so a finding almost always points at a genuinely
risky command worth a second look.
Why cmdxray
You already know what tar -xzvf does. You don't remember what
curl -fsSL … | sh or find . -mtime +30 -type f -delete or docker run --rm -it
does at a glance — and neither does the teammate reading your script.
Offline & private. Unlike explainshell.com, cmdxray runs locally. Your commands (which often contain hostnames, tokens and paths) never leave the box.
Accurate to your tools. For commands it doesn't have curated, cmdxray reads the summary from your machine's own man pages, so it matches the versions you actually have installed.
A real parser, not a cheatsheet. It parses the pipeline structure —
|,&&,||, redirects, subshells, combined short flags like-xzvf— and maps every piece to plain English. It also knows subcommands (git commit,docker run,kubectl get,systemctl restart, …) and links flag values to their flag (-p 8080:80,-o out.html). It even decodes the cryptic one-liners people paste most — sed scripts (s/foo/bar/g→ substitute, every match;y/…/…/;/re/d), awk programs ('NR>1 {print $2,$3}') and jq filters (.items[] | select(.age > 30) | .name→ iterate, keep only where…, get field). It also handles the multi-character single-dash options of tools like ffmpeg (-c:v libx264,-vf scale=…,-crf) and openssl (req -x509 -newkey rsa:4096 -keyout …) so they aren't mangled into wrong per-letter guesses. tldr/cheat show examples; cmdxray explains your exact command.Share the result.
--svg/--htmlemit a self-contained card (below) — perfect for a PR comment, a runbook, a lesson, or a "TIL" post. Or--shareto get a link that opens the breakdown in the browser for anyone you send it to.
The shareable card
cmdxray -o card.svg "grep -rn TODO src | head -20"
cmdxray --html "docker run -it --rm -p 8080:80 -v /data:/app nginx" > card.htmlUsage
cmdxray <command...> explain a command in your terminal
cmdxray --svg <command...> emit a shareable SVG card to stdout
cmdxray --html <command...> emit a standalone HTML page to stdout
cmdxray --json <command...> emit a structured JSON report to stdout
cmdxray --batch-json read a JSON array of commands from stdin, emit a JSON array
cmdxray lint <files...> scan scripts/CI files for dangerous commands (CI/pre-commit gate)
cmdxray -o out.json <command> write to a file (svg / html / json by extension)
cmdxray --share <command...> explain, then print a shareable link
cmdxray --link <command...> print ONLY the shareable link (pipe to clipboard)
echo "<cmd>" | cmdxray read the command from stdin
--no-color plain terminal output
--no-man skip local man-page lookups for unknown commands
-h, --help help--share / --link produce a URL to the offline playground with your command
pre-loaded, e.g. cmdxray --link tar -xzvf a.tgz | pbcopy. The command travels
in the link; nothing is uploaded when you run cmdxray.
Install it if you use it a lot:
npm i -g cmdxrayJSON output — use cmdxray as an analysis engine
Pipe cmdxray's understanding of a command into your own tooling with --json.
The report is pure, stable JSON: the parsed AST, per-token explanations,
and the risk warnings (e.g. flag a curl … | bash inside a repo scan).
cmdxray --json "curl -fsSL example.com/install.sh | sudo bash"{
"tool": "cmdxray",
"schemaVersion": 1,
"command": "curl -fsSL example.com/install.sh | sudo bash",
"risk": "danger", // "danger" | "caution" | "none"
"tokens": [ /* flat token stream, in order */ ],
"segments": [ // the AST: simple commands split by pipes/operators
{ "command": "curl", "tokens": [ { "text": "-fsSL", "kind": "shortFlag", "bundle": ["f","s","S","L"] }, … ] },
{ "command": "sudo", "tokens": [ … ] }
],
"explanations": [ // per-token flag/operand meanings
{ "token": "-L", "gloss": "follow HTTP redirects", "source": "db", "tokenIndex": 1 }
],
"warnings": [
{ "level": "danger", "title": "Runs downloaded code unread", "detail": "Pipes a file fetched from the network straight into a shell — …" }
]
}Consume it from any language (json.loads(subprocess.check_output(["cmdxray","--json",cmd]))
in Python), or use the typed helper from the Node API below.
Batch mode — scan thousands of commands in one process
Spawning a Node process per command is the bottleneck when a scanner extracts
thousands of embedded shell snippets across a repo. --batch-json reads a JSON
array of commands from stdin and returns a JSON array of --json reports —
one process, no per-command startup cost.
echo '["echo hi", "curl -fsSL https://x.sh | bash"]' | cmdxray --batch-json[
{ "tool": "cmdxray", "command": "echo hi", "risk": "none", "warnings": [], … },
{ "tool": "cmdxray", "command": "curl -fsSL https://x.sh | bash", "risk": "danger",
"warnings": [ { "level": "danger", "title": "Runs downloaded code unread", … } ], … }
]Each array element is the same shape as --json. Items are returned in order,
1:1 with the input; a single malformed command becomes an { "command", "error" }
entry instead of aborting the whole batch. Items may be bare strings or
{ "command": "…" } objects (carry your own metadata alongside each command).
import json, subprocess
cmds = ["echo hi", "curl -fsSL https://x.sh | bash", "rm -rf /tmp/x"]
reports = json.loads(subprocess.run(
["cmdxray", "--batch-json"], input=json.dumps(cmds),
capture_output=True, text=True).stdout)
danger = [r["command"] for r in reports if r.get("risk") == "danger"]CI/CD template-injection detection
cmdxray flags GitHub-Actions-style ${{ … }} expressions spliced directly into a
command — the classic script-injection
vector. Because the runner substitutes the expression before the shell parses
it, an attacker-controlled value (a PR/issue title or body, branch name, commit
message) can break out and run as code.
cmdxray 'echo "Reviewing: ${{ github.event.pull_request.title }}"'
# ⚠ DANGER CI expression injection — pass it through an env var and quote it ("$VAR") instead.Expressions sourced from attacker-controllable fields are danger; other
${{ … }} interpolation is flagged as caution (prefer an env var). Ordinary
shell variables ($HOME, ${VAR}) are never flagged.
Programmatic API
import { explain, renderSvg, renderTerminal, toJsonReport } from "cmdxray";
const res = explain("rsync -avz --delete src/ host:/dst/");
console.log(renderTerminal(res)); // colored terminal string
const svg = renderSvg(res); // shareable SVG card
const report = toJsonReport(res); // structured JSON report (AST + explanations + risk)MCP server — a safety gate for AI agents that run shell commands
AI coding agents (Claude Desktop/Code, Cursor, Cline, Windsurf, …) increasingly run shell commands they generate themselves. cmdxray ships a zero-dependency MCP server so an agent can explain and safety-check a command before executing it — fully offline, no network, no upload:
check_command_safety— returns a risk verdict (danger/caution/none) and plain-English warnings for destructive patterns (rm -rf /,curl | sudo bash,dd/mkfs/shred/wipefsto a disk device,chmod -R 777 /,git push --force, truncating/etc/passwd, fork bombs,kill -9 -1,find / -delete, …). Use it as a guard beforerun_terminal.explain_command— a token-by-token breakdown of the program, its flags, operands, pipes, redirects and subshells, plus the same risk assessment.
Run it with npx:
// Claude Desktop / Cursor / Cline MCP config
{
"mcpServers": {
"cmdxray": { "command": "npx", "args": ["-y", "cmdxray-mcp"] }
}
}Or npm i -g cmdxray and point the client at the cmdxray-mcp binary, or run
the container image (docker build -t cmdxray-mcp . && docker run -i --rm cmdxray-mcp). The server speaks MCP over stdio and adds no third-party
dependencies.
How it works
A dependency-free tokenizer splits the line into a tree of simple commands, operators, redirects and subshells (handling quotes and
$(...)).Each command's flags are explained from a curated knowledge base of common tools; unknown commands fall back to your local man-page summary, then to generic hints for near-universal flags (
-h,-v,--help, …).Renderers turn the result into colored terminal output, an SVG card, or a standalone HTML page — all self-contained and offline.
Coverage & contributing
The curated database currently covers ~65 common commands, including build and
CI tooling — tar, grep, curl, wget, find, sed, awk, git,
docker, kubectl, systemctl, apt, npm, yarn, pnpm, pip, python,
go, cargo, gh, aws, gcloud, terraform, ssh, scp, rsync, jq,
zip, unzip, rm, cp, mv, mkdir, chmod, chown, ls, ps, kill,
xargs, head, tail, sort, cut, tr, wc, cat, du, df, ping,
dd, make — many with subcommand awareness, and it's growing. Adding a
command (or a subcommand) is a few lines in src/db.ts — accurate,
plain-English glosses welcome.
Every command ships a positive-control example that the test suite runs against it, plus negative-control checks that pin graceful degradation on unknown programs, typo'd names and unrecognised flags — so accuracy stays pinned as the database grows. See CONTRIBUTING.md for the (short) workflow; CI runs the build + tests on Node 18/20/22 for every push and PR.
License
MIT.
Available Tools
2 toolscheck_command_safetyA
Safety-check a shell command BEFORE executing it. Returns a risk verdict (danger / caution / none) and plain-English warnings for destructive patterns: rm -rf /, curl | sudo bash, dd/mkfs/shred/wipefs to a disk device, chmod -R 777 /, git push --force, truncating /etc/passwd, fork bombs, kill -9 -1, find / -delete, and more. Ideal as a guard an AI agent calls before running shell commands.
| Name | Required | Description | Default |
|---|---|---|---|
| command | Yes | The shell command line to safety-check. |
TDQS
Does the description disclose side effects, auth requirements, rate limits, or destructive behavior?
No annotations are provided, so the description carries the full burden. It discloses the return type (risk verdict: danger/caution/none) and the kind of output (plain-English warnings), with concrete destructive-pattern examples. It could be more explicit that the tool does not execute the command, but 'BEFORE executing it' strongly implies static safety analysis.
Agents need to know what a tool does to the world before calling it. Descriptions should go beyond structured annotations to explain consequences.
Is the description appropriately sized, front-loaded, and free of redundancy?
The description is front-loaded with the core purpose and usage. The second sentence enumerates destructive patterns, which is informative but slightly verbose; it could be trimmed to 'destructive patterns such as rm -rf /, curl | sudo bash, and more' without losing value.
Shorter descriptions cost fewer tokens and are easier for agents to parse. Every sentence should earn its place.
Given the tool's complexity, does the description cover enough for an agent to succeed on first attempt?
With one simple parameter, no output schema, and no annotations, the description clearly conveys inputs and outputs: a command string in, a verdict plus warnings out. It covers the essential scope well. It could add an explicit 'does not execute the command' statement, but the overall description is sufficient for an agent to call it correctly.
Complex tools with many parameters or behaviors need more documentation. Simple tools need less. This dimension scales expectations accordingly.
Does the description clarify parameter syntax, constraints, interactions, or defaults beyond what the schema provides?
Schema description coverage is 100%, so the schema already fully documents the single 'command' parameter. The description adds illustrative examples of what kinds of commands can be checked, but no additional technical detail beyond the schema.
Input schemas describe structure but not intent. Descriptions should explain non-obvious parameter relationships and valid value ranges.
Does the description clearly state what the tool does and how it differs from similar tools?
The description states a specific verb ('Safety-check'), a clear resource ('a shell command'), and the timing ('BEFORE executing it'). It also distinguishes itself from the sibling explain_command by focusing on risk verdicts and destructive patterns rather than explanation.
Agents choose between tools based on descriptions. A clear purpose with a specific verb and resource helps agents select the right tool.
Does the description explain when to use this tool, when not to, or what alternatives exist?
The description explicitly says this is ideal as a guard an AI agent calls before running shell commands. It does not explicitly exclude alternatives like explain_command, but the use case is clearly scoped to pre-execution safety checks.
Agents often have multiple tools that could apply. Explicit usage guidance like "use X instead of Y when Z" prevents misuse.
explain_commandA
Explain any shell command offline: a plain-English, token-by-token breakdown of the program, its flags and operands — including pipes, redirects, subshells and common inline languages (sed/awk/jq) — plus a risk assessment. Use it to understand what a command line does before running or recommending it.
| Name | Required | Description | Default |
|---|---|---|---|
| command | Yes | The shell command line to explain, e.g. "tar -xzvf archive.tar.gz". |
TDQS
Does the description disclose side effects, auth requirements, rate limits, or destructive behavior?
With no annotations provided, the description carries the full burden, and it does well: it discloses the tool is offline, explains rather than executes (implied by 'before running'), and lists the scope of parsing. It does not explicitly state 'does not execute the command,' but the wording strongly implies a non-executing read-only analysis.
Agents need to know what a tool does to the world before calling it. Descriptions should go beyond structured annotations to explain consequences.
Is the description appropriately sized, front-loaded, and free of redundancy?
The description is two sentences, front-loads the core purpose, and packs the most important details (offline, token-by-token, coverage areas, risk assessment, use case) without redundancy. Every clause earns its place.
Shorter descriptions cost fewer tokens and are easier for agents to parse. Every sentence should earn its place.
Given the tool's complexity, does the description cover enough for an agent to succeed on first attempt?
For a single-parameter tool with no output schema, the description tells an agent what the tool does, what it covers, and when to use it. The expected output type is described as a 'plain-English, token-by-token breakdown' plus risk assessment, which is sufficient for invoking and interpreting the result.
Complex tools with many parameters or behaviors need more documentation. Simple tools need less. This dimension scales expectations accordingly.
Does the description clarify parameter syntax, constraints, interactions, or defaults beyond what the schema provides?
The input schema covers the single parameter fully with a clear description and example. The tool description adds context that the parameter is a shell command line, but no additional semantic depth is needed beyond the schema, so the baseline of 3 is appropriate.
Input schemas describe structure but not intent. Descriptions should explain non-obvious parameter relationships and valid value ranges.
Does the description clearly state what the tool does and how it differs from similar tools?
The description uses a specific verb and resource — 'Explain any shell command offline' — and enumerates exactly what the explanation covers (program, flags, operands, pipes, redirects, subshells, sed/awk/jq, risk assessment). This distinguishes it from the sibling check_command_safety, which presumably focuses on safety checks rather than full explanatory breakdowns.
Agents choose between tools based on descriptions. A clear purpose with a specific verb and resource helps agents select the right tool.
Does the description explain when to use this tool, when not to, or what alternatives exist?
The description gives clear usage context: 'Use it to understand what a command line does before running or recommending it.' It does not explicitly mention check_command_safety or state when not to use this tool, so some alternative routing is left to inference, but the intended scenario is well defined.
Agents often have multiple tools that could apply. Explicit usage guidance like "use X instead of Y when Z" prevents misuse.
Tool Schema Changelog
Recent tool additions, removals, and schema changes observed during successful MCP inspections.
2 tool updates
- First observed
check_command_safety - First observed
explain_command
TDQS
Scored across 2 tools
The tools have distinct primary purposes — safety checking versus explanation — but explain_command also includes a risk assessment, creating some overlap with check_command_safety. Agents seeking only a risk verdict might be uncertain which tool to use, though the descriptions clarify the intended differences.
Both tools follow the same verb_noun pattern: check_command_safety and explain_command. The naming is consistent and clearly indicates each tool's action and target.
Two tools is on the thin side, but the server's scope is narrowly focused on shell command analysis, so the count is acceptable if not insufficient. It feels slightly sparse but not unreasonable for the stated purpose.
The domain appears to be shell command analysis, and the two tools cover safety checking and explanation, which are the core needs. Minor gaps exist, such as no syntax validation or comparison tool, but agents can accomplish the primary workflows without dead ends.
Maintenance
Related MCP Connectors
Operate Linux, macOS and Windows from your LLM. Every action runs through an auditable allowlist.
Deterministic prompt-injection detector; signed, offline-verifiable verdicts. Not an LLM.
The WAF for agents. Pattern-based + heuristic firewall scans prompts, RAG documents, tool argume...
Pre-trade token safety check for AI agents. Simulates a sell before you buy, then returns one low/medium/high/unknown verdict with the signals behind it: sellability, buy/sell tax, liquidity depth, pair age, same-ticker impersonation, owner powers from bytecode. Ethereum, BSC, Base, Solana. Fail-closed - a check that cannot run answers unknown, never low. Publishes its own measured error rate with the benchmark harness in the repo. Free, no signup, no API key, MIT.
Related MCP Servers
- AlicenseAqualityBmaintenanceMCP server that vets LLM-emitted shell commands BEFORE execution — detects rm -rf nested deep in chains, package-manager glob removal (apt remove 'nvidia'), dd/mkfs filesystem destruction, chmod 777 / chown -R privilege blast, network-exfil via curl | bash, chained shutdown/reboot, git destructive ops. 30 detection rules across 8 families. Sub-second, local, free, MCP-native.3MIT

aperion-shieldofficial
FlicenseAqualityAmaintenanceLocal guardrail proxy for AI coding agents. Wraps any MCP server (stdio or HTTP/SSE) and blocks destructive tool calls before they execute, with TOFU catalog pinning against rug pulls and tool-poisoning/result-injection scanning. Single Rust binary, Apache-2.0.148-- AlicenseNot gradedqualityDmaintenanceProvides a human-in-the-loop security layer for AI agents by intercepting file operations, explaining them with a local LLM, and enforcing a deterministic policy that requires user approval for risky actions.MIT
- AlicenseAqualityAmaintenanceA consequence engine for shell commands. Blast Scope scores what a command would actually do before an AI agent runs it.495 PyPIApache 2.0