<div align="center">

⚡ prod-code

Remote code intelligence for fleets of coding agents

<p align="center"> <b>The analyzer, the builds and the tests run on a LAN node. The laptop edits.</b><br> Your checkout is mirrored to a gateway that keeps a warm analyzer for it (rust-analyzer in process; gopls, clangd, TypeScript, pyright, sourcekit-lsp as children) and runs commands there. Agents reach it as MCP tools, editors as a drop-in language server. </p> </div>

---

Why

A language server was designed for one human typing in one checkout. What runs on a machine now is a fleet: a resident agent in the main checkout, workers in their own worktrees, each asking the analyzer the kind of question a human asks once a minute and asking it ten times a second. Every worktree brings its own analyzer and its own cargo test, and they share the cores with your editor.

prod-code moves all of it one hop away. Measured on this repository, with nothing compiled on the laptop:

| | | |---|---| | hover on a warm workspace | 1–4 ms | | tool call over a persistent session | ~10 ms | | a one-shot CLI command from the laptop, end to end (prod-code hover …) | ~0.1 s | | cargo clippy --workspace --all-targets on a 32-core node, one file changed | 1 s | | cargo test --workspace — 565 tests | 5 min | | the same without the suite that starts real gateways | 56 s | | first load of a Rust workspace (build scripts, proc macros) | ~45 s, once per worktree |

These are recorded workloads; current test counts and timings are listed in each pull request. The live suite starts real gateways and drives their language servers. Unit and scripted-server tests complement those scenarios. The required coverage floor is 80% of regions per source file (python3 scripts/coverage.py --min 80); missing measurements fail the gate.

Requirements

Building prod-code and running its development checks require Rust 1.95.0 or newer. With rustup, install the supported minimum and the check components with:

rustup toolchain install 1.95.0 --profile minimal -c rustfmt -c clippy

Run commands with cargo +1.95.0 to use that toolchain without changing your default.

Install

# the client (one binary; the gateway is the same binary's sibling)
cargo install --path crates/prod-code-client        # or take a release binary

# register it once; every repository then has the tools
claude mcp add --scope user prod-code -e PROD_CODE_REMOTE=192.0.2.10:9400 -- prod-code mcp
codex  mcp add prod-code --env PROD_CODE_REMOTE=192.0.2.10:9400 -- prod-code mcp

For Antigravity/Gemini, add the same command to ~/.gemini/config/mcp_config.json. On a node:

prod-code-server --bind 0.0.0.0:9400 --storage /srv/prod-code/workspaces \
  --advertise <this host>:9400 --peers <other nodes>

The MCP server tells the agent how to work at initialize, and reloads itself when the binary is replaced, so a running session picks up new tools without a restart.

In an editor

prod-code lsp is an editor's language server. The language's own server (rust-analyzer, gopls, clangd, basedpyright, the TypeScript server, sourcekit-lsp) runs on the node, started for the editor's session in the node's copy of the checkout, and the bridge carries the protocol both ways:

• The editor's settings, rust-analyzer's check on save and the server's protocol extensions work as they do with a local server.
• A save reaches the node before the server hears of it.
• Files the server points at that exist only on the node (the standard library, dependency caches, generated files) are mirrored read-only under the user's cache directory.
• --language picks the server for one language of a mixed checkout.

For Zed there is an extension in editors/zed. Or point Zed's own rust-analyzer at prod-code lsp --language rust, which keeps everything Zed wires to rust-analyzer.

What it gives an agent

Tools use the node that holds the workspace. The tables describe current source; check CHANGELOG.md for the version that contains a change.

Find code

| tool | what it does | |---|---| | code_search | find code by what it does, ranked declarations with the doc comment that matched | | code_symbols | workspace symbol index by name, fuzzy, analyzer-backed | | code_definition · code_references | where a symbol is defined; every use of it | | code_callers · code_callees · code_implementations · code_supertypes | call hierarchy both ways, as a tree to a depth; implementations of a trait or interface, and the traits a type implements or a trait requires | | code_outline | a file's declarations with their kinds and lines, or those of every source file in a directory | | code_source | read std, registry and SDK sources that live only on the node |

Understand it without reading everything

| tool | what it does | |---|---| | code_slice | bounded traversal of declarations referenced by a symbol; depth and byte budgets limit the result | | code_hover · code_type_at | signature, type and docs | | code_impact | changed functions, reachable callers and candidate tests; CI falls back to the full suite when the evidence is incomplete | | code_dead_code | reference-based candidates, with failed or malformed queries marked unverified | | code_prune_orphans | eligible dead-code candidates removed with safe delete and analyzer validation; unverified and protected symbols remain |

