The full upstream README, mirrored here for reference. Install config, tool schemas, adoption signals, and an original overview live on the My Pi listing page.
Local-first MCP runtime for coding agents — safer workspace access without an unrestricted shell
Bounded filesystem · content-preconditioned writes · Tree-Sitter AST search · LSP navigation · Git tooling
my-pi is a deterministic local coding capability runtime exposed through the official Model Context Protocol (MCP). It gives MCP-capable coding agents controlled access to a real workspace through explicit workspace authority, bounded reads, guarded writes, structural search, language-server intelligence, and Git operations.
It is aimed at developers who want agentic coding tools to understand and modify code without handing the agent a general-purpose shell or silently granting the current working directory.
trusted elevation.Release channel: Alpha. The npm badge above is authoritative for the currently published package version. This repository may contain a newer release candidate before publication completes. Suitable for evaluation and controlled local development; review the security model before enabling the trusted profile.
Requires Node.js >=24.0.0 (Node 24 LTS is the normative runtime).
The server starts read-only. For a workspace you explicitly trust:
Or inspect a host configuration without a global install:
Generate host-specific configuration snippets:
Starting without --workspace or MY_PI_WORKSPACE_ROOT fails closed. Use --allow-cwd only when granting the current directory is intentional.
The published npm package is the stable MCP server. The coordination daemon and local UI are private workspace packages used by the experimental source build; build the repository before using those components.
| Area | Tools | Purpose |
|---|---|---|
| Filesystem | fs_read, fs_write, fs_patch, fs_stat | Bounded reads, guarded writes/patches, metadata |
| Search & workspace | search, workspace_info | Repository exploration and authoritative workspace state |
| AST & LSP | ast_search, lsp_status, lsp_symbols, lsp_navigate, lsp_diagnostics | Structural and semantic code intelligence |
| Git | vcs_status, vcs_diff | Repository status and bounded/filtered diffs |
| Capability | Behavior |
|---|---|
| Content-preconditioned mutation | File updates verify raw SHA-256 fingerprints and reject stale guarded overwrites |
| Pre-read sensitive-path policy | Sensitive paths such as .env*, .aws/, .ssh/, and *.key are denied before content is allocated to model context |
| Explicit security profiles | Default is read-only; mutation and LSP process startup require explicit elevation |
| Encoding/mode fidelity | File replacement preserves relevant encoding, line endings, BOM, and POSIX executable mode behavior |
| Cancellation | Long-running Git/search/LSP subprocess work supports cancellation and cleanup |
The stable public claim is the 13-tool MCP capability surface. The repository also contains two opt-in candidates that never change the default mode:
Prerequisites for repository development:
v24.0.0+ (Node 24 LTS normative; exact-minimum 24.0.0 lane is qualified in CI)v11.2.2+The configured CI matrix covers Ubuntu, Windows, and macOS lanes. See the live workflow badges above for current status rather than relying on static claims in this document.
| Contract | Document | Enforced by |
|---|---|---|
| Runtime compatibility (engines/types/CI parity) | docs/RUNTIME_CONTRACT.md | node scripts/check-runtime-contract.mjs |
| Test/invariant coverage | docs/TEST_CONTRACT.md | pnpm check:contract (scripts/verify-test-contract.mjs) |
| Merge/release governance | docs/GITHUB_GOVERNANCE.md | ci-required + CodeQL required checks |
| Worktree identity isolation | packages/code-state/IDENTITY.md | ownership guard + invariant suites |
The repository contains deterministic synthetic benchmarks for MCP stdio overhead, search/traversal throughput, memory sampling, runtime boundaries, coordination behavior, impact routing, evaluation feedback, and local reliability. Benchmark outputs are candidate evidence; performance claims should be interpreted alongside their qualification criteria and runner variance.
The self-hosted program keeps implementation, measurement, and promotion as separate decisions:
The current evidence files under evidence/ are candidate-bound records, not a
release or promotion claim. A passing test, a qualified sample, or an accepted
individual evidence record does not by itself open PN11. Use the read-only
promotion verifier as the authority:
Keep PN11 withheld unless the final command reports
promotionEligible: true. Do not reclassify legacy or missing-result records by
editing their metadata after a run.
Start the local coordination candidate for a logical project:
Add --evaluation only when the evaluation plane is required. The candidate keeps source and detailed code state local, does not select models or spawn agents, and does not require a hosted control plane.
Relevant qualification commands include:
pnpm verify:production-next-promotion is the read-only promotion verifier; it is the authoritative gate and is never weakened to match available results.
An opt-in, read-only visualization surface renders authoritative local state as a bounded graph. It is a projection of the coordination graph snapshot and event log — not an LLM-generated diagram — and it never mutates source state.
degraded, truncated, stale, and empty are always surfaced; unknown event types never drive motion; sensitive paths embedded in free-text values are redacted on every wire exit.ui://my-pi/theater resource behind --visuals. The default MCP catalog remains exactly 13 tools.managed, unmanaged, stale_lineage, unknown, or exempt against verified my-pi change receipts — an external edit never becomes managed by observing final bytes.allowed / rejected / review_required findings.strict-capable / managed / monitoring); a profile is never labeled strict-certified without seeded bypass evidence.Search-ignore behavior is documented in docs/SEARCH_IGNORE.md. It is a traversal optimization, not a substitute for sensitive-path policy.
Before using trusted mode, read docs/SECURITY_MODEL.md. Security findings are welcome through the repository's documented reporting process.
Issues, reproducible bug reports, benchmark counterexamples, integration feedback, and focused pull requests are welcome. If you are evaluating my-pi in a real coding host, include the host, OS, Node version, security profile, and a minimal reproduction where possible.
MIT — see LICENSE.