Path protection false positives: substring matching matches 'logout/' for 'out/'

[log0u7]

Summary

Non-glob protected path entries are matched with a raw String.includes() against the full path. Any directory pattern whose name appears as a substring of another directory name triggers false positives. In particular, the built-in out/ rule matches every path under a user's /home/lOGOUT/ home directory, so legitimate file writes get blocked with DAMAGE_CONTROL_BLOCKED: Cannot write protected path "out/".

Environment

• opencode-damage-control: 1.5.0 (same code on current main)
• opencode: 1.18.25 (Linux, x86_64)
• OS: Ubuntu (Linux)

Real-world impact

opencode's plan mode writes plan files under either <repo>/.opencode/plans/<ts>-<slug>.md or ~/.local/share/opencode/plans/<ts>-<slug>.md. On a machine whose username is logout (/home/logout/...), every single plan-file write was rejected:

DAMAGE_CONTROL_BLOCKED: Cannot write protected path "out/"
Protection level: readOnly

Observed in practice: 9 consecutive blocked writes within 25 minutes (with the agent retrying after each block), all targeting paths like:

• /home/logout/.local/share/opencode/plans/1787824560041-hidden-comet.md
• /home/logout/projets/logout/worms/.opencode/plans/1787836297164-mighty-comet.md
• /home/logout/projets/gitlab/6admin.io/blog/.opencode/plans/1787824560041-hidden-comet.md

The only escape currently is disabling the rule entirely via paths.override: { "out/": "none" }, which removes a legitimate guardrail (writes to actual out/ build directories are no longer protected at all).

Root cause

src/patterns.ts, checkPathProtection() (non-glob branch):

// Non-glob: expand home and do prefix/substring matching
const expandedPath = p.path.replace('~', home);
if (filePath.includes(expandedPath) || filePath.includes(p.path)) {
    return p;
}

filePath.includes("out/") is a raw substring test: "…/home/lOGOUT/.local/…" contains out/, so the rule fires. The doc comment above the function says directory patterns should "check if filePath starts with or contains the dir", which reads as segment-boundary semantics, but the implementation is plain substring matching.

The same flaw exists in commandReferencesPath() (shell-command matching), so rm -rf ~/logout-proj/dist would also be flagged for the dist/ rule.

Affected built-in directory rules include at least: dist/, build/, out/, venv/, target/, .git/, .github/, plus any user-defined trailing-slash entry. Examples of colliding real-world directory names: logout/, about/, output-logs/ (contains out/? no, but pour/, thought/, without/ do), distance/, builders/, convenience/, objective/.

Minimal repro

import { checkPathProtection, DEFAULT_PROTECTED_PATHS } from "./dist/patterns.js";

// false positive: matches the built-in out/ rule
console.log(checkPathProtection("/home/logout/.local/share/opencode/plans/plan.md", DEFAULT_PROTECTED_PATHS));
// => { path: 'out/', level: 'readOnly' }

// expected: null

Proposed fix

For directory patterns (entries ending with /), match on path-segment boundaries instead of substrings:

if (p.path.endsWith('/')) {
    const dir = expandedPath.replace(/\/+$/, '');
    const normalized = filePath.replace(/\/+$/, '');
    if (normalized === dir || normalized.startsWith(dir + '/') || normalized.includes('/' + dir + '/')) {
        return p;
    }
    continue;
}

• "/home/logout/x" no longer matches out/ (no /out/ segment)
• "/project/out/a.js" and relative "out/a.js" still match
• literal entries without a trailing slash (~/.ssh, ~/.config/opencode) and glob entries (.env*, *.pem) keep their current semantics

The identical segment-boundary logic should be applied to commandReferencesPath() for non-glob entries.

Happy to open a PR with the fix + tests if you are open to it.

[log0u7]

I have the fix ready but I can't open the pull request from my fork - GitHub rejects it server-side:

• GraphQL createPullRequest: FORBIDDEN - log0u7 does not have the correct permissions to execute CreatePullRequest
• REST POST /repos/whjvenyl/opencode-damage-control/pulls: 404 Not Found

Meanwhile everything else checks out:

