[Bug]: WCore Bash sandbox rejects local Windows workspace path on USB-mounted drive after path is canonicalized to \\?\E:\...

[TorqueDog]

Platform

Windows

Wayland Version

0.11.2

Bug Description

In Wayland Desktop v0.11.2 on Windows, WCore Bash execution fails because the sandbox rejects the WCore temporary workspace path when it is represented as an extended-length Windows path.

The log shows repeated Bash failures:

sandbox child execution failed: fs allowlist path must be absolute and local (no UNC/device): \\?\E:\AIWorkspace\Wayland\wcore-temp-1782166469597

After repeated failures, WCore halts the turn:

runaway detected (failing_command x4); halting turn
Tool 'Bash' circuit open: too many recent failures, try again later

Steps to Reproduce

1. Run Wayland Desktop v0.11.2 on Windows.
2. Use a WCore workspace on a drive path such as:
   E:\AIWorkspace\Wayland
3. Start a WCore chat.
4. Ask WCore to inspect or run shell commands against the workspace.
5. Observe Bash tool failures.

Expected Behavior

The sandbox should accept normal local Windows paths, including paths internally canonicalized through Windows extended-length syntax.

Actual Behavior

The sandbox rejects:

\\?\E:\AIWorkspace\Wayland\wcore-temp-...

as a UNC/device path, even though it points to a local drive path.

Additional Context

The workspace is located at:

E:\AIWorkspace\Wayland

where E: is a high-speed USB-attached HDD, not a network share and not a flash drive. The log shows Wayland successfully creates the WCore temp workspace and symlinks built-in skills under this path:

E:\AIWorkspace\Wayland\wcore-temp-1782166469597\.wayland-core\skills

But when Bash runs, the sandbox rejects the same workspace after it appears as:

\\?\E:\AIWorkspace\Wayland\wcore-temp-1782166469597

with:

fs allowlist path must be absolute and local (no UNC/device)

This suggests the validator is treating all \\?\... paths as device/UNC paths, even when the path is an extended-length form of a local drive-letter path.

Suggested Fix

Normalize extended-length local Windows paths before applying the "absolute and local" allowlist check:

\\?\E:\AIWorkspace\Wayland\wcore-temp-...

should normalize to:

E:\AIWorkspace\Wayland\wcore-temp-...

Then validate that the normalized path is:

absolute
local
inside the configured workspace
not a UNC network share
not a symlink escape

If WCore intentionally does not support removable or USB-attached volumes, the validator should detect that explicitly and return a clear error such as:

Workspace is on a removable/external drive, which is not currently supported by the sandbox.

But the current error says "no UNC/device", and a USB HDD mounted as E: is not automatically a UNC/network path.

Add Windows tests for:

C:\path\workspace
E:\path\workspace
\\?\C:\path\workspace
\\?\E:\path\workspace

The \\?\<drive>:\... forms should pass as local paths. UNC paths like \\server\share\... should still fail unless explicitly allowed.

[FerroxLabs]

Routed → core — Windows non-C: drives. Bash sandbox rejects the WCore temp workspace on an E:/USB drive: "fs allowlist path must be absolute and local (no UNC/device): \?\E:...". The sandbox canonicalizes to an extended-length \\?\ path then rejects it as a device/UNC path → "runaway detected (failing_command x4); halting turn". Accept \\?\<drive>:\ extended-length local paths in the fs-allowlist validator. Windows-unusable cluster (#257/#262/#263).

[FerroxLabs]

Fixed in wayland-core@unreleased — pending release; will close when that ships.

[FerroxLabs]

Note updated: the engine fix is in shipped wayland-core@0.12.8 (replacing the earlier unreleased/main placeholder marker, which was not a real version and would never auto-close). This will auto-close once a desktop build bundles engine ≥ 0.12.8.

[github-actions]

Shipped in v0.11.3 (bundles wayland-core 0.12.8). Closing — update and reopen if you still hit this.