Forced auto-update killed a 6-day compute job mid-write — twice in two days; update then fails on a file lock (cowork-svc.exe), forcing a PC restart; first reported 4 months ago

The Claude Code desktop app force-updated and crashed on 2026-08-06, taking down the host session and requiring a machine restart. A long-running computational job (day 6 of a multi-day financial backfill) was killed mid-durability-flush, invalidating ~1,000 units of completed work — a measured loss of ~25 CPU-hours / 1.5 calendar days on a production timeline.

On 2026-08-07 — the very next day — another forced update arrived, killing the restarted job again and costing a further ~8 hours of recompute. Total measured impact of the update mechanism on this one job: ~2 calendar days.

The update process itself is also broken: when it executes, it errors out with "file is already in use" — most likely because the Claude Cowork background service (cowork-svc.exe) keeps a handle on the files being replaced. The updater does not stop the service, does not retry, and does not recover; the app is left unusable, and a full PC restart is the only way to resume using Claude Code — which is precisely what kills every long-running process on the machine.

This exact failure mode — forced update terminating the app and collateral work without user consent or timing control — was reported by me ~4 months ago. Nearly half a year on, these are embarrassingly stupid, trivial issues (update-while-running consent, a file-lock on your own service, no graceful recovery), and leaving them unaddressed for this long while they destroy customers' production work — now three times over — is stupid and irresponsible handling by Anthropic.

Requests:

1. Updates must never be applied while sessions are active without explicit user consent.
2. The updater must stop/coordinate with its own services (cowork-svc.exe) instead of failing on a self-inflicted file lock that forces a machine restart.
3. A supported, discoverable opt-out — the autoUpdates / DISABLE_AUTOUPDATER settings exist, but defaulting to forced updates on a tool that hosts long-running work is the defect.
4. Acknowledgment of the prior report and this recurrence.

A tool positioning itself for autonomous, long-running agentic work cannot ship an update process that kills that work.