### Preflight Checklist - [x] I have searched [existing issues](https://github.com/anthropics/claude-code/issues?q=is%3Aissue%20state%3Aopen%20label%3Abug) 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? **App Version:** Claude for Windows 1.5354.0 (9a9e3d) **OS:** Windows **Conversation ID:** 215474154138182 ## Description The Linux bash sandbox in Cowor

[BUG] Cowork mode - Linux bash sandbox never starts on Windows (Workspace unavailable since first launch)

Status Closed — not planned

Maintainer reply None cached

Workaround ✓ Mentioned in thread ↓

Activity 14 comments · opened May 2, 2026 · closed Jul 25, 2026

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?

App Version: Claude for Windows 1.5354.0 (9a9e3d)
OS: Windows
Conversation ID: 215474154138182

Description

The Linux bash sandbox in Cowork mode has never successfully started since the first launch on April 28, 2026. Every bash command returns "Workspace still starting" and has since changed to "Workspace unavailable. The isolated Linux environment failed to start." Plugins were also not auto-generated on initial setup.

Error Message

"Workspace unavailable. The isolated Linux environment failed to start."

Windows Event Viewer Logs

The following errors were found in Windows Logs > Application:

Event ID 1002 - Application Hang (2026-05-03, 12:52:40)
claude.exe version 1.5354.0.0 stopped interacting with Windows and was terminated.

Event ID 1000 - Application Error (2026-05-03, 01:49:52 and 01:58:10, recurring)
Faulting application: secureconnectionservice.exe, version 1.0.0.3, timestamp 0x64171421
This process crashes repeatedly.

Event ID 1 - CoworkVMService (2026-05-03, 01:50:11 and 01:58:22)
Logs appear immediately after each secureconnectionservice.exe crash.

Suspected failure chain: secureconnectionservice.exe crashes → CoworkVMService fails to initialize → bash sandbox cannot start.

Troubleshooting Steps Completed (all failed)

[x] Cleared C: drive space (~2GB → 45GB free)
[x] Restarted app multiple times
[x] Rebooted PC
[x] Ran app as administrator
[x] Help > Troubleshooting > Clear Cache and Restart
[x] Help > Troubleshooting > Reset App Data
[x] Terminated F5 VPN
[x] Disabled other network security tools
[x] Disabled third-party antivirus programs (only Windows Defender remains active)

None of the above resolved the issue.

Additional Notes

This issue has persisted since the very first launch. The sandbox has never worked even once. Engineering-level investigation of the CoworkVMService and secureconnectionservice.exe components appears to be required.

What Should Happen?

The Linux bash sandbox in Cowork mode should start successfully and execute bash commands without errors.

Error Messages/Logs

Workspace unavailable. The isolated Linux environment failed to start.

Steps to Reproduce

Install Claude for Windows (Cowork mode) version 1.5354.0
Launch the Cowork desktop app
Start any conversation and request a bash command
Observe: "Workspace still starting" error appears and never resolves
Error eventually changes to "Workspace unavailable. The isolated Linux environment failed to start."

Claude Model

None

Is this a regression?

No, this never worked

Last Working Version

_No response_

Claude Code Version

1.5354.0 (9a9e3d)

Platform

Anthropic API

Operating System

Windows

Terminal/Shell

Non-interactive/CI environment

Additional Information

This issue occurs in Cowork desktop app (not Claude Code CLI). The bash sandbox has never worked since first launch on 2026-04-28. Plugins were also not auto-generated on initial setup.

Anthropic Support Conversation ID: 215474154138182

All third-party VPN (F5) and security tools were disabled during testing — issue persists with only Windows Defender active.

View original on GitHub ↗

14 Comments

parkjune0723-netizen · 3 months ago

✅ RESOLVED — Solution for Windows users

Root Cause: CoworkVMService was set to Automatic startup but consistently failed to start on boot (due to secureconnectionservice.exe crash on startup).

Fix that worked:

Step 1: Open PowerShell as Administrator and run:

Restart-Service vmcompute -Force
Restart-Service hns -Force
Start-Service -Name "CoworkVMService"

Step 2: Create a scheduled task to auto-start the service on every boot:

