Two remote-execution-world gaps in dsh-base (tool-fs-search rg path; fs-sandbox modes), with fixes

[weijiafu14]

While building a third-party remote-sandbox provider suite against deepseek-harness@0.1.0-rc.6, I hit two spots where dsh-base assumes the execution world is host-local. Both are invisible with the local providers and only surface once ctx.fs/ctx.subprocess point at a remote sandbox — exactly the portability the capability seams are designed for ("pointing them at a remote sandbox moves Bash, PTY, and LSP with them"). Reporting them together since they're the same class of issue, each with a concrete fix.

1. tool-fs-search hardcodes the host ripgrep path

runRipgrep in packages/fs/tool-fs-search/src/search-core.ts builds argv as:

argv: [await resolveRgPath(), '--no-config', ...argv]

resolveRgPath() returns the absolute path of the host's @vscode/ripgrep binary, handed straight to ctx.subprocess.spawn as argv[0] — it never goes through resolveExecutable. tool-fs-search is mounted in the shipped dsh-base bundle, but any remote execution world has no such host path, so every glob/grep fails with a spawn error. The examples/headless-agent/e2b.cordis.yml overlay happens to avoid it by not mounting the plugin, so it's easy to miss.

Suggested fix: resolve the search binary through ctx.subprocess.resolveExecutable('rg', ...) (falling back to the packaged path for the local provider), so the executable is located in whatever execution world is mounted. A provider can then ship rg in its sandbox image.

2. Sandbox permission modes have no remote semantics

dsh-fs-sandbox's SandboxedFileSystem extends LocalFileSystem, and writableRoots() in packages/sandbox/sandbox/src/roots.ts canonicalizes policy.workspaceRoot together with the host's /tmp and os.tmpdir() via the host realpath. In a remote world those are the wrong filesystem's paths, so read-only and workspace-write silently don't apply — the e2b example is forced to hardcode danger-full-access. The two model-visible escalation modes effectively can't be honored by a remote fs provider today, with no warning.

Suggested fix: let a remote fs provider enforce the mode against its own execution-world paths (the seam already passes sandboxPolicy down to writeText/editText), and keep writableRoots()' host-/tmp mixing to the local backend.

Happy to open PRs for either if external contributions become welcome later — I understand the current stance. In the meantime I've worked around both in a provider suite (sidecar ships rg; the sidecar enforces the mode against sandbox paths). Thanks for the seam design — it made the remote world genuinely composable once these two host assumptions are handled.