MXC 0.7 processContainer: granted filesystem paths unusable — absolute paths doubled to C:\C:\..., writes false-succeed

[samanthamsong]

Summary

On the Windows Node (MXC 0.7 processContainer backend, Bind Filter/BFS), folders granted as read/write in the sandbox settings page (e.g. Downloads, Documents) are unusable inside the container. Root cause appears to be a path-normalization bug, not a policy/allowlist choice. Writes report false success, risking silent data loss.

Environment

• Host: Windows Node paired to a WSL gateway (gateway has no /mnt/c; all FS work routes to node)
• Backend: Windows MXC 0.7 processContainer (wxc-exec.exe, Bind Filter/BFS)
• Sandbox settings: Downloads granted read/write

Verified, reproducible symptoms

1. Absolute-path doubling (100% repro): attrib "C:\Users\<user>\Downloads" returns Path not found - C:\C:\Users\<user>\Downloads. Same for Documents, Desktop, and C:\Windows. The backend prepends container root C:\ to already-absolute paths.

2. Granted folder, three different failures: for %USERPROFILE%\Downloads: if exist reports MISSING; echo x > ...\t.txt returns exit 0; type ...\t.txt returns "syntax is incorrect"; dir ... returns "Access is denied".

3. Relative write false-success: echo hi > rel.txt returns exit 0, but attrib rel.txt returns "Path not found" for the container CWD path.

4. PowerShell output swallowed: cmd /c echo HELLO works; powershell -NoProfile -Command "Write-Output 'X'" returns only DACL-recovery stderr, no stdout. Source appears to be wxc-host-prep.exe / filesystem_dacl.rs managing the \Device\Null descriptor and erroring with GetNamedSecurityInfoW: WIN32_ERROR(2) on its own temp dirs.

5. Hard timeout on \\?\-prefixed and forward-slash (C:/...) paths.

Config model (from wxc-exec.exe strings)

Keys: readwritePaths, readonlyPaths, deniedPaths, least_privilege_mode, containment. Filesystem is default-deny ("Paths are denied by default unless granted via readwritePaths or readonlyPaths"). Binary also carries a pwsh caveat ("add ... to readonlyPaths ... or upgrade to pwsh 7.7+") and a ReFS/Dev Drive warning ("Bind Filter (BFS) does not work correctly on ReFS volumes"). Intended behavior: granted folders go into readwritePaths and become usable. The defect is that they don't.

Root cause (hypothesis)

Path-normalization/prefix-join bug in the processContainer Bind Filter: already-absolute C:\... paths get re-rooted against the container root (C:\C:\...), and granted mounts aren't registered for stat/read even when writes are redirected. Net: readwritePaths grants never resolve inside the container.

Impact

• Granted folders (Downloads/Documents) silently inaccessible.
• Writes return exit 0 but data isn't retrievable at the expected path: silent data-loss risk.
• Agents can't distinguish "file absent" from "path mangled"; PowerShell node work returns no output.

Requested fixes

1. Stop re-rooting already-absolute C:\... paths (fix C:\C:\... doubling).
2. Make readwritePaths/readonlyPaths grants actually stat/list/read/write inside the container.
3. Make writes to unmounted paths fail loudly instead of exit 0.
4. Fix DACL-recovery noise so PowerShell stdout returns like cmd.
5. Handle \\?\ / forward-slash paths without hanging.
6. Confirm settings-page grants are written into MXC readwritePaths/readonlyPaths and surface active mounts.

Repro (single-line cmd on node; MXC 0.7 rejects CR/LF in commands)

1. attrib "C:\Users\<user>\Downloads" - observe C:\C:\... in error.
2. echo x > "%USERPROFILE%\Downloads\t.txt" (exit 0), then type / dir same path - syntax error / access denied.
3. echo hi > rel.txt then attrib rel.txt - write ok, stat "Path not found".
4. cmd /c echo HELLO vs powershell -NoProfile -Command "Write-Output 'X'" - cmd works, powershell stdout swallowed.

[clawsweeper]

Codex review: keeping this open for maintainer follow-up; there is still a little grit to resolve. Reviewed August 10, 2026, 8:25 PM ET / August 11, 2026, 00:25 UTC.

Summary
Keep open for explicit maintainer handling: the report targets the security-sensitive MXC runtime boundary, while current source correctly forwards folder grants but cannot disprove the reported Windows MXC 0.7 backend failure. Likely related people: Caleb Eden (high confidence) and Barbara Kudiess (medium confidence).

