[BUG] Cowork VM fails to boot on Intel Mac after update to 1.32352.1 — guest kernel halts at ~1.7 s, host hangs at usernet: calling AcceptBess (works on 1.25927.0)

Preflight Checklist

• [x] I have searched existing issues and this hasn't been reported yet
• [x] This is a single bug report (please file separate reports for different bugs)
• [x] I am using the latest version of Claude Code

What's Wrong?

After Claude Desktop auto-updated on 18 August 2026, the Cowork Linux VM stopped starting on an Intel Mac. Every shell command returns either "Workspace unavailable. The isolated Linux environment on this device failed to start" or, during boot attempts, "Workspace still starting" indefinitely. Reverting the application to the previously installed build restored normal operation immediately. The rest of the device bridge — file reads, writes, directory listings — worked correctly throughout; only the VM is affected.

What Should Happen?

Claude should be able to start up and use the Cowork Linux VM.

Error Messages/Logs

Steps to Reproduce

Install version 1.32352.1 on an Intel Mac. Attempt to run some activity that requires the VM.

Claude Model

Opus 5

Is this a regression?

Yes, this worked in a previous version

Last Working Version

at least 1.25927.0 still worked

Claude Code Version

1.32352.1

Platform

Anthropic API

Operating System

macOS

Terminal/Shell

Terminal.app (macOS)

Additional Information

Summary

After Claude Desktop auto-updated on 18 August 2026, the Cowork Linux VM stopped starting on an Intel Mac. Every shell command returns either "Workspace unavailable. The isolated Linux environment on this device failed to start" or, during boot attempts, "Workspace still starting" indefinitely. Reverting the application to the previously installed build restored normal operation immediately. The rest of the device bridge — file reads, writes, directory listings — worked correctly throughout; only the VM is affected.

Environment

| Item | Value |
|---|---|
| Platform | macOS, Intel (x86_64) |
| App version, failing | 1.32352.1 (installed automatically 18 Aug 2026 at 00:14) |
| App version, working | 1.25927.0 (restored from a local copy; verified working) |
| Electron | 42.9.2 |
| Node | 24.18.1 |
| Free disk | 58 GB |
| VM bundle | 22.85 GB, freshly downloaded |
| macOS updates in period | none recorded by softwareupdate --history |

Symptoms

Two error strings alternate depending on the phase:

Workspace unavailable. The isolated Linux environment on this device failed to start.

Workspace still starting. The isolated Linux environment on this device is booting in the
background (usually 10–30 seconds). Try again shortly.

The second persisted for over thirty minutes on several attempts, against a stated expectation of 10–30 seconds.

Evidence — the guest kernel boots, then halts

~/Library/Logs/Claude/coworkd.log shows the guest kernel completing device initialisation and then stopping at roughly 1.73 seconds. Last lines:

[KERNEL] [    1.206082] x86/mm: Checked W+X mappings: passed, no W+X pages found.
[KERNEL] [    1.206958] Run /init as init process
[KERNEL] [    1.294335] virtio_net virtio0 enp0s1: renamed from eth0
[KERNEL] [    1.294657] NET: Registered PF_VSOCK protocol family
[KERNEL] [    1.306433] [drm] Initialized virtio_gpu 0.1.0 0 for 0000:00:0a.0 on minor 0
[KERNEL] [    1.670568] raid6: avx2x4   gen() 38383 MB/s
[KERNEL] [    1.727056] clocksource: Switched to clocksource tsc
[KERNEL] [    1.729451] async_tx: api initialized (async)
[KERNEL] [    1.731649] xor: automatically using best checksumming function   avx

Nothing follows. coworkd never reports in.

Evidence — the host waits for a guest connection that never arrives

~/Library/Logs/Claude/vzgvisor.log, complete file (545 bytes):

time="2026-08-18T22:03:24+03:00" level=info msg="usernet: starting with sockFD=45"
time="2026-08-18T22:03:24+03:00" level=info msg="usernet: vmMAC=ee:ba:cf:ac:6a:0d"
time="2026-08-18T22:03:24+03:00" level=info msg="usernet: virtual network created successfully"
time="2026-08-18T22:03:24+03:00" level=info msg="usernet: net.Conn created from socket, type=*net.UnixConn"
time="2026-08-18T22:03:24+03:00" level=info msg="usernet: network stack started successfully"
time="2026-08-18T22:03:24+03:00" level=info msg="usernet: calling AcceptBess..."

The host's network stack starts correctly and then blocks at AcceptBess.

Ruled out

Each of these was tried and made no difference:

• Quitting and relaunching the application.
• A full machine restart.
• Deleting ~/Library/Application Support/Claude/vm_bundles/claudevm.bundle entirely and allowing a fresh 22.85 GB download. The new bundle downloaded and unpacked successfully; the VM still failed to start, so a corrupt image is not the cause.
• Disk space: 58 GB free throughout.
• VPN. Tailscale runs permanently on this machine, including during the weeks when Cowork worked. Quitting it completely, so its network extension unloaded, changed nothing.
• macOS updates: softwareupdate --history is empty.

Regression range

Not narrowed to a single release. 1.25927.0 is verified working and 1.32352.1 is verified broken; intermediate builds were not tested. The application had been working normally for several weeks up to and including 16 August 2026, per timestamps in cowork_vm_swift.log, which records successful VM process spawns until 16 August at 21:21 and none afterwards.

Secondary defect — disableAutoUpdates has no effect

After reverting to the working build, the following was set to prevent the broken build reinstalling itself:

defaults write com.anthropic.claudefordesktop disableAutoUpdates -bool true
defaults read com.anthropic.claudefordesktop disableAutoUpdates
1

The application downloaded the update anyway and presented the privileged-helper authorisation prompt to install it. disableAutoUpdates in the com.anthropic.claudefordesktop domain is the key documented in Enterprise configuration for Claude Desktop; the documentation specifies MDM deployment and does not state whether a locally set value is honoured. If it is intended to work only when delivered as a managed preference, the documentation should say so; if it is intended to work generally, it does not.

Impact and current position

The VM for Claude is usable only by keeping the older build and declining the update authorisation prompt at every launch.

Requested service / product changes

1. Make older versions available and easily accessible on the Anthropic website.

Two product changes as ordinary user-facing settings, not enterprise-only controls:

1. A setting to turn off automatic updates. There is currently no user-facing option. An individual user who finds that an update breaks their machine has no supported way to stay on a working build: disableAutoUpdates is documented for MDM deployment, and setting it locally had no effect (above). The only method that worked was declining the privileged-helper authorisation prompt at every launch, which is a refusal mechanism rather than a preference, and which has to be repeated indefinitely.

1. A setting to keep the superseded version on disk when updating. An update that replaces the working application with a broken one is unrecoverable for a user who has no backup, because older builds are not offered for download. Retaining the previous build — automatically, or behind a setting for users who want the safety margin — would turn this class of failure into a two-minute revert.

Diagnostic suggestions

• The guest console output stops without an error, so a failure reason is not being captured. Logging guest kernel and init output through to the failure point would make this class of problem diagnosable without reconstruction from timestamps.
• The distinction between "failed to start" and "still starting" does not correspond to observable state: "still starting" persisted for over thirty minutes.