Recover from lost MCP operation responses

[QinyangTan]

I’m using DevSpace with ChatGPT over the remote MCP endpoint for normal coding work on my Mac.

The specific reliability problem here is not the transport disconnect itself. It is what happens when a local side effect has already started or completed, but the MCP response is lost before the caller receives it.

Two concrete cases:

• A file mutation succeeds locally, but ChatGPT does not receive the result. A blind retry can repeat the mutation or act on stale file state.
• exec_command creates a process session locally, but the response containing the sessionId is lost. The process can continue running while the caller no longer has its handle. The same retry problem applies to write_stdin, where repeating an unknown call could send input twice.

The scope here is only recovery from that lost-response ambiguity. DevSpace does not need to handle tunnel failures or reconnect the transport itself.

The current #335 approach uses a required stable operationId on side-effecting tools. DevSpace records the first operation result in memory for the lifetime of the server process. An exact retry with the same operation ID joins/replays the original operation instead of repeating the side effect; using the same ID with different arguments fails closed. File write/edit also keep an expected-before content hash as a second guard for a new operation based on stale state.

This is intentionally process-local. It does not try to survive a DevSpace restart, which is a separate lifecycle problem.

[Waishnav]

Please explain “why” of this issue? Is it bug? Weird behavior you came across?

Don’t write AI slop in issue description

[QinyangTan]

This came from issues I actually ran into while using DevSpace with ChatGPT on my Mac.

My normal setup is ChatGPT connected to DevSpace through the remote MCP endpoint, and I use it for regular coding work — editing files, running tests, builds, commands, etc.

What I’ve seen a few times is that the MCP request times out or the connection drops, but the local operation has already happened. From my side I can see that DevSpace did something on the Mac, while ChatGPT only sees a failed or missing tool result.

With file edits, after reconnecting ChatGPT doesn’t really know whether the previous edit was applied. If it retries based on the file state it saw before the timeout, that retry can already be stale. That’s where the hash precondition idea came from. I mainly wanted stale retries to fail instead of modifying a file that has changed since the agent last saw it.

I ran into a similar thing with long-running commands. Normally the existing sessionId + write_stdin flow works fine. The problem is when exec_command starts the process locally, but the MCP response carrying the sessionId never gets back to ChatGPT. Then the process can still be running, but ChatGPT has lost the handle to it.

So the issue came from repeatedly hitting the same pattern: the local side has already moved forward, but because the remote MCP response was lost, ChatGPT no longer knows exactly what state it is in.

The operation ID / durable job ideas in the original issue were possible follow-ups after seeing that pattern. The file precondition PR is the small concrete fix I wanted to start with.

[Waishnav]

this is issue associated with #303 btw

will be solved by today and released in beta, in the meantime you can try his branch and see if it this issue is still reproducable

[QinyangTan]

I tried the current #303 branch (7c0259e8ac6b5e2f09e72c04e19e6e988a0f334a) in an isolated sandbox and split the test into the normal #303 path and the response-loss case I was seeing.

The normal #303 behavior looks good: a ~15s command with a 30s yield completed in the initial exec_command call (15048ms, running=false, no session_id), and the short-yield -> session_id -> poll flow also completed normally.

I then injected a transport failure after the local side had already moved forward. Two cases were still reproducible:

• a process session was created locally, the initial response containing its session_id was treated as lost, and the local command still completed while the caller had no handle to poll it;
• a file mutation completed locally, the response socket was dropped, and a blind retry after another change could overwrite the newer state.

So #303 seems to fix the model-facing snake_case/yield contract issue, but I don't think it fully covers the separate "local operation committed but MCP response was lost" case. The current apply_patch contract on that branch is still just workspace_id + patch, so there isn't a version/precondition or operation receipt for that ambiguity.

Sandbox evidence:

Full transcript: https://github.com/QinyangTan/devspace/blob/a36f07823299f1df16ed0f1df882fe38ff549ce0/evidence/pr303-sandbox-evidence.txt

I’ve now narrowed #334 to only the lost-response reliability case and updated #335 to describe only the stale-retry guard. Transport/disconnect handling is no longer part of the proposed DevSpace scope.

[Waishnav]

Thanks, this makes sense. #303 rules out the yield/schema issue, so this does look separate.

One thing though: I don't think the evidence shows a ~15s ChatGPT timeout — your #303 test successfully returned after ~15s, and you previously saw the same network error on near-instant calls too. The actual disconnect itself still looks like a host/transport-side issue rather than something DevSpace should try to solve.

That said, the “operation succeeded locally but its response was lost” ambiguity is a valid DevSpace reliability problem. Please narrow #334 to that case specifically. I'd avoid bundling transport/disconnect handling into it; let's focus on whether we need a minimal recovery mechanism for lost mutation/process responses.

[QinyangTan]

I reran the narrowed file-mutation case against the current upstream main (67d4c8f8fce08c171eea6f820a0ee090ae81c1d0), separate from #303.

I overlaid the #335 fix on that exact main in an isolated validation branch and added a focused regression for the actual uncertain-result case:

1. the first file mutation succeeds locally, but its response is treated as lost;
2. the file changes again before the caller retries;
3. the caller retries using the original expected-before hash;
4. the retry is rejected and the newer file state is preserved.

The focused precondition/concurrency suite is 6/6 passing. This confirms #335 handles the stale-retry safety part of this narrowed issue: it fails closed instead of overwriting newer state after an uncertain response.

It does not recover the original lost response or provide an operation receipt, so I’m treating it as a small safety primitive rather than a full response-recovery mechanism.

Full validation note: https://github.com/QinyangTan/devspace/blob/24ec39c8236cd7c9c210c5862022788537952188/evidence/lost-response-fix-latest-main.txt

[QinyangTan]

I narrowed this down to the lost-response case and updated #335 with the recovery mechanism.

The current version uses a required stable operationId on side-effecting tools. If the local operation runs but the MCP response is lost, retrying the exact same call with the same ID returns/joins the original result instead of executing the side effect again. Reusing that ID with different arguments fails closed. This now covers file mutations, apply_patch, exec_command, and write_stdin; the existing file hash precondition stays as a second guard for a new operation based on stale file state.

I tested the current design in a Node 22 sandbox: 19 focused tests passed, including two real HTTP fault injections where I destroyed the response socket after the local file write / process start. The retry preserved newer file state and recovered the original process session instead of starting a duplicate. write_stdin retries also did not duplicate input.

Evidence: https://raw.githubusercontent.com/QinyangTan/devspace/2285943414b86676e1eeab45dd0234b5141ea86d/evidence/lost-response-recovery-production-validation.svg

The boundary is still the one we discussed: this is process-local recovery only; it does not handle the transport or survive a DevSpace restart. GitHub Actions for the fork PR is currently action_required, so I’m not claiming a full CI pass yet.