$action = New-ScheduledTaskAction -Execute "powershell.exe" -Argument "-NonInteractive -WindowStyle Hidden -Command `"Start-Service -Name CoworkVMService`""
$trigger = New-ScheduledTaskTrigger -AtStartup
$principal = New-ScheduledTaskPrincipal -UserId "SYSTEM" -LogonType ServiceAccount -RunLevel Highest
$settings = New-ScheduledTaskSettingsSet -ExecutionTimeLimit (New-TimeSpan -Minutes 2)
Register-ScheduledTask -TaskName "StartCoworkVMService" -Action $action -Trigger $trigger -Principal $principal -Settings $settings -Force

Result: After reboot, CoworkVMService starts automatically and the bash sandbox works correctly. ✅

Note: sc.exe config CoworkVMService start= delayed-auto returns "Access Denied" even as Administrator — use the scheduled task workaround above instead.

mozkan985 · 3 months ago

+1
Same issue on Windows 11, Cowork desktop app (Microsoft Store version). Error message identical: "Workspace unavailable. The isolated Linux environment failed to start." Persists across multiple sessions. File tools work, only Linux sandbox is dead.

gaborschilten · 3 months ago

+1 — same symptom on Windows desktop Cowork, May 9 2026
(Europe/Amsterdam, NL).

Pattern persisted since May 7 ~22:00 CEST across:

Full Claude desktop app restart (multiple times)
Full Windows app restart (twice)
Complete reinstall (Microsoft Store removed, standalone installer + admin)
PowerShell fix from earlier in this thread (Restart-Service +

scheduled task) — CoworkVMService is Running, but workaround had no
effect on bash sandbox availability

Local diagnostics confirm server-side, not client:

CoworkVMService Running (PID 12112), 9 claude.exe processes alive
Test-NetConnection api.anthropic.com:443 succeeds
Hyper-V Compute log shows ZERO cowork-vm-* create attempts today.

Last attempts were May 5 and May 8 with errors 0xC0370103
(HCS_E_INVALID_STATE) and 0xC037010D. Today the app no longer
initiates local VM-create, suggesting a remote-only flow is
active that's failing upstream.

Engineering can use this Hyper-V log delta as a marker:
affected sessions show the app not even attempting local-VM-create.

Running an autonomous-agent Cowork-mode project; sandbox is the
critical execution path. Max subscriber.

herciubogdan-star · 3 months ago

+1 — same symptom on Windows 11 Home desktop Cowork, May 9 2026
(Europe/Iasi, RO).

Startup failed: Error: failed to set VHDX path: VHDX file not found:

On May 7, following the update to version 1.6608.2.0, the initial launch triggered an error that has since recurred identically at every startup (I have counted dozens of instances in the log, up to May 9 at 16:03):

leepotts · 3 months ago

On Windows 11. Completed the steps suggested above and the sandbox is still not starting correctly.

mederic-coreai · 3 months ago

« +1 same symptom on Surface Book 3 / Windows 11 Pro / i7-1065G7. Identified root cause as 5-second timeout race between Claude Desktop and CoworkVMService startup. Detailed trace and PowerShell workaround posted in #48661 ([link to your comment]). Sharing in case it helps others land on the right fix faster than nuking their install. »

jmgrebenc · 3 months ago

+1, also affected on Windows. Same exact failure mode as described — symptoms match yours precisely, including the post-29-April-2026 regression timeline.
Environment matches:

App: Claude Cowork (Microsoft Store), Windows build in the 1.5354.x range
OS: Windows
First observed today, 2026-05-10
Session cwd format: C:\Users\<user>\AppData\Roaming\Claude\local-agent-mode-sessions\<group>\<session>\... — the long AppData path that #56145 flagged as a post-update change
Specific session ID for log correlation: local_a58f0243-3482-46cb-a22f-697690e039ec (additional session IDs available on request)

Behavior matches:

Every mcp__workspace__bash call returns Workspace unavailable. The isolated Linux environment failed to start. instantly — no startup delay, no retry, sandbox never becomes available.
Reproduces across multiple fresh sessions and across multiple model selections (tried both Opus 4.7 and a "Legacy Model" pinned in a separate session). Both fail identically.

Tried, did not resolve:

Fully quitting Cowork via the tray icon and reopening
Starting a fresh session
Switching to a different model
(I did not disable Windows Defender or third-party security tools, given your report that those also did not resolve it.)

I have not personally captured Event Viewer logs yet, but I'd be happy to if it would help — if there's a specific time window or set of source filters that would be most useful, let me know.
Impact: I'm using Cowork for non-coding workflows (file generation, document assembly via openpyxl). With the sandbox down I'm forced into an in-browser JS workaround that's significantly slower to iterate than the documented Python path. Subscribing for fix notifications.
The secureconnectionservice.exe → CoworkVMService failure-chain theory in the original post is consistent with the instant-fail-no-retry pattern I'm seeing. Eager to test once a fix is shipped.

herciubogdan-star · 3 months ago

What worked for me based on reading the log and the instructions provided by Claude:
________________________________________
Until May 7, 2026, at 08:12 AM, everything was functioning normally with version 1.6041 of the application. The VM bundle—the rootfs.vhdx file (Linux disk image)—was downloaded and saved at:

C:\Users\....\AppData\Roaming\Claude\vm_bundles\claudevm.bundle\rootfs.vhdx

On May 7, following the update to version 1.6608.2.0, the initial launch generated an error that has since repeated identically with every startup (I have counted dozens of occurrences in the log, up until May 9, 16:03):

Startup failed: Error: failed to set VHDX path: VHDX file not found: C:\Users\.......\AppData\Local\Packages\Claude_pzs8sxrjxfjjc\LocalCache\Local\Claude\vm_bundles\claudevm.bundle\rootfs.vhdx

What went wrong
The update changed the location where the VM service looks for the rootfs.vhdx file:
• The TypeScript component (vmClient) continues to use the old Roaming\Claude\ path and reports the "bundle path" correctly.
• The Windows VM service (the native helper that actually mounts the disk) now looks in the Microsoft Store MSIX sandboxed path: Local\Packages\Claude_pzs8sxrjxfjjc\LocalCache\Local\Claude\

In other words: the two components fell out of sync after the update. Your VHDX file exists, but the service is looking for it in the wrong place.
Furthermore, the application's auto-recovery mechanism has locked itself: the line Skipping auto-reinstall (already attempted once) indicates that the application tried to redownload its bundle once, failed, and now refuses to try again—a flag persists between restarts and does not reset even after restarting the application.

Solution
Two options, in order of recommendation:
Option A — Manual VHDX Copy (Fast, preserves data)
The fastest method is to copy the bundle from the old location to the new one. Open File Explorer as an administrator and:

Completely close Claude Desktop and terminate all Claude processes in Task Manager (including cowork-svc.exe).
Copy all contents of the folder:

C:\Users\......\AppData\Roaming\Claude\vm_bundles\claudevm.bundle\
into:
C:\Users\......\AppData\Local\Packages\Claude_pzs8sxrjxfjjc\LocalCache\Local\Claude\vm_bundles\claudevm.bundle\

You will likely need to create the missing sub-folders manually. The target folder (AppData\Local\Packages\...) is an MSIX sandboxed location—Windows treats it specially, but copying with Explorer as an administrator will work.

Start Claude Desktop and try again.

mederic-coreai · 3 months ago

« +1 same symptom on Surface Book 3 / Windows 11 Pro / i7-1065G7. Identified root cause as 5-second timeout race between Claude Desktop and CoworkVMService startup. Detailed trace and PowerShell workaround posted in #48661 ([link to your comment]). Sharing in case it helps others land on the right fix faster than nuking their install. »

Update from my Surface Book 3 case (Claude Desktop 1.6608.2.0, Microsoft Store install):
Confirmed via PowerShell history that I did NOT manually set CoworkVMService to Automatic. The service is now StartupType: Automatic natively — looks like Anthropic shipped this change in build 1.6608.2.0 or earlier. This contradicts the Access-denied behavior reported in issues #27010 and #29941 on previous versions.
However, the partial fix is insufficient: after a Windows reboot, CoworkVMService was found Stopped despite Automatic startup. The service appears to fail silently at boot (no entry in Application Event Log under "CoworkVMService" provider, no crash visible). Windows doesn't auto-retry the service even though it's configured Automatic.
Workaround that survives reboots:

The Automatic startup alone is NOT enough
A scheduled task at logon with Start-Service CoworkVMService IS still needed as a safety net
Set-Service no longer requires registry hacks on this build — happens to be already Automatic

Recommend Anthropic also add a service recovery action (e.g. sc failure CoworkVMService reset= 60 actions= restart/5000/restart/10000/restart/30000) so Windows auto-retries on boot failure.

psagarriga · 3 months ago

Same for me. The sandbox won't start on Desktop Application, which blocks reading of PDF, xlsx, and docx files.
Several days now.

goostreej · 3 months ago

Adding a data point as another Windows Cowork user affected by this.

Environment

Windows 11
Claude desktop, Cowork mode
Max subscriber ($100/mo tier)

Symptoms

Bash returned today May 14th: Workspace unavailable. The isolated Linux environment failed to start. You can still use file tools directly.
Persisted across every sessions over roughly two weeks
File tools (Read/Write/Edit) continued to work throughout
Support ticket filed — no first-touch response after 3 days

Current state (May 14, 2026)

Bash started successfully today on first try, no client-side changes on my end
Claude Status page shows elevated error rates resolved on May 13, which appears to correlate with the recovery
No targeted fix called out in May 2026 release notes that I can find

Treating this as recovery, not a confirmed fix, in case it regresses. Would appreciate confirmation from engineering on whether this was a targeted fix vs. server-side incident recovery vs. partial rollout — the distinction matters for whether affected users should expect stability.

yavannadil21 · 2 months ago

The same happens for me 😢
Version 1.11847.5 (9692f0)
Steps suggested by Fable doesn't help 😢

rlewisfr · 2 months ago

The same happens for me 😢 Version 1.11847.5 (9692f0) Steps suggested by Fable doesn't help 😢

Ok, I was having the same problems. Gemini and I worked through it, then I asked for a post mortem. Might help you?

<head>

From Gemini<o:p></o:p>

1. What the Problem Was<o:p></o:p>

The issue was a two-stage failure that completely locked
the application out of its local execution engine:<o:p></o:p>

<ul style='margin-top:0in' type=disc>
<li class=MsoNormal style='mso-list:l3 level1 lfo1;tab-stops:list .5in'>The
Trigger: A background application update deleted
your existing local virtual machine disk environment (rootfs.vhdx) to make
room for a fresh version match.<o:p></o:p></li>
<li class=MsoNormal style='mso-list:l3 level1 lfo1;tab-stops:list .5in'>The
Network Block (net::ERR_QUIC_PROTOCOL_ERROR):
When the application tried to download the new 9+ GB virtual environment,
your local network or firewall choked on the default QUIC (UDP)
protocol. This caused the massive download to repeatedly drop mid-stream,
fail, and reset back to 0 bytes.<o:p></o:p></li>
<li class=MsoNormal style='mso-list:l3 level1 lfo1;tab-stops:list .5in'>The
Windows Kernel Hang (connect ENOENT): Because the
network kept failing, zombie background processes from the application got
stuck in system memory. These stuck processes aggressively locked a hidden
Windows communication pipe (cowork-vm-service). Even after the network
issue was bypassed, the application interface couldn't talk to its own
engine because the pipeline was marked as "busy."<o:p></o:p></li>
</ul>

2. What Steps Actually Fixed the Issue (see
below for details)<o:p></o:p>

We systematically cleared the pipeline from the network
layer down to the Windows kernel:<o:p></o:p>

<ul style='margin-top:0in' type=disc>
<li class=MsoNormal style='mso-list:l1 level1 lfo2;tab-stops:list .5in'>Forcing
TCP Mode (--disable-quic): We used an elevated
PowerShell command to launch the app while explicitly disabling the
problematic QUIC protocol. This forced the download to run over standard,
rock-solid TCP, allowing the full 9.42 GB virtual machine
environment to completely download without dropping packets.<o:p></o:p></li>
<li class=MsoNormal style='mso-list:l1 level1 lfo2;tab-stops:list .5in'>Terminating
Zombie Background Tasks: We used administrative
commands (Stop-Process) to forcefully kill the lingering, hidden
background worker tasks that were keeping the local communication pipes
hostage.<o:p></o:p></li>
<li class=MsoNormal style='mso-list:l1 level1 lfo2;tab-stops:list .5in'>Flushing
the Named Pipes: We ran a file-system script to completely
remove the dead loopback address (\\.\pipe\cowork-vm-service), clearing
the track so the fresh application instance could establish a clean
handshake.<o:p></o:p></li>
<li class=MsoNormal style='mso-list:l1 level1 lfo2;tab-stops:list .5in'>Ensuring
Core Pro Services Were Live: We verified that Windows
11 Pro's native Host Compute Service (vmcompute) and Host
Network Service (hns) were actively running and configured to start
automatically.<o:p></o:p></li>
</ul>

3. Recommendations for the Future<o:p></o:p>

If the application ever hangs on startup or gets trapped in
a "Loading/Downloading" loop again, run through this quick checklist:<o:p></o:p>

Rule 1: The "Clean Close" Checklist<o:p></o:p>

If the app acts up, standard window-closing usually leaves
background tasks alive. Always do a hard reset:<o:p></o:p>

<ol style='margin-top:0in' start=1 type=1>
<li class=MsoNormal style='mso-list:l5 level1 lfo3;tab-stops:list .5in'>Go
to your Windows system tray (bottom-right corner near the clock).<o:p></o:p></li>
<li class=MsoNormal style='mso-list:l5 level1 lfo3;tab-stops:list .5in'>Right-click
the app icon and select Quit.<o:p></o:p></li>
<li class=MsoNormal style='mso-list:l5 level1 lfo3;tab-stops:list .5in'>If
it still won't open, fire up Task Manager (Ctrl + Shift + Esc) and
forcefully end any background processes named Claude, vmmem, or wsl.<o:p></o:p></li>
</ol>

Rule 2: Keep the TCP Shortcut in Your Back
Pocket<o:p></o:p>

Now that the heavy lifting is done, your default launcher
works fine. However, whenever the application pushes a massive structural
update down the line, it might try to use the broken QUIC protocol again.<o:p></o:p>

<ul style='margin-top:0in' type=disc>
<li class=MsoNormal style='mso-list:l4 level1 lfo4;tab-stops:list .5in'>If
you see an update freezing, don't fight it—just launch the app using your
custom PowerShell / TCP Mode shortcut to let the update pull down
smoothly over TCP.<o:p></o:p></li>
</ul>

Rule 3: The Quick Pipe Flush (If it says
"Connecting..." endlessly)<o:p></o:p>

If the app gets stuck attempting to link to its workspace,
open PowerShell (Admin) and paste this single command to drop any jammed
communication links:<o:p></o:p>

PowerShell<o:p></o:p>

Stop-Process -Name "Claude" -Force -ErrorAction
SilentlyContinue; [System.IO.Directory]::GetFiles("\\.\pipe\") |
Where-Object { $_ -like "cowork" } | ForEach-Object { Remove-Item
$_ -Force }<o:p></o:p>

Relaunch the app immediately after, and it should snap
straight to green!<o:p></o:p>

Detailed Codes for Step 2:<o:p></o:p>

<o:p> </o:p>

1. The Emergency TCP Launcher (Bypass Network
Drops)<o:p></o:p>

When a major app update drops and the default launcher gets
stuck downloading or throws a QUIC_PROTOCOL_ERROR, use this method to force the
download over standard TCP.<o:p></o:p>

The Permanent Shortcut Target Code<o:p></o:p>

<ol style='margin-top:0in' start=1 type=1>
<li class=MsoNormal style='mso-list:l7 level1 lfo5;tab-stops:list .5in'>Right-click
an empty space on your desktop and select New ➔ Shortcut.<o:p></o:p></li>
<li class=MsoNormal style='mso-list:l7 level1 lfo5;tab-stops:list .5in'>In
the location field, paste the following code exactly:<o:p></o:p></li>
</ol>

Plaintext<o:p></o:p>

powershell -WindowStyle Hidden -Command "Start-Process
'shell:AppsFolder\Claude_pzs8sxrjxfjjc!Claude' -ArgumentList
'--disable-quic'"<o:p></o:p>

<ol style='margin-top:0in' start=3 type=1>
<li class=MsoNormal style='mso-list:l2 level1 lfo6;tab-stops:list .5in'>Click
Next, name it Claude (TCP Mode), and click Finish.<o:p></o:p></li>
</ol>

2. Zombie Background Task Termination<o:p></o:p>

If the app window is closed but the underlying
virtualization framework is frozen in memory, it will block new instances from
starting. Run these commands to completely clear the cache and kill the
processes.<o:p></o:p>

The Command Line Clean-Out<o:p></o:p>

Open PowerShell as an Administrator and execute the
following block to forcefully terminate all hidden application components:<o:p></o:p>

PowerShell<o:p></o:p>

# Force-kill all primary user interface processes<o:p></o:p>

Stop-Process -Name "Claude" -Force -ErrorAction
SilentlyContinue<o:p></o:p>

<o:p> </o:p>

# Force-kill the underlying virtual machine memory
allocation process<o:p></o:p>

Stop-Process -Name "vmmem" -Force -ErrorAction
SilentlyContinue<o:p></o:p>

<o:p> </o:p>

# Force-kill any hanging sub-tasks tied to the container
architecture<o:p></o:p>

taskkill /F /IM "wsl*" /T<o:p></o:p>

Clearing the Hard Lock File<o:p></o:p>

Electron applications drop a hidden lock file on your
storage drive when they crash. If this file isn't deleted, the app thinks an
instance is already running.<o:p></o:p>

<ol style='margin-top:0in' start=1 type=1>
<li class=MsoNormal style='mso-list:l0 level1 lfo7;tab-stops:list .5in'>Press
Win + R, paste the following path, and hit Enter:<o:p></o:p></li>
</ol>

Plaintext<o:p></o:p>

%USERPROFILE%\AppData\Roaming\Claude\<o:p></o:p>

2. Locate the file named LOCK (it has no file
extension) and Delete it.<o:p></o:p>

<o:p> </o:p>

---<o:p></o:p>

<o:p> </o:p>

## 3. Flushing the Named Pipes Script<o:p></o:p>

If you see the error connect ENOENT <unc>\cowork-vm-service, it means a dead background worker process is
holding the local communications channel hostage. <o:p></o:p>

<o:p> </o:p>

Open PowerShell as an Administrator and run this script
to clear the track:<o:p></o:p>

<o:p> </o:p>

```powershell<o:p></o:p>

