DeepSeek Harness WSL UNC: write fails with EIO Win32 1

A DeepSeek Harness workspace that can read, list, and search but never write is not a permissions problem; admission and the file backend disagree about what "supported filesystem" means. Admission checks only path spelling, so UNC passes; writes assume NTFS semantics, and GetFileSecurityW returns ERROR_INVALID_FUNCTION on the 9P share, surfaced as EIO (Win32 1). According to the discussion, the reporter reproduced this in the desktop app, and community members reviewed the workspace and fs-local sources (discussion).

Read, write, and terminal each report differently in a DeepSeek Harness UNC workspace

The same workspace behaves differently across four kinds of operations; record them by operation before deciding whether this is admission or backend capability.

1. Open \\wsl.localhost\Ubuntu\home\you\proj as a workspace in the desktop app. Expected: it loads.
2. Ask the model to edit an existing file. Expected: Error: GetFileSecurityW EIO (Win32 1): \\wsl.localhost\...
3. Ask the model to create a file. Expected: FS_IO_ERROR with cannot write in the message, and the code is not ENOTSUP.
4. Open a terminal tab in the workspace. Expected: it lands in cmd.exe and reports that UNC paths are not supported, then gives up the current directory.
5. Read an ordinary file and list a directory. Expected: both succeed. Time one stat with Measure-Command; expected about 17,000 microseconds per file versus about 86 microseconds inside WSL.
6. Access a symlink such as /etc/os-release or /lib. Expected: ENOENT, because the share exposes Linux symlinks as reparse points Windows cannot resolve.

A successful read does not mean the workspace is usable; it only means the 9P read path is sufficient.

Why admission lets UNC through: it only rejects two root forms

The check is meant to reject relative drive paths and root-relative paths; UNC is simply not on its rejection list, which is not the same as being supported. The predicate reviewed by the community is:

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\, which matches neither rejected form, so the guard passes. Only realpathNormalize runs afterward; there is no filesystem capability check. Admission and the backend share no information about what the volume supports, so failure can only appear at the first operation.

Why writes must fail: GetFileSecurityW has no 9P equivalent

Publishing a file on Windows copies the source DACL and then replaces the target; both steps assume security descriptors work, and 9P provides neither. The same DACL failure also shows up in Windows sandbox commands, covered in Windows ACL sandbox command failures. The chain:

1. fs-local/src/win32.ts:92-97 calls GetFileSecurityW(nativePath, DACL_SECURITY_INFORMATION, ...).
2. When it returns 0, the code throws win32Error('GetFileSecurityW', api.getLastError(), path), and 9P supplies error code 1.
3. Lines :122-132 of the same file publish through ReplaceFileW, which is also not a 9P primitive.
4. Creating a new file goes through the link(temp, dest) guard; 9P rejects hard links with ENOTSUP, but the fs layer wraps it as a generic FS_IO_ERROR and leaves the errno only in the message text.
5. Conclusion: DACL-copy publishing is meaningless on this kind of share. This is not a missing row in a mapping table.

Path 1: reject UNC at DeepSeek Harness admission

The most honest fix is to say "unsupported" at adoption time, so users learn the path is a dead end before they see EIO. Steps:

1. Add a root check to the win32 branch of paths.ts: treat root.startsWith('\\\\') as UNC. Expected: the predicate rejects UNC roots as unsupported.
2. Return an explicit "unsupported workspace type" error on a match, rather than returning false and silently falling into another branch. Expected: the caller receives an explicit error instead of a silent fallback.
3. Cover four spellings, \\wsl.localhost\, \\wsl$\, \\?\UNC\, and \\server\share\; add each as a workspace. Expected: all four are rejected.
4. Regression-test an NTFS drive path. Expected: adding and read/write behavior are unchanged.

Accept the cost: UNC workspaces that currently read and list will be rejected too, including intentional network shares.

Path 2: keep DeepSeek Harness admission, fail the first write with a capability error

If you do not want to remove the existing read-only use, keep admission but move the failure to the first write and describe it as "this filesystem is unsupported" rather than "an API failed". Steps:

1. Probe the target volume's capability at the write entry point, or recognize error code 1 from GetFileSecurityW as "unsupported". Expected: the write path knows whether the volume supports DACL calls before it starts.
2. Throw an error that names the filesystem type, for example "UNC/9P workspaces do not support DACL-copy publishing; use a drive letter or run inside WSL". Expected: the message names the filesystem and a workable alternative.
3. Add a persistent notice to these workspaces saying they are read-only. Expected: the workspace shows a read-only notice in the UI.
4. Retest: reads, listings, and search remain available; writes fail immediately with readable text. Expected: reads still work and writes fail with the new message.
5. Include the 17,000-microsecond stat cost in the notice so users do not wait on large directories. Expected: the notice explains the per-file latency cost.
6. Store a "read-only workspace" flag in the workspace record so the notice survives a restart instead of depending on session memory. Expected: the notice reappears after restart.

Path 3: map a drive letter and retest DeepSeek Harness DACL copy

A drive mapping solves "admission does not recognize it" and "cmd.exe does not accept UNC", but the share underneath is still 9P, so write support must be tested rather than assumed. Steps:

1. Confirm the WSL distribution is running: wsl -l -v. Expected: state is Running.
2. Run net use W: \\wsl.localhost\Ubuntu\home\you\proj /persistent:yes. Expected: the command completes successfully.
3. Add W:\ as a workspace. Expected: admission passes because the root is now a drive root.
4. Edit an existing file. Expected one of two outcomes: it succeeds, meaning DACL calls work through this mapping; or it still fails with EIO (Win32 1), meaning the underlying semantics did not change, so return to Path 1 or Path 2.
5. Create a new file. Expected: no more FS_IO_ERROR; an ENOTSUP still means hard links are unavailable.
6. Open a terminal on W:\. Expected: no UNC-unsupported message.
7. Run net use W: /delete and reopen the workspace. Expected: a clear error rather than a directory that quietly stops working.

A drive mapping is not a master key: it bypasses path-spelling checks, not filesystem capability.

How to choose in DeepSeek Harness: does the workspace need writes?

The three paths divide on one question: will this workspace be written to?

One last note: a DSH plugin such as dsh-plugin-wsl-env uses a resident agent that takes over files and shell, but that is not a built-in host capability, so upgrades and compatibility are your responsibility (per the discussion).

Whichever path you choose, ask "does this workspace support writes?" before adoption. That is much cheaper than discovering EIO on the first edit.

Source: Discussion #10260.