Reproducibility: no. The report supplies concrete commands, but this read-only Linux review cannot execute the required Windows MXC/AppContainer runtime; the repository's own real-runtime tests are explicitly host-gated.

Ways to help us reproduce this

• Add a screenshot or short recording showing the behavior.
• Add expected vs actual behavior.

Maintainer decision needed

Question	Recommendation
Should affected MXC 0.7 process-container hosts remain enabled while an upstream runtime defect is investigated, or should OpenClaw add a fail-closed compatibility guard until grants are proven reliable?	Reproduce, then add a narrow guard or update: Run the formal MXC proof on an affected Windows host and use the resulting failure to select an SDK update or a fail-closed compatibility guard.

Why: The adapter currently emits the intended grants, but choosing an SDK update, runtime disablement, or host fallback changes the containment and availability posture for existing users.

Next step
The suspected failure is in a pinned third-party sandbox runtime and any fallback or disablement decision changes the containment boundary.

Security
Needs attention: The report concerns a sandbox filesystem boundary and possible false-success writes, but this review has not independently verified a bypass or runtime defect.

Review details

Best possible solution:

Establish a failing real MXC 0.7 Windows proof for a Settings-page Downloads or Documents grant, then either update the bundled runtime or add a fail-closed compatibility guard and regression coverage so writes never report success without retrievable data.

Do we have a high-confidence way to reproduce the issue?

No. The report supplies concrete commands, but this read-only Linux review cannot execute the required Windows MXC/AppContainer runtime; the repository's own real-runtime tests are explicitly host-gated.

Is this the best way to solve the issue?

Unclear. Source already maps the settings grants into MXC configuration, so a core change should follow a failing real Windows MXC proof rather than assume a path-normalization defect in the adapter.

AGENTS.md: found and applied where relevant.

Remaining risk / open question:

• A compatibility workaround that disables or falls back from MXC could weaken the containment boundary if it permits uncontained execution.
• The existing MXC runtime matrix does not independently cover the affected well-known folders or the reported absolute-path and PowerShell cases on the exact Windows host/runtime.

Codex review notes: model internal, reasoning high; reviewed against 582a44713860.

Label changes

Label changes:

• add impact:data-loss: The report describes successful write exit codes followed by absent or unreadable data at the expected path.
• add issue-rating: 🦪 silver shellfish: Current issue advisory state selects this label.
• add clawsweeper:no-new-fix-pr: Current issue advisory state selects this label.
• add clawsweeper:needs-maintainer-review: Current issue advisory state selects this label.
• add clawsweeper:needs-product-decision: Current issue advisory state selects this label.
• add clawsweeper:needs-security-review: Current issue advisory state selects this label.

Label justifications:

• P1: Reported false-success writes can break real Windows-node agent workflows and require prompt validation.
• impact:data-loss: The report describes successful write exit codes followed by absent or unreadable data at the expected path.
• impact:security: The behavior concerns the default-deny filesystem-grant boundary of a sandboxed command runtime.

Evidence reviewed

Security concerns:

• [medium] Validate filesystem-grant false success on a real MXC host
  If a granted-path write returns success without readable host data, callers cannot safely rely on the sandbox result; validate the exact bundled runtime before changing fallback behavior.
  Confidence: 0.78

What I checked:

• Settings-to-policy mapping: Current policy construction sends Documents, Desktop, Downloads, and custom folder choices to the readwritePaths or readonlyPaths lists; this supports the report's claim that the intended contract is usable granted folders, but does not independently validate the MXC backend. (src/OpenClaw.Shared/Mxc/MxcPolicyBuilder.cs:79, 582a44713860)
• Config emission: The config builder preserves policy readwritePaths, adds only the per-invocation scratch directory, and forwards the requested working directory without adding a C:\ prefix itself. (src/OpenClaw.Shared/Mxc/MxcConfigBuilder.cs:73, 582a44713860)
• Existing runtime coverage is incomplete for this report: The MXC-gated integration matrix asserts custom read-write writes and reads, read-only reads, and denied read-only writes, but it uses temporary folders rather than the Settings-page Downloads/Documents paths reported here. (tests/OpenClaw.Shared.Tests/Mxc/MxcCommandRunnerIntegrationTests.cs:203, 582a44713860)
• Dependency boundary: The tray project pins the externally supplied @microsoft/mxc-sdk runtime to 0.7.0 and packages its wxc-exec executable, so the reported process-container behavior depends directly on that runtime contract. (src/OpenClaw.Tray.WinUI/OpenClaw.Tray.WinUI.csproj:110, 582a44713860)
• Required real-host proof path: Repository guidance says hosted CI lacks a working MXC/AppContainer runtime and requires validate-mxc-e2e.ps1 on an MXC-enabled Windows machine for this surface. (docs/WINDOWS_NODE_TESTING.md:172, 582a44713860)
• Area provenance: Current history identifies Caleb Eden's commit as the latest change touching the inspected MXC configuration and integration-test area; current main contains it. (src/OpenClaw.Shared/Mxc/MxcConfigBuilder.cs:73, c9608c8e54e6)

