Build1 distinct publisher3 min readPublished
A blocking MCP tool call asks the client's idle timer to stay patient for four minutes. The fix that survived eleven releases is to return a readable resource as soon as the command proves it is slow.
The Engineer · Build desk

Compiled by The EngineerSomething wrong?How this is made
Do the subtraction and the shape of the failure is clear: a 240-second suite cancelled at second 60 leaves 180 seconds of compilation happening where nobody is watching, three quarters of the run [1]. Cancellation is a message to the client, not a signal to the child, so the process kept going while the model sat holding an error where its results should have been [2]. The workaround the model invented later, `sleep 240`, matched the suite's runtime exactly, which is the closest thing to a spec that anyone had given it [4][4].
The first patch treated the silence. Release 0.10.2 emits a progress notification every ten seconds while a command runs in the foreground [6]. Six of those intervals fit inside a sixty-second window, so the call tolerates five consecutive dropped beats before the silence adds up to a cancellation [2]. That fixed the killings without touching the blocking [7].
What happens now at second ten is worth reading closely. The command is not killed and not restarted; the same process is promoted to a background job [11]. Output capture is durable from the first byte, so nothing printed during its foreground life is lost at the boundary [12]. The tool call returns immediately with a resource link whose name is the command itself, which is what lets a client still render "make test ... still running" after a context compaction has discarded the original request [13]. Each job is an MCP resource with a URI like `octofs://jobs/17342-1` [17]. On exit the server emits `notifications/resources/updated` for that URI, and one read hands back the exit code and the output tail [14]. The longest blocking call in that path goes from 240 seconds to about 10, a factor of 24 [3].
The flag is the more portable lesson. Background execution shipped in 0.11.0 behind a flag on the shell tool, and 0.13.0 deleted it, because the flag asked the model to predict a duration it cannot know: `cargo build` is instant on a warm cache and six minutes cold [8][10][11]. The author traces the reasoning to 0.9.0, when a `--line-mode` switch was removed on the grounds that safety shipped behind a flag is safety most people never enable [9]. It is a rare release note that describes its own feature as the same bug in a different costume [8].
Two things have to be true before that ten-second threshold transfers. Your workload has to be bimodal the way builds and test suites are, with fast calls well under the line and slow ones well over it; if most of your calls land just past it, you promote nearly everything and pay a round trip on each. And your client has to render resource links and act on `resources/updated` [13][14]. A client that ignores both leaves you back at polling with a tidier URI [4].
One default I would copy outright: a resource read returns at most the last 30 KB [15]. The verdict lives at the end of a build log, and feeding a model the first 30 KB of a log whose final line reads FAILED is how you get a confident report that everything passed [16].
Ranked by verification strength, evidence, and original report placement.
An agent ran a test suite that takes four minutes, against an MCP client whose idle timeout is sixty seconds.
At second sixty the client cancelled the call. The process kept running because nobody told it to stop, and the model, holding a cancellation where its test results should have been, ran the suite again.
Two test suites ran in the same directory racing each other over the same build artifacts; the second failed with a locking error, the model reported the tests as broken, and the tests were fine.
In another session the same model developed a workaround: run the build, then call sleep 240, then look. The author describes this as the model reinventing polling badly because it had not been given anything better.
The author builds octofs, an open-source MCP filesystem server, and the incident set the agenda for eleven releases in two weeks, 0.10.1 through 0.14.1.
Release 0.10.2 added liveness heartbeats: while a command runs in the foreground, octofs emits a progress notification every ten seconds, described as well below any sane idle timeout so that a single missed beat cannot cancel the call.
Distinct publishers with included, body-backed reporting in this cluster.
dev.to
1 article · September 2, 2026
Follow any of these and your For You feed starts watching them — no settings page required.
build
One state machine or two: the transaction fork hiding inside your MCP server1 distinct publisher
build
One join point, two audiences: why the MCP server reads the build artifact, not the source1 distinct publisher
build
Keycloak's metadata-document executor provisions clients that accept plain PKCE1 distinct publisher
build
Pandex hooked a Fortune 500 agent four minutes after claiming a package name from llms.txt1 distinct publisher
Evidence-backed comparisons of source perspectives and observed adoption signals. Read the methodology
Which Builder, Operator, and Investor concerns the observed source mix emphasized—not a truth score.
Evidence, demonstrated adoption, hype gap, incentives, and confidence are assessed independently, each on its own current evidence. How these are measured.
One implementer, unusually checkable
The sixty-second cancellation, the eleven releases, the ten-second promotion window and the 30 KB tail all come from the person who wrote the server, published on dev.to. That makes him the best available witness to what the code does and the only witness to whether it fixed anything: no other outlet, no user report, no issue thread appears anywhere in this reporting. What keeps the score respectable rather than low is specificity — version numbers, a URI scheme and a named notification either exist in a public repository or they do not.
Shipping, not uptake
Eleven releases in a fortnight tells you the maintainer was busy; it says nothing about anyone installing them. The only agent sessions described are his own, and there are no installs, stars, downstream MCP clients or third-party deployments anywhere in this reporting. We would rather record that we do not know than read a changelog as traction.
Talks itself down, then closes with an absolute
This is not how overselling normally sounds — the author calls his own flag "the same bug in a different costume" and describes an earlier release as too blunt. What nudges the needle positive is the framing around the edges: "Nothing blocks, nothing gets killed, nothing runs twice," asserted for a design two weeks old with exactly one user, and a ten-second window presented as measurement replacing prediction when no measurements are actually shown.
Maintainer touring his own release notes
The incident is real reporting and it is also the best possible argument for installing octofs; the four releases double as a product walkthrough. Nothing is concealed — the authorship sits in the second paragraph — and no pricing, funding or vendor relationship is in view, so the pull is reputational rather than commercial. The tell is what goes unmeasured: the failure is narrated in detail, the success is asserted.
Sure what it does, less sure it generalises
We are fairly confident about the mechanics, because they interlock in ways an author only discovers by being bitten: durable capture from the first byte is precisely what makes a ten-second promotion safe, and replaying completion to a late subscriber is not a detail you invent at a whiteboard. Confidence drops on the wider proposition. A pattern that survived eleven releases in one repository, graded by its own author against one recurring failure, is thinner ground than the writing implies.