Repository navigation
[Bug] dsh-memory-plugin uri-guard blocks write/edit when file content mentions a viking URI #4188
Description
Activity
- moved this from Backlog to In progress in OpenViking project
on Aug 23, 2026 Independent confirmation with fresh real-world numbers — still hitting this on
@openviking/dsh-memory-plugin0.2.1 with dsh 0.1.1-rc.1 (profile: web, Windows 11).The repro scope is wider than write/edit. The whole-args fallback also blocks:
grepwithpatterncontaining the literal — I only had to search for viking:// in your own plugin source in order to read the guard code, and the search itself was denied. Searching for a string that you need to read cannot be a path misuse.bashinvocations whose command string contains it.editwherenew_stringmerely mentions it.
Real impact in our session: while writing local audit docs (markdown result files under a fleet repo) that cite memory paths like viking://user/default/peers/..., three separate local
write/editcalls on normal Windows paths were denied purely because the content mentions the URI — the file was never created. Every doc/README/code comment that needs to reference a memory path hits this wall. (This very comment was drafted as a local file and the draft write was denied too; we had to route it around the guard.)Small refinement of the suggested fix: instead of "argument contains URI", test "the path-meaning of the argument resolves to a viking:// prefix":
- keep the path-like key scan (
filePath,file_path,path,uri,target_uri) as-is; - drop the whole-args recursive fallback;
- for
pattern(grep regex/glob) and shellcommand, deny only when the value starts with viking:// (or a quoted path prefix), not when the substring appears in body text.
A simple opt-out flag (
uriGuard: falseconfig /OPENVIKING_URI_GUARD=0env) would also let teams keep strict-by-default without blocking legitimate documentation.Both the original issue and this confirm the guard's intent — blocking viking URIs as local paths — is sound; it is purely the matching granularity that needs to move from "appears anywhere in the arguments" to "is the target path". Happy to test a patch if one lands.
- added a commit that references this issue
on Aug 26, 2026
Summary
@openviking/dsh-memory-plugin(0.2.1) registers atools/pre-executeguard that blocks DeepSeek Harness filesystem/shell tools from receiving viking URIs. The guard scans the entire tool-arguments object, so a localwrite/editwhose content merely mentions a viking URI (e.g. documentation text like "viking://user/default/") is denied with:Repro
writetool withfile_path= any normal local path andcontentcontaining the substring "viking://..." (e.g. "viking://user/default/").Control: same call without "viking://" in the content succeeds.
Root cause
shared/uri-guard.mjs->findVikingUri(args):filePath,file_path,path,uri,target_uri,pattern) - good;findVikingUriInValue(args), which recursively scans every argument value, includingcontent(write),new_string(edit),command(bash),pattern(grep).The regex then matches the URI inside the file content, and the guard denies the call.
Suggested fix
Scan only path-like keys and drop the whole-args fallback (or gate the fallback behind a config flag). The intent - blocking a viking URI as a path argument - is fully preserved by the keys loop.
Environment