directory-picker-browse: New-folder errors show invalid payload for host.createDirectory because the UI drops rpcError.details.issues

[zhanglunet]

Summary

In the browse directory picker, typing/pasting an absolute path into the New folder name field surfaces invalid payload for host.createDirectory to the end user. The actionable text the schema already produces (host.createDirectory requires a single non-blank path segment name) is transported correctly but dropped by the picker UI.

Reported by a non-technical Windows user of a product built on dsh; the message told them nothing about what was wrong or what to do.

All three packages at 0.1.0-rc.7. Electron host on Windows 10/11 x64.

Reproduction

1. Open the browse directory picker (@deepseek-ai/dsh-host-directory-picker-browse).
2. Click New folder.
3. Enter an absolute path instead of a single name, e.g. D:\Projects\demo.
4. Click Create.

Observed: red inline text invalid payload for host.createDirectory.
Expected: something like "Enter a folder name only — to create it somewhere else, use Edit path."

Where it is lost

The payload is correctly rejected, with a specific reason:

dsh-host-apiproxy/lib/types/api/host.schema.js:44-45

}).refine(payload => payload.name.trim() !== '' && payload.name !== '.' && payload.name !== '..'
    && !/[/\\]/.test(payload.name),
    { message: 'host.createDirectory requires a single non-blank path segment name' });

dsh-host-apiproxy/lib/index.js:4857-4862 — the generic message, with the zod issues preserved under details:

const payload = route.schema.safeParse(message.payload);
if (!payload.success) return errorResponse(message.rpcId, {
    code: "bad-request",
    message: `invalid payload for ${method}`,
    details: { issues: payload.error.issues }
});

So the proxy does the right thing: details.issues[0].message carries the readable sentence.

dsh-client-ui-directory-picker-browse/lib/client.js:113-116 — the picker's failure-text helper reads only message:

/** Failure text: the Host business message when typed, else the throw's text. */
if (error instanceof DirectoryBrowseError) return error.rpcError.message;
return error instanceof Error ? error.message : String(error);

details.issues is never consulted, so the specific reason is discarded at the very last step before display.

Suggested fixes

1. Use the detail that is already there. When rpcError.code === 'bad-request' and rpcError.details?.issues?.length, prefer the first issue's message over the generic one. That alone turns the above into host.createDirectory requires a single non-blank path segment name — still developer-flavoured, but at least it names the actual constraint.

2. Validate in the field, before the round trip. The New-folder input knows it wants one segment (browser.folderName). Rejecting / and \ inline, with a hint pointing at the existing Edit path affordance (browser.editPath), fixes the real user problem: they were not trying to name a folder oddly, they were trying to go somewhere else. Pasting a full path into the only text field on screen is a very natural mistake when the target is on another drive.

3. Optional — say so in the label. browser.untitledFolder as placeholder reads as "type a name here"; an explicit hint ("name only") would cost nothing.

Note on a related constraint

dsh-host-directory-picker-browse/lib/index.js:225 uses non-recursive mkdir, so multi-level creation is not possible even with a corrected message. That is a reasonable default, but it means a user targeting D:\A\B must create A, enter it, then create B. Worth mentioning in the same hint.

---

Filed from the same downstream product as
#4330 (the Windows native-picker segfault). That one is confirmed fixed for us by switching the win32 backend to browse; this report is about the browse backend's own UX.

[ChangkeunJ]

Diagnosis holds, and the helper is unchanged on master (0.1.1-rc.2). DirectoryBrowser.tsx hasn't been touched since 2026-08-12, so it predates your rc.7:

// packages/client/ui-directory-picker-browse/src/client/DirectoryBrowser.tsx:67
function failureText(error: unknown): string {
  if (error instanceof DirectoryBrowseError) return error.rpcError.message
  return error instanceof Error ? error.message : String(error)
}