Likely related people:

• Caleb Eden: Current MXC configuration and integration-test history most recently records Caleb Eden's change in this area. (role: recent area contributor; confidence: high; commits: c9608c8e54e6; files: src/OpenClaw.Shared/Mxc/MxcConfigBuilder.cs, tests/OpenClaw.Shared.Tests/Mxc/MxcCommandRunnerIntegrationTests.cs)
• Barbara Kudiess: The exec-approval V2 history includes MXC command-path work, making this a related routing contact if the gateway-to-node request shape contributes. (role: adjacent exec-policy contributor; confidence: medium; commits: 4806eaac7c24; files: src/OpenClaw.Shared/Mxc/MxcConfigBuilder.cs, src/OpenClaw.Shared/Mxc/MxcCommandRunner.cs)

How this review workflow works

• ClawSweeper keeps one durable marker-backed review comment per issue or PR.
• Re-runs edit this comment so the latest verdict, findings, and automation markers stay together instead of adding duplicate bot comments.
• A fresh review can be triggered by eligible @clawsweeper re-review comments, exact-item GitHub events, scheduled/background review runs, or manual workflow dispatch.
• PR/issue authors and users with repository write access can comment @clawsweeper re-review or @clawsweeper re-run on an open PR or issue to request a fresh review only.
• Maintainers can also comment @clawsweeper review to request a fresh review only.
• Fresh-review commands do not start repair, autofix, rebase, CI repair, or automerge.
• Maintainer-only repair and merge flows require explicit commands such as @clawsweeper autofix, @clawsweeper automerge, @clawsweeper fix ci, or @clawsweeper address review.
• Maintainers can comment @clawsweeper explain to ask for more context, or @clawsweeper stop to stop active automation.

[clawsweeper]

Maintainer investigation update against current origin/main at bc518f7bd1581c69ffc7967ba2ce301b8e2f777a:

• The Hub-side path projection still appears correct. MxcPolicyBuilder resolves Documents, Desktop, Downloads, and custom-folder selections and places each unchanged path into the requested read-only/read-write list (source).
• MxcConfigBuilder copies those policy lists unchanged, adds only the per-invocation scratch directory to readwritePaths, filters configured denies, and does not prepend C:\ to granted paths (source).
• The existing real-runtime matrix has the right observable contract: write and read the granted path inside MXC, verify the output file exists at the requested host path, and verify a read-only write remains absent (source). An exit code alone is intentionally not accepted.
• The PowerShell/empty-output portion of the original report has since been addressed separately by merged PR fix(mxc): PowerShell fails in the Windows node sandbox #1147 through the explicit Windows UI API opt-in. This investigation remains focused on granted-path resolution and false-success writes.

Native proof could not be completed in this run:

• Azure Crabbox provisioning failed before a lease was created because the subscription's approved LowPriorityCores quota was below the requested Windows VM size.
• Brokered AWS did create native-Windows lease cbx_19cf22b3a598 (pearl-lobster, run run_ce051d7c51ff), but the stock image is Windows Server build 20348. That OS cannot exercise the MXC 0.7 processContainer/AppContainer path required by this issue. The image also lacked the repository's Node/npm prerequisites, but installing those would not make this OS MXC-capable.
• The attempted lease release is currently timing out at the Crabbox coordinator; cleanup has been requested repeatedly and remains an infrastructure follow-up.

Therefore I am not claiming that the upstream MXC backend is proven to be the root cause, and I am not opening a speculative Hub fix or weakening containment/host-fallback policy. The next required step is a real native MXC-capable Windows repro on this exact head that records: requested grant path, emitted readwritePaths/readonlyPaths, in-container list/read/write output, observable host path/content, and a denied-write control. If that fails while the emitted path is unchanged, we will have evidence for a source-backed microsoft/mxc report and can decide whether a narrow fail-closed Hub guard is warranted.