Cowork: sdk_install fails with EACCES when Claude Desktop is installed as MSIX (Store) package

Summary

On the MSIX (Microsoft Store) build of Claude Desktop, Cowork VM startup consistently
fails at the sdk_install step with permission denied when the guest tries to open
the SDK binary over virtiofs. The VM itself boots fine and add_plan9_shares completes;
only the SDK binary open fails.

Reproducibility: 100% (112/112 attempts since 2026-07-28).

Why this is not a duplicate of #37400. #37400 looks structurally identical (MSIX path,
virtiofs, sdk_install, SDK binary unreadable), but its root cause was Windows
Application Protected encryption on the Store path, and its error was
input/output error. This report differs on both points:

• The error here is permission denied (EACCES), not input/output error.
• cipher /c on the binary returns U (unencrypted) — Application Protected

encryption is not applied on this machine, so #37400's cause does not apply.

Neighbouring issues were also checked and rule out: #76094 (fails at sdk_install but with
"connection forcibly closed", a guest-side crash), #78373 (checksum mismatch, Linux — this
machine passes checksum verification), #77005 / #72685 (hang at Plan9 share mount — this
machine reaches add_plan9_shares completed), and #27801 (scoped to "VM service not
running" — the VM boots fine here).

Error

[VM:steps] add_plan9_shares completed        <- OK
[VM:steps] sdk_install started
[error] RPC error -1: failed to open SDK binary:
  open /mnt/.virtiofs-root/shared/c/Users/airwa/AppData/Local/Packages/
       Claude_pzs8sxrjxfjjc/LocalCache/Roaming/Claude/claude-code-vm/2.1.219/claude
  : permission denied

Environment

| | |
|---|---|
| OS | Windows 11 Home 10.0.26200 (build 26200) |
| Claude Desktop | 1.24012.9.0 (MSIX / Microsoft Store, package Claude_pzs8sxrjxfjjc) |
| SDK version | 2.1.219 |
| Virtualization (VMP / WSL / Hypervisor / CoworkVMService) | all Enabled / Running |

Key observation

The failure is confined to paths under the MSIX package container.

| Path location | sdk_install outcome |
|---|---|
| Inside MSIX container (%LOCALAPPDATA%\Packages\Claude_pzs8sxrjxfjjc\...) | 0 success / 112 fail |
| Outside the container | 370 success / 0 fail |

What was ruled out

Seven independent hypotheses were tested and eliminated:

1. Host-side NTFS ACL — granting permissions via 3 different approaches had no effect.
2. Service account — CoworkVMService already runs as LocalSystem; host ACL cannot

be the blocker.

1. Corrupt / missing VM bundle — re-downloading the bundle had no effect

(vm_boot completed is reached).

1. Stale SDK cache (#49495) — deleting claude-code-vm and re-fetching 262MB had no

effect. That issue reports exit code 1; this one is EACCES, a different symptom.

1. Corrupt binary — the host reads the file fine; ELF header 7F 45 4C 46 confirmed,

262.3MB, attributes Archive only (no NTFS compression, no EFS).
Encryption specifically ruled out: cipher /c reports U (unencrypted) on the
binary, both at the container path and at the relocated copy. This is the cause behind
#37400 and it does not apply here.

1. ACL persistence — the MSIX container re-applies its restrictive ACL on every

delete / re-fetch / app update, so manual grants never survive. Measured directly.

1. Container path itself (decisive test, 2026-08-03) — see below.

Decisive test: moving the SDK outside the container did NOT help

Since the container re-applies restrictive ACLs, the SDK directory was relocated out of
the container entirely and exposed at the original location via an NTFS junction:

• claude-code-vm moved to D:\ClaudeSDK (275,004,471 bytes, verified byte-identical)
• junction created: ...\Roaming\Claude\claude-code-vm -> D:\ClaudeSDK

ACL on the binary, read through the junction path, then matched the known-good profile:

| ACL entry | before (in container, failing) | after (outside, via junction) |
|---|---|---|
| AppContainer SID | (I)(F) | absent |
| DESKTOP\airwa | (I)(F) | absent |
| SYSTEM / Administrators | (I)(F) | (I)(F) |
| Authenticated Users | absent | (I)(M) |
| BUILTIN\Users | absent | (I)(RX) |

The host could read the ELF binary through the junction without issue.

Result: byte-for-byte the same permission denied, on the same path. Note the error
names the file (.../2.1.219/claude), not the directory, so the guest appears to traverse
into the directory and fail on opening the file.

This eliminates host-side NTFS permissions and container ACL inheritance as the cause. The
remaining candidate is how virtiofs maps / exposes this share to the guest.

Impact

Cowork is completely unusable on the MSIX build. There is no workaround available to the
user: a non-MSIX (.exe) build of Claude Desktop is not distributed, so "reinstall the
non-Store version" is not an option.

What would help

• Guidance on what determines the guest-side uid/gid/permission mapping for

/mnt/.virtiofs-root/shared/..., and whether MSIX-container paths are expected to work.

• If MSIX-container paths are known-unsupported, having the client place the SDK outside

the container by default (the junction workaround above shows the relocation itself is
tolerated — it is the mapping, not the location, that still fails).