Your refs are into the published lib/ bundles, so for anyone reading along in source: the generic message comes from the shared unary dispatcher, packages/host/apiproxy/src/fetch/handler.ts:182-185:

const payload = route.schema.safeParse(message.payload)
if (!payload.success) {
  return errorResponse(message.rpcId, { code: 'bad-request', message: `invalid payload for ${method}`, details: { issues: payload.error.issues } })
}

That's the only place in the repo emitting that string, so every unary method's schema rejection reads identically. Worth pairing with the fact that failureText has 4 call sites in the dialog (468, 514, 632, 637) and 3 of them are listing failures, so anything you put in that helper is dialog-global, not create-specific. Harmless in practice, since hostListDirectoryRequestSchema is just { path: z.string().optional() } and the UI can't make it fail, but worth knowing before editing it.

One correction, in your favour: details isn't optional, so the ?. in your suggestion 1 isn't needed. packages/host/apiproxy/src/api/rpc.ts:105:

export type RpcError = {
  [C in RpcErrorCode]: { code: C; message: string; details: RpcErrorDetailsMap[C] }
}[RpcErrorCode]

with 'bad-request': { issues: ZodIssue[] } on line 33, and the wire error schema carrying details.issues at rpc.schema.ts:35. error.rpcError.code === 'bad-request' narrows details to that record for free, no cast. It really is a 2 line change.

I'd still not ship that as the fix, for a reason that isn't in the report. The dialog's copy is localized, with zh and en dictionaries registered in src/client/index.ts, and the active locale follows the browser: packages/client/locale/src/client/index.ts resolves detectBrowserLocale() ?? FALLBACK_LOCALE, and FALLBACK_LOCALE is 'en' (line 98). So for a zh reader the dialog is Chinese while rpcError.message is server English, and suggestion 1 drops host.createDirectory requires a single non-blank path segment name untranslated into it. Already true of the listing failures, so not a regression, but your suggestion 2 is the one that can go through t().

The field also already has the seam to hang it on, in 2 places, because Enter bypasses the button. Line 1032 is disabled={creatingFolder || folderDraft === null || folderDraft.trim() === ''} and line 604 inside confirmCreate is if (name.trim() === '') return. Both check blank only, which means . and .. reach the host and come back with the same generic message on any platform. That's your cheap falsifiable test: open New folder, type .., Enter. If you get invalid payload for host.createDirectory it's the refine path, nothing Windows or separator specific, and the inline check needs to cover . and .. as well as / and \.

The problem queued behind it: that predicate already exists twice, and deliberately.

// packages/host/directory-picker-browse/src/index.ts:308
if (name.trim() === '' || name === '.' || name === '..' || /[/\\]/.test(name)) {
  throw new DirectoryPickerError('directory-create-failed', join(parent, name), `"${name}" is not a single path segment`)
}

The comment above it says the wire schema also refuses these, but direct service consumers must hit the same fence. An inline UI check makes 3 copies with 3 different wordings, and you can't dedupe by importing the schema: packages/api/remotes/src/client/index.ts re-exports RpcError and friends as export type only ("the carrier's runtime values stay behind their own module edge"), and the client picker package's only dependency is clsx. So the duplication is structural rather than an oversight, and a patch should probably say that in a comment beside the new copy.

On the mkdir note, non-recursive is correct (await mkdir(target), line 315), but it doesn't make the message worse. Every other create failure already reads fine, because directoryError at api-proxy.ts:569 passes DirectoryPickerError straight through: EEXIST becomes directory-exists with ${target} already exists, everything else becomes directory-create-failed with cannot create ${target}: ..., and both arrive intact in rpcError.message. The generic text is specifically the zod-refine path, so I'd scope the fix that way rather than as "create errors are bad".

Workaround for your users today with no upstream change: the pencil zone on the path bar (browser.editPath) accepts a full path and navigates. Paste D:\Projects, Enter, then New folder and type demo. It only walks to directories that already exist, so for D:\A\B with neither present it's still create A, enter it, create B.