Provider update is killed when the client's connection drops mid-update #27361

Activity

1. runshotgun commented on Nov 4, 2026

   

   runshotgun

   on Nov 4, 2026

   More actions

   Same defect on Windows with the Codex npm install: the CLI launchers are removed

   What happened (T3 Code Desktop, Windows 11 ARM64, local server, Node 24.19.0, npm 11.17.0)

   1. The app started a Codex provider update: npm install -g @openai/codex (0.165.0 to 0.166.0).
   2. 6 s later, ws.rpc.server.updateProvider ended as Interrupted ("All fibers interrupted without error", from ProviderMaintenanceRunner.runCommand / collectCommandResult). The request finalizer killed npm.
   3. npm had already put the new package in %APPDATA%\npm\node_modules\@openai\codex and moved the old codex, codex.cmd and codex.ps1 aside (.codex-<random> names), but it had not linked the new bin shims.
   4. Result: %APPDATA%\npm\codex.cmd (the provider's binaryPath) did not exist. The Codex provider was broken until a manual npm install -g @openai/[email protected], which linked the shims again and removed the .codex-* debris.

   So on npm installs this failure is worse than an old version: the CLI disappears from PATH. #27056 (OpenCode gone from PATH after an update on Windows) may have the same cause.

   Trace (server.trace.ndjson, times in UTC)

   08:36:24.3  ws.rpc.server.updateProvider            start
   08:36:24.6  ProviderMaintenanceRunner.runCommand    start (npm spawned)
   08:36:30.3  runCommand / runProviderUpdate / updateProvider / ws.rpc.server.updateProvider  exit Interrupted
   

   Seen on the nightly of 2026-11-04 before 0.1.8-nightly.20261104.4165. The handler and the addFinalizer(() => child.kill()) are unchanged in 0.1.8-nightly.20261104.4165.

   Tested fix: run the update in a detached fiber and only join it from the request

   We patched the built server locally (apps/server/src/ws.ts equivalent):

   [WS_METHODS.serverUpdateProvider]: (input) =>
     Effect.forkDetach(providerMaintenanceRunner.updateProvider(input)).pipe(
       Effect.flatMap((fiber) => Fiber.join(fiber)),
     ),

   (In the bundle we wrote the join by hand with Effect.callback + fiber.addObserver, the same as the internal fiberJoin, because Fiber.join is not imported in that chunk.) An interrupt of the request now only removes the join observer. The update keeps its own scope, so the 30-minute UPDATE_TIMEOUT_MS from #28132 still applies, and the command lock is released when the update ends.

   Test with T3's own bundled Effect module: an "update" with addFinalizer (for child.kill) that sleeps 300 ms, forked from a caller that is interrupted after 50 ms:

   original ["finalizer","caller interrupted"]                    (update killed, never finishes)
   patched  ["caller interrupted","update finished","finalizer"]  (update finishes after the drop)
   

   Normal calls still return the update result, and update errors still reach the caller. The patched server starts and runs normally.

   Open point for an upstream fix: a client that reconnects does not re-attach to the running update's progress. The provider maintenance action state still shows it.

   Filed by Claude Opus 5.5 in Claude Code, via T3 Code triage.