prod-code 0.3.49: several code reads in one MCP call, and edits that check what they replace

An experimental code_workflow tool composes existing prod-code reads, previews and applies text edits only over the bytes it saw, and runs only checks it is asked for. It also fixes stalled refreshes in non-Git sessions. It makes no speed or context claim.

An agent that wants to understand one function in prod-code usually makes a short chain of calls: find the symbol, read its definition, read what it depends on. Each call is a model round trip, and the agent has to carry the location from one answer into the next request. Version 0.3.49 adds an experimental MCP tool, code_workflow, that accepts that chain as one request. It runs the same operations through the same gateway and language engines as the individual tools, which all remain available. It adds no shell, no JavaScript runtime and no new network protocol.

This post covers what the tool does at tag v0.3.49 (commit 61aae41), archived on Zenodo as 10.5281/zenodo.23905176. The newer work on prod-code’s main branch is not part of it. There is no prod-code workflow command in this version; the tool exists only over MCP.

v0.3.49 #

Reads, composed

For the common cases there are two short forms. One inspects a symbol:

{"symbol":"Cache::get","include":["dependencies","callers"]}

The other searches for literal text and expands each hit into the definition that encloses it. The expansion reuses prod-code’s existing grep enrichment, which is a heuristic rather than a parser: ambiguous hints fail visibly, and hits outside any symbol are returned as unexpanded instead of being counted as definitions.

Anything longer is an explicit plan of named steps. A later step refers to an earlier result with a step ID and a JSON pointer, "target#/path"; forward and self references are rejected before anything runs. A step can iterate over an array, up to eight items; more than eight is an error, not a silent subset. A failing step can be marked to continue, and a recovery step can run only when it failed. Nothing is retried automatically.

The bounds are fixed: one workspace, or one verified sibling Git worktree, per plan, up to 16 steps and 32 operation calls, 64 KiB of input, 1 MiB of retained intermediate values, and a wait of 30 seconds by default and 60 at most. Only the steps named in outputs are returned, but every step’s status and warnings stay in the report, so a hidden step that hit a truncation limit still says so.

Edits that check what they replace

A plan can also change files, in two stages. A preview step takes an old and a new snippet, requires the old one to match exactly once, and returns a diff together with each file’s SHA-256. It writes nothing and runs nothing. An apply step takes those prepared files, checks every path and every file’s bytes against the recorded hashes, and only then writes through prod-code’s existing edit journal. A file that changed since the preview is refused before any write, and the report says zero writes.

What it does not do matters as much. Writes need apply: true on the whole request, and that flag only permits apply steps; it does not schedule them. Each apply batch is independent: if a later step fails, earlier writes stay on disk. The writer gates serialize requests inside one MCP process; another process or an editor can still change a file after the check, so this is not a cross-process compare-and-swap, and there is no crash-safe multi-file transaction or rollback of a whole plan. Preview handles existing UTF-8 files only, not creates, deletes or renames.1

Checks only when asked

A verify step runs check, lint or test on an explicit path inside the workspace. A test needs a non-empty filter, and a test runner that would ignore the filter is refused. Scopes that would widen to a whole Cargo workspace or ./... are refused too; the agent has to name a member package. Nothing is built or tested because a preview or an apply succeeded. A verification waits at most 120 seconds, a write-enabled plan two minutes, and a timed-out wait is reported as a timeout, not as success or as a rollback.

The refresh fix

The other change is a fix. In an open session on a checkout that is not a Git repository, a workspace refresh sent a handshake probe where an incremental sync was expected, and the gateway waited on it. The client now sends the incremental update, the gateway disconnects a late probe instead of stalling, and file access events that change nothing no longer trigger redundant sync probes (#1796, #1798).

What was measured, and what was not

The measurements in the release are acceptance observations, recorded in docs/agent-workflow-measurements.md. On a small Rust fixture, a symbol search, definition and dependency slice took three standalone calls or one workflow call, with identical text. In a session against prod-code’s own repository, a search and a definition took two calls or one, with the same complete definition. In both cases the response was larger, not smaller:

The standalone calls ran first, against a colder analyzer, so the timings recorded alongside do not show that composition is faster, and the release makes no speed claim. Nor does it claim a smaller context: a direct code_slice already returns a symbol and its dependencies in one call, and a three-call baseline is not the strongest one. Fewer round trips are what was observed; whether agents choose better or finish sooner with this tool has not been tested.

The release checks are in PR #1804: 55 workflow unit tests and the affected live workflow case passed, and six native client and server binaries were built for Linux x86-64, Linux ARM64 and macOS ARM64, the macOS ones signed. The strict scoped lint did not pass; it reports 260 existing diagnostics outside the new modules, so this is not a release with a clean lint.

The tool is marked experimental. The next step its documentation sets is a comparison on real tasks, in both orders, including cold and unavailable analyzers, before the contract grows.

Footnotes #

The edit contract at the tag, docs/agent-workflow-edits.md , still carries the heading “development contract”. The release notes, the changelog and PR #1804 include preview, apply and verification in 0.3.49.↩

Cite this article #

Alexander Panasenko (2026-11-03). prod-code 0.3.49: several code reads in one MCP call, and edits that check what they replace. https://prod.codes/blog/prod-code-0-3-49-several-reads-one-call/