[BUG] Failed to Start Claude's Workspace

Found 3 possible duplicate issues:

1. https://github.com/anthropics/claude-code/issues/46768
2. https://github.com/anthropics/claude-code/issues/46687
3. https://github.com/anthropics/claude-code/issues/46661

This issue will be automatically closed as a duplicate in 3 days.

• If your issue is a duplicate, please close it and 👍 the existing issue instead
• To prevent auto-closure, add a comment or 👎 this comment

🤖 Generated with Claude Code

I am getting:
Failed to start Claude's workspaceCan't reach the Claude API from Claude's workspace.Restarting Claude or reconnecting to your network sometimes resolves this.

I have tried restarting Claude app, my WiFi - nothing works!!!

Claude App version: Claude 1.2278.0 (e5213f) 2026-04-13T17:49:21.000Z

Closing for now — inactive for too long. Please open a new issue if this is still relevant.

Im facing the same issue

I hit this exact error and found the root cause on my machine — posting the diagnosis + fix since this thread keeps collecting "+1, same issue" comments after being auto-closed.

TL;DR

VZErrorDomain Code=1 (VZErrorInternal) is Apple's generic "VM failed to start" error — but in my case it was not an Apple bug. A hung, duplicate Claude.app instance from the previous day was still holding the workspace VM's disk images through its com.apple.Virtualization.VirtualMachine XPC service. Every fresh Claude instance then failed to start the VM. "Restart Claude" never helps in this state, because quitting the visible window leaves the hung background instance untouched.

How to check if this is your case (30 seconds)

ps axo pid,lstart,comm | grep -E 'MacOS/Claude$|Virtualization.VirtualMachine'

Red flags:

• Two /Applications/Claude.app/Contents/MacOS/Claude rows (one with an old start date)
• A com.apple.Virtualization.VirtualMachine process whose start time is hours/days old

Also check disk space — this matters (see below):

df -h /

The fix

# 1. Kill ALL Claude Desktop instances (graceful first)
kill -TERM <pid-of-old-Claude> <pid-of-new-Claude>
# wait a few seconds; kill -9 any survivors
# (killing the owning instance also takes down the stale VM XPC service)

# 2. Verify nothing is left
ps axo pid,comm | grep -E 'MacOS/Claude$|Virtualization.VirtualMachine'

# 3. Relaunch
open -a Claude

Verification that the VM actually booted: this file's mtime updates a few seconds after launch once the guest gets an IP:

stat -f '%Sm' ~/Library/Application\ Support/Claude/vm_bundles/claudevm.bundle/vmIP

In my case the workspace booted ~14s after a clean relaunch. No reinstall needed, no data lost.

Important co-factor: low disk space

The workspace VM bundle (~/Library/Application Support/Claude/vm_bundles/claudevm.bundle/) is ~13 GB, and the app's auto-recovery path re-extracts a fresh ~10 GB rootfs.img. I had only ~15 GB free, so Claude's built-in self-repair (there's a .auto_reinstall_attempted marker showing it tried) silently failed — it physically couldn't fit the rebuild. If you're low on disk, the "reinstall the workspace" link in the error dialog will fail too. Keep ≥ 25–30 GB free before retrying.

Why this thread keeps getting closed

VZErrorDomain Code=1 is a catch-all, so reports here mix several distinct causes that each need different fixes:

• Hung duplicate instance holding the VM → this comment (fix above)
• Low disk → reinstall/recovery can't fit → free space first
• Home directory on external SSD → #34827
• VM runtime missing from the app bundle (packaging bug) → #31647
• VM service not running at all → #27801

Without ps output, disk numbers, or logs, these all look identical and unreproducible, so the bot closes them. If the fix above doesn't apply to you, attach the output of the ps and df commands plus:

log show --last 1h --predicate 'process == "com.apple.Virtualization.VirtualMachine"' --style compact | tail -50

…that gives maintainers something actionable instead of another auto-close.

Suggestion for @anthropic maintainers: the error dialog's advice ("Restart Claude") is actively misleading in the duplicate-instance case — the app could detect an existing live VM XPC/bundle claim at startup and offer to terminate the stale owner, and the auto-reinstall path should check free disk before extracting and surface a clear "need X GB free" error instead of failing into the generic VZErrorInternal.

This issue has been automatically locked since it was closed and has not had any activity for 7 days. If you're experiencing a similar issue, please file a new issue and reference this one if it's relevant.