Windows: whole drive (e.g. D:\) cannot be used as a Workspace — blank title and session.create fails with EPERM

[Nanoda16]

Windows: a whole drive (e.g. D:\) cannot be used as a Workspace — blank title and session.create fails with EPERM

Summary

On Windows, picking a drive root (e.g. D:\) as a Workspace produces two failures:

1. The Workspace is created but its title is blank (the sidebar shows an empty name).
2. Creating a new session in that Workspace fails silently — startSession logs new session failed: to the console and nothing happens in the UI.

Both are caused by special-casing of Windows volume roots that the current code does not handle.

Environment

• OS: Windows
• Packages: @deepseek-ai/dsh-workspace 0.1.0-rc.6, @deepseek-ai/dsh-host-apiproxy 0.1.0-rc.6
• Reproduction: pick D:\ in the directory picker as the Workspace, then click the "+" (New Session) button on that Workspace.

Steps to reproduce

1. In the Web GUI, open the workspace picker and select a whole drive (D:\) as the Workspace directory.
2. Observe the new Workspace row in the sidebar: the name is blank (empty string).
3. Click the New Session ("+") button on that Workspace row.
4. No new session appears. Browser console shows new session failed: ....

Expected behavior

• The Workspace should display a sensible name for the drive root (e.g. D:\).
• A new session should mount and open in the drive-root Workspace.

Actual behavior

• title is stored as "" and rendered verbatim → blank Workspace name.
• Session creation rejects server-side → client-side startSession swallows the error with console.warn.

Root cause

1. Blank title — path.basename returns "" for a Windows drive root

node:path on Windows:

path.basename("D:\\") // => ""  (empty string)

The Workspace registry derives the display title from the basename:

• packages/workspace/workspace — createCanonical: const workspaceName = title ?? basename(canonical);
• packages/workspace/workspace — history bootstrap: title: basename(group.path),

For a drive root both produce "", which is stored in the durable record and shown verbatim by the sidebar (the client's workspaceLabel(cwd) fallback exists only for ungrouped/search rows, not for the Workspace header).

2. session.create fails — fs.mkdir(cwd, { recursive: true }) throws EPERM on a volume root

In packages/host/apiproxy — ensureSession:

try {
    await mkdir(cwd, { recursive: true });
} catch (error) {
    throw new Error(`failed to ensure project directory "${cwd}": ${String(error)}`, { cause: error });
}

On Windows, fs.promises.mkdir("D:\\", { recursive: true }) rejects with EPERM: operation not permitted, mkdir 'D:\' even though the directory already exists: for a volume root, CreateDirectoryW returns ERROR_ACCESS_DENIED rather than ERROR_ALREADY_EXISTS, and Node only swallows EEXIST in recursive mode. The RPC then returns code: "internal", the client's startSession catches it and only logs to the console, so the UI appears to do nothing.

Verified with Node 22 on Windows:

> await fs.mkdir('D:\\', { recursive: true })
EPERM: operation not permitted, mkdir 'D:\'

Suggested fix

1. Fall back to the full path when the basename is empty (root-aware title):

const workspaceName = title ?? (basename(canonical) || canonical);
// and in bootstrap:
title: basename(group.path) || group.path,

2. Tolerate EPERM in the mkdir guard when the target already resolves to a directory (Windows volume root already exists):

try {
    await mkdir(cwd, { recursive: true }).catch(async (error) => {
        if (!(error && typeof error === "object" && error.code === "EPERM" &&
              await stat(cwd).then((info) => info.isDirectory(), () => false))) throw error;
    });
} catch (error) {
    throw new Error(`failed to ensure project directory "${cwd}": ${String(error)}`, { cause: error });
}

(stat is already imported in that module.)

A ready-to-apply patch against the published 0.1.0-rc.6 bundles is attached as fix-bundles-0.1.0-rc.6.patch; the corresponding TypeScript sources are the two locations above.

Notes

• POSIX is unaffected: mkdir("/", { recursive: true }) succeeds (EEXIST is swallowed) and / has a non-empty basename.
• The same basename edge case can affect the title of the drive root in the ungrouped fallback path; worth a client-side workspaceLabel reuse as well.

[XyTT2N2bTc]

补充证据（同一根因在 C:\ 上复现，2026-08-14 排查）：

1. 契约不一致：packages/client/connection/tests/fixture.client.spec.ts 断言 "A basename-less path serves as its own title"（/ → title '/'），但真实实现从未满足该契约 —— fixture 是假 API，掩盖了差异。
2. 前后端不一致：客户端 intentName()（packages/client/runtime/src/client/workspaces/workspace.ts）已有 fallback（C:\ → 预览显示 C:），而服务端没有 —— picker 预览与最终落库 title 不一致，创建成功后列表刷新变空白。
3. schema 无同等保护：workspace.create 请求 schema 只要求 path: z.string()（根路径可通过）；而 workspace.rename 明确拒绝空 title（refine(trim !== '')）——空 title 只在创建路径无防线。
4. 测试缺口：packages/workspace/workspace/tests/workspace.spec.ts 的 fixture 与实现同样用 basename(path)，无根路径/盘符根用例；建议补盘符根（C:\）与 POSIX 根（/）创建用例，断言 title 非空。
5. 最新源码确认：主分支 createCanonical 目前仍为 title ?? basename(canonical)（无 fallback），与本文报告一致，问题在最新代码仍存在。
6. Node 行为确认：path.basename("C:\\") === ""（win32）；path.basename("/") === ""（posix）——与 D:\ 同一根因。

修复建议与正文一致：服务端 basename(canonical) || canonical + 补测试；UI 侧可对空 title 回退显示 path（Rows.tsx / WorkspacePicker.tsx），让历史脏数据保持可达。