[BUG] Cowork Windows: bwrap sandbox torn down between turns, killing background processes (works on Mac)

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?

Description

On Windows, the Cowork VM's bubblewrap (bwrap) sandbox is destroyed and recreated between every conversational turn. This kills all background processes (e.g., web servers), making it impossible to host and test local servers from within Cowork. This works correctly on Mac.

Steps to Reproduce

1. Ask Claude in Cowork to create an HTML page and serve it on localhost:8222
2. Claude starts a Python HTTP server, verifies it responds with 200
3. On the next turn, the server is dead — port 8222 is no longer active
4. Confirmed by checking that bwrap PID 1 gets fresh socket names each turn (e.g., claude-http-63626386de62bf52.sock → claude-http-f982906a3ceca549.sock)

Evidence

• /proc/uptime shows the VM kernel persists (~1.5 hrs), but PID 1 (bwrap) restarts every turn
• Unix socket names change between turns, confirming full sandbox teardown
• Get-VM and Get-HnsNetwork show no Cowork-specific Hyper-V VM or NAT network
• SSH tunneling (localhost.run, serveo) blocked by proxy ruleset
• No ability to write to systemd, crontab, or init.d from inside the sandbox
• Filesystem is read-only outside the working directory

Environment

• Windows 11
• Claude Desktop v1.1.5368 (d12d02)
• Cowork VM: Ubuntu 22, bwrap sandbox with --unshare-net

Expected Behavior

Background processes should persist between turns (as they do on Mac), allowing Claude to host and test web servers that the user can access from their browser.

Related Issues

• #25155 (VM networking unreachable)
• #28516 (NAT subnet mismatch)
• #28094 (session crash cleanup)
• #28668 (ICS-type HNS blocks WinNAT)

What Should Happen?

Background processes started by Claude inside the Cowork VM should persist between conversational turns, as they do on macOS. For example, if Claude starts a Python HTTP server on port 8222, that server should still be running and accessible when the user sends their next message. The user should be able to access http://localhost:8222 from their browser and reach the server running inside the VM. This currently works on macOS but not on Windows.

Error Messages/Logs

No error messages — the process is silently killed. Evidence of the sandbox teardown:

Turn 1: bwrap socket = claude-http-63626386de62bf52.sock
Turn 2: bwrap socket = claude-http-f982906a3ceca549.sock
fuser 8222/tcp returns "port free" on second turn
ps aux shows only fresh bwrap/socat/claude processes, no user-started processes survive
Get-VM on the Windows host returns empty (no Hyper-V VM visible)
Get-HnsNetwork shows no Cowork-specific network (only "Default Switch" and "WSL")
Get-NetNat returns empty (no NAT rules)

Steps to Reproduce

1. Open Claude Desktop v1.1.5368 on Windows 11
2. Start a Cowork session
3. Ask Claude: "Create an HTML page and serve it on localhost:8222"
4. Claude creates the file and starts python3 -m http.server 8222
5. Claude verifies the server responds with HTTP 200 (confirmed within the same turn)
6. Send a follow-up message asking Claude to check if the server is still running
7. The server is dead — fuser 8222/tcp shows nothing listening
8. Further investigation shows PID 1 (bwrap) has new Unix socket names each turn, confirming the entire sandbox was torn down and rebuilt between messages

On macOS, the server persists between turns and the user can access it from their browser.

Claude Model

Opus

Is this a regression?

No, this never worked

Last Working Version

_No response_

Claude Code Version

Version 1.1.5368 (d12d02)

Platform

Anthropic API

Operating System

Windows

Terminal/Shell

WSL (Windows Subsystem for Linux)

Additional Information

_No response_