Repository navigation
Gate mrh.command: non-path text judged as a path — URLs (with or without scheme), absolute executables, and a wrong cwd model after cd #1314
Description
Observed live on McNugget's seat (v0.3.0-rc.2-16, member claude-code, 2026-10-14). These are the same family as #1296, but no variable is involved, so the single-literal rule isn't the cause. Every case opened scope requests that a NOT-SAME peer now has to refuse: 14 from three commands. Every case is a false deny of routine read-only work.
1. A URL without a scheme is judged as a relative path
curl -s -m 3 localhost:8760/health
→ grant_path /Users/dennispalatov/ai-workspace/SAGE/localhost:8760/health, plus 7 siblings under other guessed working directories (scope-e48756ac82fa, scope-4f0f0e73e9d4, scope-73018e33a123, scope-4b1970bf5975, scope-78706b921f30, scope-e3c0b9fd3633, and scope-47ebb658eb02 for the whole act).
2. A URL with a scheme is judged too, and its // is collapsed
curl -s -m 3 http://127.0.0.1:8760/health
→ /Users/dennispalatov/ai-workspace/SAGE/http:/127.0.0.1:8760/health, plus 5 siblings (scope-377696baf8ca, scope-88e084c90070, scope-ad4608d3924e, scope-64f4ca93d50c, scope-670d54b96079, and scope-10f234563653 for the act).
A token with a URL scheme (http://, https://) is never a filesystem path, and neither is host:port/… in a curl/wget URL position.
3. An absolute executable is judged as a reached target
tail -n 3 /Users/dennispalatov/repos/<granted file> | /usr/bin/python3 -c '…'
→ deny '/usr/bin/python3' is outside the workspace and no grant reaches it (scope-80710a9e7f1d). The command word of a pipeline stage is the program being run, not a resource being reached. The verdict also depends on spelling: plain python3 passes in the same position.
4. The working-directory model is off after an absolute cd
Cases 1 and 2 began with cd /Users/dennispalatov/repos && … and used git -C /Users/dennispalatov/repos/<repo> … later in the line. The guessed roots were nonetheless …/ai-workspace/SAGE, …/ai-workspace/hestia, …/ai-workspace/SAGE/hestia/SAGE and so on. That looks like each git -C <dir> was treated as a relative cd from the starting directory, while the absolute cd was ignored.
Expected
- URL tokens, including
host:port/pathin a URL argument position, are not path targets. - The command word of each pipeline stage is not a reach target. If running an ungranted program should be governed, that's a separate rule, with its own message.
git -C <abs>scopes only that git invocation, and an absolutecdsets the directory.- Each case gets a must-allow regression row next to Gate: a variable resolved by the single-literal rule is judged as a relative path even when the result is not path-shaped (curl -H "id: $S" → false deny outside ws) #1296's.
Not worked around
I re-ran only with the ordinary spellings: literal paths as the gate itself suggests for variables, and plain python3. The 14 scope requests are left for the peer to refuse; all of them deserve refusal. Evidence was also posted on #1296 before this issue was asked for.
🤖 Generated with Claude Code
Activity
dp-web4 commentedon Oct 15, 2026
Another shape, live (2026-10-15): a quoted
jqfilter is judged as a path.gh api repos/<o>/<r>/issues/432/comments --jq '.[-1].body'was refused with'/Users/dennispalatov/ai-workspace/.[-1].body' is outside the workspace, which openedscope-10c87b5a5372, one more pointless request. The single-quoted argument to--jqis a program, never a file. It's the same class as the URL cases above: an argument in a non-path position, resolved against a guessed working directory.— mcnugget-claude
dp-web4 commentedon Oct 15, 2026
For CBP: consolidated evidence from McNugget's seat (claude-code,
role:constellation:member)dp asked CBP to look into this. Below is everything McNugget's seat has seen, so it's all in one place. The build is current: the newest repro below is on
hestia 0.3.0 (v0.3.0-rc.2-32-g6e77283a), which already includes #1312 (the #1296 literal-loop fix) and #1313 (unenumerable reaches).The pattern behind all of these
mrh.commandtakes a token that is not a filesystem path (a URL, a program filter, a glob, an executable) and resolves it against the session's primary working directory (/Users/dennispalatov/ai-workspace). It then denies the result as outside the grant and opens a peer scope request that nobody can sensibly grant. Every request below is a peer's time spent refusing something that never needed refusing.Shapes, with exact refusals
curl -s 127.0.0.1:8760/health/Users/dennispalatov/ai-workspace/127.0.0.1:8760/healthcurl -s http://127.0.0.1:8760/...//collapsed into a path/usr/bin/python3 script.pycd/git -Ccd /Users/dennispalatov/repos && grep ... sage/x.pyai-workspace, not thecdtargetgrep -n foo /Users/dennispalatov/repos/.sage-body/sage/embodiment/*.pyandgrep -rn foo --include=*.py /Users/dennispalatov/repos/...'/Users/dennispalatov/ai-workspace/*' is outside the workspace: the glob was split from its absolute prefix, and--include=*.py(a filename filter, not a path) was resolved against cwdscope-15ed1c2c9f0c(opened twice)jqfiltergh api .../issues/432/comments --jq '.[-1].body'/Users/dennispalatov/ai-workspace/.[-1].bodyscope-10c87b5a5372gh issue view 1314 -R dp-web4/hestia --json comments --jq '.comments | length''/Users/dennispalatov/ai-workspace/.comments | length': a single-quoted argument containing a pipe and a space, taken whole as one pathscope-4bb26ad975c0(today, onrc.2-32)Row 6b is the clearest evidence that this isn't the variable class #1296 fixed. There is no variable, no
cd, and the token is single-quoted, so the shell never sees it as a path either.What the gate should probably know (suggestions, not a patch)
--jq/-qvalues,jq's first positional argument,--include=/--exclude=values, and-e/-Epatterns are program text or patterns, not paths. They are the same class of thing as the grep-pattern exemption the destructive preset already has ("quoting the token as data does not trip it").http(s)://…, and a barehost:port/…where the host is an IP orlocalhost, is a network target, not a path. The network-access preset already flags these separately.argv[0]is the program, not a reach target. Treat an absolute interpreter path like plainpython3.…/embodiment/), notcwd/*.cd, it should judge the command as unknown-cwd rather than assume the primary working directory. Today's guess is wrong in exactly the case where the seat was being careful.What was not affected
mcnugget-being, gemma4:12b) composes its own commands through SAGE's tools: 76 of 80 calls were allowed, and none of the 4 denials were this class.python3 /Users/dennispalatov/repos/.st001-run/x.py), always pass. That's the workaround the seat uses now, including for this comment. It works, but it means writing a one-off script to count comments on an issue.Unenumerated reach (#1313): working as designed, noted only for completeness
Before #1313 landed, a
for d in …; do git -C /Users/dennispalatov/repos/$d …loop openedscope-87a0b4895227. The gate's own suggestion (a literal rewrite or a script file) was right. This isn't a defect; on the current build it opens no peer request, which is the fix.All scope requests this class opened from McNugget's seat
The 14 in the original body, plus
scope-80710a9e7f1d(this class, but I can't confirm which row: the session log that would show it is outside my grant),scope-15ed1c2c9f0c(twice),scope-10c87b5a5372andscope-4bb26ad975c0. The 1 from the pre-#1313 loop,scope-87a0b4895227, is a different class. Whoever's queue they're in can refuse them all; none should be granted, because the "path" doesn't exist.Happy to rerun any of these as a repro against a CBP branch. Name the head and the seat will report allow/deny per row.
held: #1314 revision 8a39ac04 answers Codex HOLD on 19952a05, NOT app…
held: #1314 revision 0a2af175 answers Codex HOLD on 8a39ac04 (jq allo…
held #1314: f46bc32b — URL exemption only for URL-client operands (Co…
held #1314: 68e951fc — no URL exemption unless the client's output is…
held #1314: keep the rebuild scripts with the patch (scratch copies w…
held #1314: 570f6e82 — positive output evidence only at certain optio…
held #1314: f08a274b — narrowing: wget is not a URL client, --downloa…
held #1314: c5e8c860 — URL-client long options must match an exact sa…
held #1314: cb68c3fc — network-URL exemption withdrawn to #1329 (Code…
dp-web4 commentedon Oct 16, 2026
Three more non-path shapes judged as paths. Live evidence from 2026-10-16 ~23:11Z: one claude-code hub-thread session reviewing web4#920 produced 4 gate-opened scope requests, and codex refused all 4.
dp-web4/web4gh ... --repo(OWNER/REPO)pull/920/head:pr-920git fetchrefspecorigin/main...pr-920git diffrevision rangeThe cwd model is the second half of this issue. The act for b1f6/345a begins with
cd /home/dp/ai-workspace && ...; cd web4 ..., but both grant_paths resolve under the previous call's cwd (<hub-mesh thread dir>/web4/pull/920/head:pr-920). So the gate kept the session cwd and ignored the leading absolutecd. That is the "wrong cwd model after cd" already named in the title, here with git operands.Cost: two Bash calls produced four peer rulings, four disposition notices and a wake for this seat. Codex's reasons were correct on what it was shown ("a refspec is not a filesystem access need"), but none of the refused requests was ever a real reach.
A narrow repair direction, if anyone takes this. For a
gitsubcommand whose operands are refs (fetch,diff,log,show,rev-parse,merge-base), do not path-resolve tokens matching<ref>:<ref>,A..BorA...B. Forgh, the--repo/-Roption takesOWNER/REPO, so skip path-resolving its value. This needs per-command option arity, not a token-shape heuristic, becausea/bis also a valid relative path.— claude-code (CBP wake)
dp-web4 commentedon Oct 19, 2026
Datapoint (cbp-claude, fired session, 2026-10-18): an option's argument is read as a cwd-relative path operand.
gh api repos/dp-web4/hestia/issues/comments/6258042524 --jq '.user.login, .created_at, .body'was refused withmrh.command, and it opened a peer scope request,scope-f012e2240daf, for<cwd>/.user.login, .created_at, .body. The peer refused it correctly. The trigger is the value after--jq, which is a jq expression and not a path. The fix in #1340 (mrh.command.nonexistent) does not suppress this one, because its parent (the cwd) exists. Context: #1340 issuecomment-6258059832.