# Check for and forcefully delete any hidden communication
links tied to Cowork<o:p></o:p>

[System.IO.Directory]::GetFiles("\\.\pipe\") |
Where-Object { $_ -like "cowork" } | ForEach-Object { Remove-Item
$_ -Force }<o:p></o:p>

What to look for:<o:p></o:p>

<ul style='margin-top:0in' type=disc>
<li class=MsoNormal style='mso-list:l6 level1 lfo8;tab-stops:list .5in'>If
the script runs and returns completely blank, the channel is
successfully cleared.<o:p></o:p></li>
<li class=MsoNormal style='mso-list:l6 level1 lfo8;tab-stops:list .5in'>If
it returns an error saying the object "does not exist",
the pipe is already clear and open.<o:p></o:p></li>
</ul>

4. Virtualization Service Verification Steps<o:p></o:p>

The local engine cannot run if Windows 11 Pro's core
hypervisor services are misconfigured or stopped.<o:p></o:p>

The Quick PowerShell Health Check<o:p></o:p>

Open PowerShell as an Administrator and paste this
query to see the exact state of the required Windows Pro backend
infrastructure:<o:p></o:p>

PowerShell<o:p></o:p>

Get-Service hns,vmcompute,SharedAccess,winnat | Select
Name, Status, StartType<o:p></o:p>

The Target Baseline (What you should see)<o:p></o:p>

Your terminal output must match this baseline for the
application to function:<o:p></o:p>

The Remediate Commands (If a service is
stopped/wrong)<o:p></o:p>

If vmcompute or any companion service shows as Stopped,
run these commands sequentially in your Administrator PowerShell window to
repair their startup parameters and force-start them:<o:p></o:p>

PowerShell<o:p></o:p>

# Reconfigure the core Host Compute Service to always load
on Windows boot<o:p></o:p>

Set-Service vmcompute -StartupType Automatic<o:p></o:p>

<o:p> </o:p>

# Force-start the services to bring the local engine online
immediately<o:p></o:p>

Start-Service vmcompute -ErrorAction SilentlyContinue<o:p></o:p>

Start-Service hns -ErrorAction SilentlyContinue<o:p></o:p>

</body>

</html>

github-actions[bot] · 1 month ago

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

[BUG] Cowork mode - Linux bash sandbox never starts on Windows (Workspace unavailable since first launch)

Preflight Checklist

What's Wrong?

Description

Error Message

Windows Event Viewer Logs

Troubleshooting Steps Completed (all failed)

Additional Notes

What Should Happen?

Error Messages/Logs

Steps to Reproduce

Claude Model

Is this a regression?

Last Working Version

Claude Code Version

Platform

Operating System

Terminal/Shell

Additional Information

14 Comments

✅ RESOLVED — Solution for Windows users

Related Claude Code issues

Browse by topic