[BUG]: Filesystem tools treat HTTP(S) URLs as local relative paths and return misleading errors.

[KurobaKaitou]

Summary

When a model passes an HTTP(S) URL to a filesystem tool such as read, the local filesystem provider treats the URL as a relative filesystem path.

On Windows, the URL is joined to the session working directory and rewritten into a Windows-style path. The resulting not found error contains only this rewritten path, which is misleading to both users and agents.

This was originally reported downstream in:

anywhere-labs/dsh-desktop#701

After tracing the Desktop composition, the affected filesystem tools and provider appear to be owned by the upstream Harness packages rather than by Desktop.

Reproduction

On Windows, use a session whose working directory is, for example:

C:\Users\Work_01\Documents\Workspace

Call the read tool with:

{
  "file_path": "https://raw.githubusercontent.com/Tencent/WeMM-Embedding/main/README.md"
}

Actual result

Error: cannot read "C:\Users\Work_01\Documents\Workspace\https:\raw.githubusercontent.com\Tencent\WeMM-Embedding\main\README.md": not found

The original URL has been interpreted as a relative local path:

• https:// becomes https:\
• Forward slashes become Windows path separators
• The result is joined to the session working directory

The error does not explain that filesystem tools only accept local paths.

Expected result

At minimum, filesystem tools should detect URI-like inputs such as http:// and https:// before local path resolution and return a clear error, for example:

read only accepts local filesystem paths; use the web/fetch tool for HTTP(S) URLs

The error should preserve the original input.

I do not think the filesystem provider should transparently perform a network request, because that would mix filesystem and network capabilities and their permission boundaries.

Suspected root cause

@deepseek-ai/dsh-fs-local currently resolves the model-supplied string directly:

const displayPath = resolve(cwd, path)

The read tool then reports absence using the resolved displayPath, so the original input is no longer available in the final error.

write, edit, and read_image appear to use the same filesystem resolution path and should be audited together.

glob is also worth auditing for URL-shaped path inputs. However, it uses the ripgrep subprocess path rather than the same fs-local resolution path, so it may require separate validation.

Platform scope

The misleading transformation is especially visible on Windows, but the semantic issue is not necessarily Windows-only. POSIX path resolution can also interpret https://... as a relative local path.

Suggested change

1. Add shared validation for URI-like inputs before local path resolution.
2. Reject at least http:// and https:// with an actionable filesystem-tool error.
3. Preserve the original caller-provided value in the error.
4. Add coverage for read, write, edit, and read_image.
5. Audit glob and grep separately because they use the search/subprocess implementation.

Would the maintainers prefer this validation to live at the model-facing filesystem tool boundary or in the local filesystem provider?

[argszero]

Verified the report against the alpha.1 tree (HEAD cd5ef81) — the reproduction is accurate, and to answer the open design question: the guard belongs in the provider, with a distinct error code that the tool boundary translates into the actionable message.

Confirmed at source.

• resolveLocalTarget(cwd, path) (packages/fs/fs-local/src/fsio.ts:146-148) does exactly const displayPath = resolve(cwd, path), which is what rewrites https://raw... into the joined, separator-mangled path on Windows (and a misleading relative path on POSIX).
• The provider's resolve() (packages/fs/fs-local/src/index.ts:108) is the single entry for read/write/edit/read_image and list — listDirectory operates on the already-resolved target.displayPath (index.ts:160), so all five surface ops share this one choke point.
• The FsError taxonomy already supports a distinct code: FsError extends HarnessError with codes like FS_NOT_FOUND / FS_ABORTED (packages/fs/fs/src/types.ts:196), and fs-local already throws typed codes at fsio.ts:147/:157 etc.

Why provider, not tool boundary. The provider is the security-relevant layer: the fs sandbox / permission policy sits below it, and nothing URL-shaped should ever reach path resolution or policy evaluation. Rejecting at resolveLocalTarget (or a shared URI precheck it calls) covers all five ops in one place, keeps the invariant "a filesystem target is never a URL" for every consumer of fs-local (tools, host APIs, plugins), and matches your "no transparent network request" instinct. The tool boundary then only maps the code — e.g. FS_URL_NOT_LOCAL → "read only accepts local filesystem paths; use the web/fetch tool for HTTP(S) URLs" — preserving the original input in the message.

One extra surface to audit: lstat. It does its own raw resolve(opts?.cwd ?? this.config.cwd, path) (index.ts:142) rather than going through resolveLocalTarget, so a URL passed to lstat would bypass a guard placed only at resolveLocalTarget. The clean fix is a small shared assertLocalPath(path) used by both sites (and by resolveLocalTarget itself), which also keeps the error shape identical across ops. Your "audit glob/grep separately" note is correct — those use the ripgrep subprocess path, not fs-local.

