Most projects in this shape claim guardrails they do not have; this one lists its own gaps line by line and publishes the patch plan needed before it should be presented as security-oriented — argv-based execution, a default strict mode with allowlists, an enforced workspace root, output limits, redaction and audit logs. Read that way it is a clear, honest reference for what a shell-execution server has to solve, and a scratch-machine tool until those land.
An experimental MCP server that exposes local shell execution to an assistant. It registers a single tool that runs a caller-supplied command string through the shell, with a fixed five-minute timeout, and returns what came back. The repository describes itself as a prototype rather than a secure shell server.
- A shell command executed on the host, returning exit code, stdout and stderr — `execute_command`
- An optional working directory for the call, defaulting to the home directory
- A fixed five-minute timeout, so a hung command does not hang the session forever
No account and no key — the risk is not credentials, it is reach. The current code runs the command string with the shell interpreter, with no allowlist or denylist, no working-directory boundary, no environment filtering, no output sanitisation and no audit log; earlier versions of the README described those controls, and they are not in the source. Run it only against a host, account and directory holding nothing sensitive — no production data, no private source, no SSH keys, no cloud tokens. Development install is `pip install -e ".[dev]"` then `pytest`. The pyproject name is `Lilith-Shell` (0.1.0), MIT licensed.