{"slug": "prod-code-0-3-49-several-code-reads-in-one-mcp-call-and-edits-that-check-what", "title": "prod-code 0.3.49: several code reads in one MCP call, and edits that check what they replace", "summary": "Prod-code 0.3.49, released at tag v0.3.49 (commit 61aae41) and archived on Zenodo as 10.5281/zenodo.23905176, adds an experimental MCP tool called code_workflow that composes multiple code reads into a single request, running the same operations through the same gateway and language engines as the existing individual tools. The tool also adds two-stage file edits: a preview step requires the old snippet to match exactly once and returns a diff with each file's SHA-256, and an apply step verifies every path and file's bytes against those recorded hashes before writing through prod-code's existing edit journal, refusing files that changed since the preview. Plans are bounded to one workspace or one verified sibling Git worktree, up to 16 steps and 32 operation calls, 64 KiB of input, 1 MiB of retained intermediate values, and a default 30-second wait capped at 60 seconds; the release also fixes stalled refreshes in non-Git sessions and makes no speed or context claim.", "body_md": "# prod-code 0.3.49: several code reads in one MCP call, and edits that check what they replace\n\nAn 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.\n\nAn agent that wants to understand one function in prod-code usually makes a short chain of\ncalls: find the symbol, read its definition, read what it depends on. Each call is a model\nround trip, and the agent has to carry the location from one answer into the next request.\nVersion 0.3.49 adds an experimental MCP tool, `code_workflow`, that accepts that chain as one\nrequest. It runs the same operations through the same gateway and language engines as the\nindividual tools, which all remain available. It adds no shell, no JavaScript runtime and no\nnew network protocol.\n\nThis post covers what the tool does at tag\n[`v0.3.49`](https://github.com/alex09x/prod-code/releases/tag/v0.3.49) (commit `61aae41`),\narchived on Zenodo as [10.5281/zenodo.23905176](https://doi.org/10.5281/zenodo.23905176). The\nnewer work on prod-code’s main branch is not part of it. There is no `prod-code workflow`\ncommand in this version; the tool exists only over MCP.\n\n## v0.3.49\n\n### Reads, composed\n\nFor the common cases there are two short forms. One inspects a symbol:\n\n```\n{\"symbol\":\"Cache::get\",\"include\":[\"dependencies\",\"callers\"]}\n```\n\nThe other searches for literal text and expands each hit into the definition that encloses\nit. The expansion reuses prod-code’s existing grep enrichment, which is a heuristic rather than\na parser: ambiguous hints fail visibly, and hits outside any symbol are returned as\n`unexpanded` instead of being counted as definitions.\n\nAnything longer is an explicit plan of named steps. A later step refers to an earlier result\nwith a step ID and a JSON pointer, `\"target#/path\"`; forward and self references are rejected\nbefore anything runs. A step can iterate over an array, up to eight items; more than eight is\nan error, not a silent subset. A failing step can be marked to continue, and a recovery step can\nrun only when it failed. Nothing is retried automatically.\n\nThe bounds are fixed: one workspace, or one verified sibling Git worktree, per plan, up to 16 steps and 32 operation calls, 64 KiB of\ninput, 1 MiB of retained intermediate values, and a wait of 30 seconds by default and 60 at\nmost. Only the steps named in `outputs` are returned, but every step’s status and warnings\nstay in the report, so a hidden step that hit a truncation limit still says so.\n\n### Edits that check what they replace\n\nA plan can also change files, in two stages. A `preview` step takes an old and a new snippet,\nrequires the old one to match exactly once, and returns a diff together with each file’s\nSHA-256. It writes nothing and runs nothing. An `apply` step takes those prepared files, checks\nevery path and every file’s bytes against the recorded hashes, and only then writes through\nprod-code’s existing edit journal. A file that changed since the preview is refused before any\nwrite, and the report says zero writes.\n\nWhat it does not do matters as much. Writes need `apply: true` on the whole request, and\nthat flag only permits apply steps; it does not schedule them. Each apply batch is independent:\nif a later step fails, earlier writes stay on disk. The writer gates serialize requests inside\none MCP process; another process or an editor can still change a file after the check, so this\nis not a cross-process compare-and-swap, and there is no crash-safe multi-file transaction or\nrollback of a whole plan. Preview handles existing UTF-8 files only, not creates, deletes or\nrenames.[1](#user-content-fn-1)\n\n### Checks only when asked\n\nA `verify` step runs `check`, `lint` or `test` on an explicit path inside the workspace. A test\nneeds a non-empty filter, and a test runner that would ignore the filter is refused. Scopes that\nwould widen to a whole Cargo workspace or `./...` are refused too; the agent has to name a member\npackage. Nothing is built or tested because a preview or an apply succeeded. A verification\nwaits at most 120 seconds, a write-enabled plan two minutes, and a timed-out wait is reported as\na timeout, not as success or as a rollback.\n\n### The refresh fix\n\nThe 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).\n\n### What was measured, and what was not\n\nThe measurements in the release are acceptance observations, recorded in\n[`docs/agent-workflow-measurements.md`](https://github.com/alex09x/prod-code/blob/v0.3.49/docs/agent-workflow-measurements.md).\nOn a small Rust fixture, a symbol search, definition and dependency slice took three standalone\ncalls or one workflow call, with identical text. In a session against prod-code’s own\nrepository, a search and a definition took two calls or one, with the same complete definition.\nIn both cases the response was larger, not smaller:\n\n| Scenario | Standalone | Workflow | \n|---|---|---|\n| Rust fixture, full MCP results | 1,142 bytes | 1,261 bytes | \n| prod-code repository, JSON-normalized results | 3,116 bytes | 3,550 bytes | \n\nThe standalone calls ran first, against a colder analyzer, so the timings recorded alongside do\nnot show that composition is faster, and the release makes no speed claim. Nor does it claim a\nsmaller context: a direct `code_slice` already returns a symbol and its dependencies in one\ncall, and a three-call baseline is not the strongest one. Fewer round trips are what was\nobserved; whether agents choose better or finish sooner with this tool has not been tested.\n\nThe release checks are in [PR #1804](https://github.com/alex09x/prod-code/pull/1804): 55\nworkflow unit tests and the affected live workflow case passed, and six native client and\nserver binaries were built for Linux x86-64, Linux ARM64 and macOS ARM64, the macOS ones\nsigned. The strict scoped lint did not pass; it reports 260 existing diagnostics outside the\nnew modules, so this is not a release with a clean lint.\n\nThe 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.\n\n## Footnotes\n\n1. \nThe edit contract at the tag, `docs/agent-workflow-edits.md` , still carries the heading\n“development contract”. The release notes, the changelog and PR #1804 include preview, apply\nand verification in 0.3.49.[↩](#user-content-fnref-1)\n\n## Cite this article\n\n```\nAlexander 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/\n```\n\n", "url": "https://wpnews.pro/news/prod-code-0-3-49-several-code-reads-in-one-mcp-call-and-edits-that-check-what", "canonical_source": "https://prod.codes/blog/prod-code-0-3-49-several-reads-one-call/", "published_at": "2026-11-03 00:00:00+00:00", "updated_at": "2026-11-06 08:51:29.882948+00:00", "lang": "en", "topics": ["ai-agents", "agent-protocols", "developer-tools", "ai-tools"], "entities": ["prod-code", "code_workflow", "Zenodo", "alex09x", "GitHub"], "also_reported_by": [], "alternates": {"html": "https://wpnews.pro/news/prod-code-0-3-49-several-code-reads-in-one-mcp-call-and-edits-that-check-what", "markdown": "https://wpnews.pro/news/prod-code-0-3-49-several-code-reads-in-one-mcp-call-and-edits-that-check-what.md", "text": "https://wpnews.pro/news/prod-code-0-3-49-several-code-reads-in-one-mcp-call-and-edits-that-check-what.txt", "jsonld": "https://wpnews.pro/news/prod-code-0-3-49-several-code-reads-in-one-mcp-call-and-edits-that-check-what.jsonld"}}