path must not use a Windows network or device namespace

Error message

path must not use a Windows network or device namespace

What it means

On Windows, `validatePathPlatform` rejects paths that use Windows network or device namespaces — UNC (`\\server\share`), device paths (`\\?\`), or NT-object prefixes (`\??\`). The path-safety policy cannot reason about where these open, so they are refused outright. This error is wrapped with the flag name by safePath on the strict tier.

Solutions

Map the network share to a drive letter and use a local absolute path (e.g. `net use Z: \\server\share` then `Z:\dir\file`).
Copy the file into an allowed local root (cwd, %TEMP%, or the user's files directory) and use that path.
Strip the `\\?\` extended-length prefix, keeping an ordinary absolute path.

Example fix

// before (Windows)
lark-cli drive upload --file \\srv\share\report.pdf
// after
net use Z: \\srv\share
lark-cli drive upload --file Z:\report.pdf

Defensive patterns

Strategy: validation

Validate before calling

// Go: reject UNC / device namespace shapes before passing the path
normalized := strings.ReplaceAll(p, "/", `\\`)
if strings.HasPrefix(normalized, `\\`) || strings.HasPrefix(normalized, `\??\`) {
    return fmt.Errorf("map the share to a drive letter or use a local path: %q", p)
}

Prevention

Use mapped drive letters instead of \\server\share paths.
Strip \\?\ prefixes captured from Win32 tooling output.
Stage files to a local temp directory when the source/destination is a network share.

When it happens

Trigger: Passing `--file \\server\share\doc.pdf`, `--output \\?\C:\dir\file`, or a forward-slash variant `//server/share` on Windows; also paths copied from Win32 API calls with the extended-length prefix.

Common situations: Downloading to or uploading from a network share in an enterprise environment; scripts that copied extended-length paths from `robocopy` output; tooling that emits `\\?\` to bypass MAX_PATH.

Related errors

AI-assisted analysis of larksuite/cli@7fd6ef3c07 (2026-09-04). Data as JSON: /api/errors/f231a45b12170b69. Report an issue: GitHub.

Appendix: source

Thrown at internal/vfs/localfileio/path_local_windows.go:20

// SPDX-License-Identifier: MIT

//go:build windows

package localfileio

import (
	"fmt"
	"path/filepath"
	"strings"
)

// validatePathPlatform rejects Windows path shapes the policy cannot reason
// about: network/device namespaces (UNC, \\?\) and NTFS alternate data
// streams (a colon anywhere past the drive letter would address a hidden
// stream on an otherwise-allowed file).
func validatePathPlatform(path string) error {
	if isWindowsNonLocalNamespace(path) {
		return fmt.Errorf("path must not use a Windows network or device namespace")
	}
	cleaned := filepath.Clean(path)
	// A drive-relative path ("C:foo") carries a volume but is not absolute: it
	// resolves against that drive's own current directory, so the location it
	// names is not the one this validation can see. It is also how the stream
	// check below would be slipped, since "C:" is stripped as the volume and
	// the remaining "foo" holds no colon.
	if filepath.VolumeName(cleaned) != "" && !filepath.IsAbs(cleaned) {
		return fmt.Errorf("path must not be drive-relative; give a full path or a path without a drive letter")
	}
	if strings.Contains(cleaned[len(filepath.VolumeName(cleaned)):], ":") {
		return fmt.Errorf("path must not address an NTFS alternate data stream")
	}
	return nil
}

func validateLocalInputPlatform(path string) error {
	if isWindowsNonLocalNamespace(path) {

View on GitHub (pinned to 7fd6ef3c07)