[Bug] Workspace validation admits WSL UNC paths the file toolchain cannot serve

[Big-Dao]

Summary

packages/workspace/workspace/src/paths.ts:16-23 admits
\\wsl.localhost\<distro>\... as a workspace (the win32 check only requires
root !== '\\' && root !== '/'), but the file toolchain's Windows publication
path assumes NTFS primitives that the 9P share does not provide. The result is
a workspace that boots, reads, and then fails every write with misleading
errors.

Steps to reproduce

1. Open \\wsl.localhost\<distro>\home\<you>\proj as a workspace in desktop.
2. Ask the model to edit an existing file (any file).
3. Ask the model to create a new file.

Actual behavior

• Edit / overwrite an existing file: fails with EIO — the measured text
  is Error: GetFileSecurityW EIO (Win32 1): \\wsl.localhost\.... Root cause:
  fs-local's Windows publication copies the source DACL via
  GetFileSecurityW (packages/fs/fs-local/src/win32.ts:88-115), which on
  the 9P share returns Win32 error 1 (ERROR_INVALID_FUNCTION), then
  publishes via ReplaceFileW (win32.ts:122-134) — neither is a 9P
  primitive (packages/fs/fs-local/src/fsio.ts:622-647).
• Guarded create: publication uses link(temp, dest) (fsio.ts:633-638);
  the 9P share rejects hard links, so link returns ENOTSUP, which the fs
  seam wraps as its generic FS_IO_ERROR — the errno survives only in the
  message text (cannot write "<path>": …), not as the code.
• Reading and listing work for plain files and directories, over the 9P share,
  at roughly 200× the per-file metadata cost of the same tree from inside the
  distro: ~17 000 µs per stat against ~86 µs measured in-distro.
• Symlinked paths are the read-side exception: the share exposes a Linux
  symlink as a reparse point whose POSIX target Windows cannot resolve, so
  stat, realpath and read on /etc/os-release or /lib return ENOENT
  (the seam reports FS_NOT_FOUND). On Ubuntu /bin, /lib and
  /etc/os-release are symlinks, so read-only tooling that reaches for them
  fails as well — the breakage is not confined to writes.
• A terminal tab opened on the workspace lands in cmd.exe, which prints
  "UNC paths are not supported" and abandons the directory.

Expected behavior

Either:

1. the adoption path rejects \\wsl.localhost\... workspaces with a clear
   "not supported" signal, so users do not discover the limitation as
   EIO/FS_IO_ERROR mid-session; or
2. the toolchain serves these workspaces (a WSL provider family, comparable to
   how packages/ssh pairs fs/subprocess/sandbox remotes).

Note that (1) is not free: these workspaces read and list today, and admitting
the form is what lets a WSL-aware directory picker hand the registry a project
directory at all — an outright rejection would also stop setups that work now.
Accepting them read-only, behind a persistent banner, would remove the
misleading mid-session errors without that regression.

Notes

• The mismatch is between two modules: a lexical validator
  (workspace/src/paths.ts) and an NTFS-assuming implementation
  (fs-local/src/win32.ts). Nothing connects them, which is why the failure
  appears as per-operation I/O errors rather than an adoption-time signal.
• A third-party plugin exists that serves these workspaces:
  dsh-plugin-wsl-env is an incremental version of (2) — a resident-agent
  substrate for ctx.fs and shell execution, a root-plane filesystem that
  routes by coordinates, search-spawn rewriting, terminal handling and
  directory-picker integration, with the workspace identity kept as the UNC
  path. It is not complete: the @-completion traversal still reads the share
  through upstream's own node:fs walk, because the seam it would need does
  not exist yet. Happy to share measurements, traces, or probe scripts if
  useful for deciding between (1) and (2).

[PerryLink]

The predicate is exactly as you describe, and the asymmetry sits in the admission check rather than in the file backend.

packages/workspace/workspace/src/paths.ts:16-23:

if (platform !== 'win32') return posix.isAbsolute(path)
const root = win32.parse(path).root
return win32.isAbsolute(path) && root !== '\\' && root !== '/'

For \\wsl.localhost\Ubuntu\home\you\proj, win32.parse(path).root is \\wsl.localhost\Ubuntu\ — neither of the two rejected spellings — so the guard passes and realpathNormalize (:52-57) is the only thing that runs afterwards. The guard is doing what it was written for: rejecting drive-relative and root-relative spellings before realpath resolves them from cwd or the current drive. A UNC share root was simply not in the set of things it knew to reject, so "admitted" here means "not one of the two spellings we reject", not "we believe this is a normal fixed drive".

The write failures follow from that, and your two citations are the ones I would lead with:

• packages/fs/fs-local/src/win32.ts:92-97 — getFileSecurityW(nativePath, DACL_SECURITY_INFORMATION, ...) and, on a zero return, throw win32Error('GetFileSecurityW', api.getLastError(), path). On 9P that call is ERROR_INVALID_FUNCTION (1), which is the EIO (Win32 1) you measured.
• :122-132 — publication goes through replaceFileWin32 / ReplaceFileW, the same class of assumption.

So this is not an errno-mapping wart on top of a working copy; the DACL-copy publication path has no meaning on a share that does not implement those calls.

Where I would put the fix, and the tradeoff. Rejecting at admission is the honest place, because the alternative is teaching every fs-local publication path a second, untested fallback for a filesystem class the sandbox cannot fence either — the write grant edits the workspace root's security descriptor, which is the same family of API that fails here. A one-line test in that predicate, root.startsWith('\\\\'), rejects \\wsl.localhost\, \\wsl$\, \\?\UNC\ and \\server\share\ together.

The cost of that one-liner is that it also rejects UNC workspaces that today read and list fine, and any workspace reached through a network share on purpose. That is a product decision, not a regex decision, so the smaller change may be to keep admitting the path but fail create/first-write with a capability error that names the filesystem instead of the syscall — which is also what would have saved you the 200x-per-file read cost before you built anything on top of it.