Change it safely

Most custom planners below target Rust. The two parameter tools also support Go, C/C++, TypeScript/JavaScript, Python and Swift for their documented input shapes. Rename and server code actions depend on the selected language server. See ROADMAP-AUDIT.md for missing capabilities and ROADMAP.md for individual restrictions.

Analyzer diagnostics do not include every compiler or borrow-checker check. Tools with verify: "compile" can additionally run a shadow compiler check; semantic refusals still apply. A Rust file reported as unlinked-file is unchecked and cannot pass edit validation. New modules must be checked with their module declarations; new Cargo targets need a workspace reload or an explicit compiler check that includes them. Missing or malformed diagnostic reports also fail validation. Manifest, lockfile and documentation proposals need shadow-run with the appropriate parser or build command instead of source diagnostics.

| tool | what it does | |---|---| | code_validate_edit · code_validate_edits | analyzer diagnostics for proposed file contents, nothing written; several files judged together, with a warning when an edit removes a symbol another file still uses | | code_diagnostics | diagnostics for a file, in memory, without a build | | code_rename · code_safe_delete | semantic rename across the workspace (a field with its accessors, with accessors); delete only when nothing references it, or a parameter with its arguments | | code_change_signature | Rust signature changes; Go reorder/removal through gopls and typed literal additions to ordinary functions. Additions preserve old argument order and require remote compiler verification | | code_move | a declaration moved to another module, with the imports it takes and the imports it leaves behind | | code_move_method · code_move_module | a method moved to the type of one of its parameters, or an associated function to another type; a whole module moved to another parent, with every path that names it | | code_extract_function | a selection turned into a named function, and its duplicates and near-duplicates in this file and others replaced by calls | | code_introduce_parameter_object | parameters bundled into the language's supported object form, updating supported body uses and calls; JavaScript uses plain objects | | code_extract_parameter | an expression promoted to a parameter and supported callers updated, with structural and semantic refusal cases | | code_migrate_type | a declared type changed, with every site that no longer fits listed before any of it is done; with convert, .into() written wherever the analyzer accepts it | | code_generify | a parameter's concrete type turned into a bounded type parameter, every file that calls it type-checked against the new signature | | code_invert_boolean | a predicate, a bool field or a bool variable renamed to its opposite, every read and write unchanged in effect | | code_make_static | a method that never uses self turned into an associated function, every call site with it | | code_inline_parameter | a parameter every caller passes the same constant for, moved into the body and out of every call | | code_extract_delegate | fields and the methods that use only them moved into a helper type the struct holds, with every access and literal rewritten | | code_extract_trait | selected Rust inherent methods moved into a trait with caller imports; preserves ordinary lifetime/type/const generics and bounds, refuses conditional or opaque-return shapes and Self-dependent impl bounds | | code_loop_to_iterator | a loop that only sums, counts or pushes into an accumulator turned into an iterator chain, checked by the analyzer | | code_introduce_variable | an expression bound once (let w1 = w + 1;) and every occurrence of it in the function replaced, refused when evaluating once would change what the code does | | code_convert_to_method | an associated function turned into a method: its first parameter becomes self, Type::f(&x, a) becomes x.f(a) | | code_wrap_return | a return type wrapped in Option or Result, ? at every caller that can propagate, the rest named | | code_extract_field | an expression in a method turned into a field of its type, initialised wherever the type is built | | code_encapsulate_field | a public field made private, every read and write outside its file turned into a getter or setter call | | code_schema_rename | one schema field renamed across every language that spells it differently, semantically per project | | code_assists · code_assist | the analyzer's code actions and compiler fix-its, applied to the checkout | | code_codemod | structural search and replace on the syntax tree (pattern ==>> replacement), as a diff or applied | | code_generate_fixture | a Rust value with explicit default fallbacks, or builder: true for a typed builder preview of a named struct with ordinary lifetime/type/const parameters, defaults and bounds; verified by default, with no files written | | code_shadow_run | run a command once per candidate fix, each in a private shadow of the workspace, and take the winner's diff |

Run it

| tool | what it does | |---|---| | code_check · code_lint · code_test · code_benchmarks | build, lint and test on the node with parsed diagnostics; path narrows to one crate, package or directory; fix: true applies the compiler's machine-applicable fixes and checks again (Rust) | | code_exec | any command in the workspace copy; formatters, generators and lockfiles are written back | | code_diagnose_failure | run tests and report up to ten failure dossiers with sites, callers, changes and supported printed assertion operands |

Operate it

| tool | what it does | |---|---| | code_status · code_sync | gateway health, engines, loaded workspaces and the builds and tests running on it; a manual push (the watcher does this