[KurobaKaitou]

Verified the report against the alpha.1 tree (HEAD cd5ef81) — the reproduction is accurate, and to answer the open design question: the guard belongs in the provider, with a distinct error code that the tool boundary translates into the actionable message.

Confirmed at source.

• resolveLocalTarget(cwd, path) (packages/fs/fs-local/src/fsio.ts:146-148) does exactly const displayPath = resolve(cwd, path), which is what rewrites https://raw... into the joined, separator-mangled path on Windows (and a misleading relative path on POSIX).
• The provider's resolve() (packages/fs/fs-local/src/index.ts:108) is the single entry for read/write/edit/read_image and list — listDirectory operates on the already-resolved target.displayPath (index.ts:160), so all five surface ops share this one choke point.
• The FsError taxonomy already supports a distinct code: FsError extends HarnessError with codes like FS_NOT_FOUND / FS_ABORTED (packages/fs/fs/src/types.ts:196), and fs-local already throws typed codes at fsio.ts:147/:157 etc.

Why provider, not tool boundary. The provider is the security-relevant layer: the fs sandbox / permission policy sits below it, and nothing URL-shaped should ever reach path resolution or policy evaluation. Rejecting at resolveLocalTarget (or a shared URI precheck it calls) covers all five ops in one place, keeps the invariant "a filesystem target is never a URL" for every consumer of fs-local (tools, host APIs, plugins), and matches your "no transparent network request" instinct. The tool boundary then only maps the code — e.g. FS_URL_NOT_LOCAL → "read only accepts local filesystem paths; use the web/fetch tool for HTTP(S) URLs" — preserving the original input in the message.

One extra surface to audit: lstat. It does its own raw resolve(opts?.cwd ?? this.config.cwd, path) (index.ts:142) rather than going through resolveLocalTarget, so a URL passed to lstat would bypass a guard placed only at resolveLocalTarget. The clean fix is a small shared assertLocalPath(path) used by both sites (and by resolveLocalTarget itself), which also keeps the error shape identical across ops. Your "audit glob/grep separately" note is correct — those use the ripgrep subprocess path, not fs-local.

Thanks for confirming the issue and clarifying where the validation should live.

A shared provider-level check, with a distinct error code translated into an actionable message at the tool boundary, makes sense. The additional lstat path is also a good catch.

We will track the downstream impact in:

anywhere-labs/dsh-desktop#701

If an upstream issue or PR is opened for the fix, please link it here so we can track the Harness release that includes it.

[denial123789]

I wrote up an independent operator runbook for this boundary: https://github.com/sandbaseai/deepseek-harness-handbook/blob/main/docs/en/troubleshooting/filesystem-url-as-path.md

It keeps the recommendation narrow: reject http/https before local path resolution, preserve the original input, and route retrieval to a web/fetch capability rather than making fs-local perform network I/O. The guide also calls out the separate lstat path and treats glob/grep as an audit item, not assumed coverage.

[nokkies]

A branch carrying a fix for this is available, based directly on cd5ef8148 (0.1.2-alpha.1) so it applies with git am -3:

https://github.com/nokkies/dsh-upstream-patches/tree/fix/url-in-filesystem-path

It adds assertFilesystemPath, which rejects any scheme:// before the call reaches the filesystem and names the remedy: http/https point at web_fetch, any other scheme asks for a filesystem path. It carries FS_NOT_FOUND so retry/permission/UI routing is unchanged, and is wired at all three path entries including read (which remediateFsError does not cover, and where a URL most plausibly arrives).

Windows shapes that carry a colon are covered by tests: C:\work\a.txt never produces ://, and UNC paths have no scheme.

Offered as-is, no attribution wanted. Take, adapt, or ignore it freely.

[liyangbing]

A useful way to keep this fix bounded is to reject URI-shaped input before any cwd resolution, while preserving the original value for the diagnostic. Treat the capability split as part of the contract: filesystem tools accept local paths; a web/fetch tool owns HTTP(S) retrieval.

For a regression probe, run the same sanitized http:// and https:// values through read, write, edit, and read_image; then audit glob/grep separately because they use different subprocess/search paths. Success evidence should show (1) no network request from the filesystem provider, (2) an actionable error naming the web/fetch route, and (3) the original URI retained in the error. Keep a disposable workspace and do not “fix” the symptom with transparent downloading.

I documented the boundary, Windows/POSIX behavior, expected evidence, and recovery path here: https://sandbaseai.github.io/deepseek-harness-handbook/filesystem-url-as-path.html

Verified against the rc.2 source revision b150a551 on 2026-08-29. This is an independent community runbook, not an official DeepSeek AI statement.