• the compare endpoint works: main...log0u7:fix/path-protection-segment-matching (1 commit ahead, 2 files)
• issues and comments on this repo work (obviously)
• opening a PR from a fork on other public repos passes permission checks fine

So it looks like a GitHub anomaly specific to this repository rather than anything on my side.

The fix (also described above): directory patterns (out/, dist/, ...) are matched with a raw String.includes(), so /home/logout/... trips the built-in out/ rule. The change matches them on path-segment boundaries instead, in both checkPathProtection() and commandReferencesPath(), with 21 new test cases (468/473 pass; the 5 loadConfig failures are pre-existing on main, unrelated).

The branch: log0u7/opencode-damage-control @ fix/path-protection-segment-matching (commit 13ecad6).

If you want to take it in, you can open the PR yourself from that branch (maintainers can select a fork branch when creating a PR), or let me know how you'd prefer to receive the patch.

[log0u7]

Follow-up findings: the path-segment fix from the previous session removed the substring class, but a larger false-positive class remained, now fixed in fix/write-target-extraction (stacked on fix/path-protection-segment-matching).

Root cause of the remaining false positives

checkShellPathViolation required a write/delete operator anywhere in the compound command and then matched protected directory names against the whole command text. Every word in the command therefore acted like a path:

• kustomize build ... (subcommand word) tripped the build/ entry
• a variable named venv tripped .venv/ / venv/
• the docker --rm flag matched as an rm delete command (\brm\s+), so docker run --rm ... npm run build was flagged as deleting build/
• a stderr redirect in one segment made reads in other segments look like writes: a plain ls of a dist/ directory plus a cat f 2>/dev/null elsewhere in the compound was reported as writing dist/
• the bare kubeconfig zeroAccess entry blocked even sed -i on a copy under /tmp and any command merely mentioning the word

The fix

shellWriteTargets() / shellDeleteTargets() tokenize the command (quote-aware, operator-aware) and extract the real destinations:

• redirection targets (>, >>, 2>, &>)
• tee files, dd of= operands (not if=)
• operands of commands whose arguments are write destinations: cp, mv, install, ln, touch, mkdir, chmod, chown, patch, truncate, sed -i (script expression excluded), Windows copy/move/ren/...
• all operands of delete commands (bare relative names included, so deleting a build directory still blocks)

Matching then runs against those tokens only, with the same glob/segment/literal strategies as before. ZeroAccess enforcement is unchanged (any mention still blocks). The bare kubeconfig entry moves from zeroAccess to noDelete: deletion stays blocked, in-place edits on exported copies work again, and ~/.kube remains zeroAccess.

Test matrix: 511 tests pass, including new false-positive cases (kustomize/cargo subcommands, --rm, stderr redirects, variable names) and preserved protections (rm -rf build bare, echo > build/x.js, mv into build, dd of=, tee, chmod on protected files).

Branch: log0u7/fix/write-target-extraction. PR incoming.

[log0u7]

(test) PR creation from a fresh fork still returns FORBIDDEN on CreatePullRequest even though the fork network is now healthy (parent/source correctly set, 4+ min propagation wait). Will retry later or via branch link.

[log0u7]

Found why the PR can't be opened from here (multiple FORBIDDEN/404 attempts across two days, on both the old and a freshly re-created fork): the Pull Requests feature is disabled on this repository (Settings -> General -> Features -> "Pull requests" is unchecked). Diagnostics that led there:

• Issues, comments and forking all work; a cross-repo PR creation attempt against octocat/Hello-World returns the expected 422 No commits (head resolution works for this account), while this repo returns 404/FORBIDDEN for every head, including log0u7:main
• The repository page renders no Pull requests tab (only Issues), unlike a normal repo
• No rulesets, not archived, allow_forking: true - the only blocker is the feature toggle

Once Pull requests are re-enabled in the repository settings, the PR can go up immediately: branch log0u7/opencode-damage-control:fix/write-target-extraction (2 commits: path-segment matching + write/delete target extraction, 511 tests green, full analysis in the comment above).

Alternatively, if you prefer applying it directly: git am-able commits are on that branch, or cherry-pick 13ecad6 and 90cc305.