Reference

Note Nothing here is needed to use Fettler. The quick start gets it working; this page is the argument behind it, for anybody who has to satisfy themselves the boundary holds.

The boundary — what it can actually say

Nothing outside a declared tree exists. Not writable, not readable, not listable, not knowable. A path outside every tree is refused with exit 4 — and refused identically whether or not something is actually there, so the refusal itself cannot be used to probe a disk. There is no current directory to change, no path that climbs out, and no shell to reach past it with.

Inside a tree, everything that may be done is stated, never assumed. The first question worth settling is not how this works. It is whether it can express the rule you already have in your head. Most people arrive with one of these.

Every word in that table is one of seven, and section 4 defines them all. They combine freely, per tree and per folder. That is what makes "may reorganise, may not destroy" a rule you can state, rather than a thing you hope for.

Saying it at a depth

A tree is a path and a set of permissions. A scope states permissions somewhere inside one. Here is a real configuration, shown to read rather than to copy — writing your own is the first step of setting up a project:

{
  "trees": {
    "work": {
      "path": ".",
      "can": ["list", "read", "create", "update", "rename", "delete"]
    },
    "requirements": {
      "path": "../shoddy-requirements",
      "can": ["list", "read"],
      "scopes": {
        "backlog":           { "can": ["list", "read", "create", "update", "rename"] },
        "backlog/cancelled": { "can": [] }
      }
    }
  }
}

That reads: work may be changed but nothing in it may be run. The requirements tree is readable throughout. Its backlog folder may be added to, changed, and reorganised, but never destroyed. And backlog/cancelled is not there at all, as far as anything can tell.

Two rules decide what a given file gets, and they are the two worth knowing before you write one of these:

• The most specific scope containing the path decides — not the tree, and not the shallowest scope that matches. cancelled sits inside backlog, so cancelled wins there.
• A scope replaces what its tree grants. It does not add to it. That is what lets a scope take a permission away, which is how a folder inside a readable tree ends up invisible. It is also the trap worth stating out loud: a scope naming create and nothing else grants create and nothing else — not even read.

Paths resolve against the file, never against the caller. Read against a current directory, a relative path names a different tree from every folder you run it in. Read against the file's own directory, it names one tree from everywhere. That is what lets the file be checked in.

A tree, not a repository. A folder with no version control in it is the ordinary case, not an exception. Nothing in the configuration, the default names, or this page assumes a checkout, a remote, or a .git.

A malformed configuration is refused, never fallen back from. A silent fallback usually widens the boundary.

The seven permissions

Move is two permissions, not one. Moving into a subfolder needs rename on the source and create at the destination. Moving out of a scope needs delete as well, because a file that leaves is gone from here either way. That is what makes "may reorganise, may not destroy" possible to say at all.

A move that replaces something needs delete at the destination too, whatever the verb was called. Replacing a file destroys it.

Verbs that do not name what they touch

A recursive delete and a recursive copy reach paths nobody wrote down. That is how a protected scope gets taken anyway. So both are refused when any scope inside the target does not grant what the operation needs. The refusal names no path — saying where would tell a caller where a hidden scope is. That costs one bit of information. It buys a destructive operation refused out loud, instead of half-done in silence.

The defaults, which are the safe ones

The default is decided by where the tree is, not by how its path was spelled. "." and an absolute path to the same folder mean the same thing.

The exception is setup and doctor, and it is exactly two verbs wide. Both configure a machine rather than work in a tree. Neither resolves a path through the boundary, and both reach only a fixed, compiled-in list of well-known configuration paths. With nothing declared, they fall back to the current directory — read-only. That cannot widen anything: read-only is all it grants, and no verb that touches a tree is reachable that way. Without the exception there was no way in at all. setup carries the scaffolder for .fettler.json, so the file it writes was the file required to run it. And doctor refused to diagnose the commonest broken state there is. A configuration that is present and malformed still refuses, for both verbs, because falling back from a broken boundary is how a boundary silently widens.

Why there is no implicit current directory otherwise. The obvious convenience — with no flag and no configuration, the folder you happen to be in becomes a tree — is exactly the "searching around" this boundary exists to stop, and it fails in the one direction a containment mistake must never fail in. A current directory usually sits above the tree somebody meant, so that fallback would widen the boundary silently, at exactly the moment nobody had stated one.

Where a permission may come from

This is the load-bearing rule, and it is the answer to --root.

--root stays because the MCP server has to be launched somehow, and because ad-hoc reading is genuinely useful. It can no longer hand anybody write access. To write to a tree, you put a file in it.

The single exception, and the only one: setup may write outside every tree — to a fixed, compiled-in list of client-configuration paths, and nowhere else. It is the same closed list doctor reads. Nothing else in the tool may write outside a tree that granted it.

Fettler never writes its own rules

The configuration file names the trees, what may be done in each, and the commands Fettler may run. Before this rule existed, Fettler could write that file and then act on what it had just written. Declaring a task and running it took two commands. Two things follow.

execute must not be a default, even on the tree the configuration sits in. That tree is writable by definition, and the configuration lives inside it. Write-by-default plus execute-by-default is arbitrary code execution — the tool could be walked into running anything. And it defeats every other permission at once, because a scope protected from delete means nothing to a task that can run del.

An explicit grant is not enough on its own, either. If the declaration can be written by the thing the grant applies to, the grant has no bound. Whoever holds execute also chooses what executes.

Therefore, compiled in and not configurable at any permission level:

The second group is the same argument, arrived at later. Fettler's own declaration was protected from the start. Meanwhile .claude/settings.json — the file naming which tools a model may use at all — stayed an ordinary writable file. No boundary had to be breached to reach it. A project's assistant configuration lives in the project, so the file governing the assistant and a file the assistant may write were the same file. A model that can edit its own deny list has no deny list. And being asked to edit it is no safeguard: an instruction can arrive from a prompt, from a file just read, or from a misreading of either.

Matched on the last two path segments, not on the file name alone. A rule refusing every settings.json would be unusable, and also wrong: .vscode/settings.json is a person's editor configuration and has no say in what an assistant may do. CLAUDE.md is deliberately not on the list either. It persuades rather than permits, and an assistant maintaining a project's instructions is ordinary work.

setup still writes all of them — by construction, not by exemption. It uses plain file IO and resolves no path through the boundary, so a guard that lives on the path-resolving route every tool verb takes is simply not in its way.

The six names cover the trees and the tasks alike, since a task is declared by the same file that declares the trees.

The names are matched at any depth, so a configuration in a subdirectory is protected too. And they are matched by name, so .fettler.json.bak and .fettler.json.md are ordinary files. Reading them is fine and stays fine. A caller asking what the rules are is the opposite of the problem.

The refusal has its own outcome and its own wording — these are the rules this tool works under, and it does not edit them — and its own exit code, 11. It is deliberately not a permission denial, because nothing is missing. No grant would have allowed it, and a caller sent looking for one is being sent somewhere there is nothing to find. setup may create a configuration where none exists. Changing one is a person's job, with an ordinary editor.

Why an assistant cannot override any of this

Worth stating plainly, because it is the whole point.

• A model never supplies the boundary. The MCP server learns its trees at launch, from a client configuration a person wrote, before the model has said anything. Every tool call then runs against a boundary fixed at that moment.
• No tool can name a tree it was not given. No tool schema carries a root or a config flag, and a test asserts that none ever will. The only related field is in, which selects among trees already open.
• --root cannot grant write at all, so even a careless launch cannot hand write access to anybody.
• And the model cannot edit the files that would grant it more. That was the actual hole — not the flag, but that the tool would happily rewrite the document governing it, and then act on the new version.

So the answer to why does an MCP server need a root is that it does not need --root. It needs a boundary, from a source the model cannot write. A file in the tree is that source.

Hidden is not secret

A scope with no list is absent from find and search, and absent from their counts and totals. A direct path into it is refused in the same words as a path outside every tree — including a path to a file that was never there. The difference between hidden and absent cannot be probed.

This is not encryption, and it does not pretend to be. Somebody at a terminal can open the folder. What it stops is an assistant finding cancelled requirements by searching, and reading them back as current.

The verbs

The CLI verb and the MCP tool name are the same word, and both front ends reach the operations through one dispatcher. That makes "this capability is for a model but not a script" impossible to write, rather than merely forbidden.

$ fettle find "src/**/*.cs" --sort mtime --limit 3
src/Fettler/Glob.cs           4812  2026-08-14T09:22:07Z
src/Fettler/PathRoot.cs       6104  2026-08-13T17:40:11Z
src/Fettler/Edits.cs         11233  2026-08-12T08:05:52Z
3 files (77 excluded: bin, obj, .git - pass --include-generated)

$ fettle roots
work          /work/shoddy  (default)
              can: list read create update rename delete
requirements  /work/shoddy-requirements
              can: list read
              backlog  can: list read create update rename
              backlog/cancelled  can: nothing

declared by /work/shoddy/.fettler.json

Worked twins

# scripts/list-types.ps1
$out = fettle search "^public sealed" --glob "src/**/*.cs" --json
if ($LASTEXITCODE -ne 0) { throw "search failed: $out" }
$out

# scripts/list-types.sh
out=$(fettle search '^public sealed' --glob 'src/**/*.cs' --json) || {
  printf '%s\n' "$out" >&2; exit 1;
}
printf '%s\n' "$out"

In machine-readable mode the complete result — failures included — is on stdout, the normal output stream. That matters on Windows. PowerShell 5.1 turns a native program's redirected error output into NativeCommandError records, and sets $? false even on exit code 0. Any design that needs 2>&1 to retrieve an answer is broken on the primary development platform.

What it can read

On a machine where the assistant's own reader has been denied, Fettler is the only reader. A type it cannot open is a file nobody can open.

• read stops at 2000 lines unless --to says otherwise, and says how many are left. find stops at a thousand, search at two hundred.
• And read stops at 40,000 characters, which --to does not lift. Those two caps are in different units on purpose. A line cap bounds how much of a file you asked for; a character cap bounds how much of it survives the trip, and lines vary in length by two orders of magnitude — so a 593-line page, well under the line cap, was still large enough for a caller to reject the answer whole. A rejected answer costs a turn and returns nothing, which is worse than a short one, so the size is measured here and the answer comes back short and says what is left. The budget is spent across the whole call rather than per path, and at least one line is always served — a minified file is a single enormous line, and an empty answer is a dead end rather than a smaller answer.
• --tail N is the end of the file, counted backwards. Reaching the end of a log or a build transcript needs neither its length nor any arithmetic. It cannot be combined with --from/--to. The end of a file and a named range are two different questions, and answering one of them by precedence would be a confident wrong answer rather than an error.
• A notebook's non-text output is measured rather than pasted. One output cell routinely holds a megabyte of encoded image data that nobody can see.
• A document is searched, not only read. A PDF in the path of a search is rendered and matched along with everything else, and a hit inside one cites its page. Searching inside one says what that costs.
• Word and Excel are read here rather than exported first. Telling a person to save as PDF or CSV describes a chore rather than a workflow: it makes somebody convert a file before the assistant may read it, which is the hindrance and not the remedy. The obvious objection — that parsers for those formats are a maintenance liability — is answered by what the formats actually are: a zip full of XML, opened with the archive support already here, and so with no new dependency at all.
• A workbook comes back as rows, not as cells. A cell to a line would make every hit a single value with nothing around it, and what a person wants from a search of a workbook is the record the value sits in. Formulas are rendered as well as values, because the two answer different questions and only one of them is in the file twice: a search for VLOOKUP is a search for how a sheet works and would find nothing in the cached results, while a search for a customer name would find nothing in the formulas. And dates are rendered as dates — Excel stores the cell you see as 2026-03-15 as the number 46096, so rendering the number would leave a workbook full of dates nobody can search for. That is the same readable-but-unfindable fault that had search skipping PDFs.
• A Word document is located by its headings. Word does not store where the pages break — that is worked out at layout time by whatever is displaying the file, and it moves with the font and the paper. A heading is in the file, is stable, and is what a person would say if you asked them where in the document something was.
• The macro-bearing twins are in; the older formats are not. .xlsm and .docm are the same formats carrying macros, read the same way, and nothing here executes anything. .xlsb and .doc are not here: both are binary formats wearing a familiar coat, and a reader that claimed them would fail on every file.
• Neither reader trusts the file. A document arrives from wherever documents arrive from, and these run inside a server whose whole job is to be a boundary. So no DTD and no resolver, which closes the external entity that reads a file off the machine and the internal one that expands to gigabytes; and no part is read past a cap however comfortable a number its own header claims. A rendering stops at 200,000 lines and says that the rest was left unread.
• A rendering does not go back. write, edit and replace refuse a PDF, a workbook and a Word document outright: what comes back for one is text pulled out of it, with the sheets, the formulas, the tables and every piece of structure left behind, so writing that text back would not edit the file — it would replace it with a fraction of itself, still wearing the name that says it is a document. An image, an archive and a lone .gz are refused for the plainer reason that they are not text at all. move, copy and delete do not inspect content and are the way to shift one of these; extract writes an archive member's own bytes and is deliberately not caught.
• Still no plugins. A declared command needs an explicit execute grant, so a loader running unnamed code in process at full trust would be a hole straight through the boundary. A reader is a class in this tree with tests beside it, never a file found at startup. For a format Fettler does not ship, a declared converter task is the honest form, and it already exists.

Searching inside one

Readable and unfindable is the trap this closes. A tool can render a PDF for read and still let search try to decode it as text, fail, and move on without counting it — leaving a tree full of documents answering every search with a confident nothing. That is the failure this whole tool exists to prevent, and it would be sitting inside the tool.

• The rendering happens on the way into the search, and a hit cites the page rather than a line number into a rendering nobody can see. A line number that cannot be checked against the document is not a citation, and it moves the moment the renderer changes.
• Renderings are cached on the file's length and modification time, so a second search over the same tree does not pay for the same parse again. A file that has changed is rendered again.
• A document over 32 MB is not opened, and neither is one that will not render. Neither fails the sweep; both are counted.
• What was not looked inside is said out loud. A search that never opened a file has not established that there is nothing in it, so the count travels with the answer rather than being left to be inferred from a total that looks complete.
• --no-documents leaves them shut where the cost is not worth paying. The count is still reported.

Unpacking one

extract ARCHIVE --into DIR writes; everything above only reads. An archive is a list of paths somebody else chose. That is exactly why the tool that already refuses a path outside a tree is the right one to unpack with.

$ fettle read fettle-1.0.0-win-x64.zip
79605839  2026-08-16 16:08  - fettle.exe
    2545  2026-08-16 14:09  - NOTICE
    1133  2026-07-30 04:52  - LICENSE
3 members, 79609517 bytes uncompressed

$ fettle extract fettle-1.0.0-win-x64.zip --into tools
extracted 3 members (79609517 bytes) from work:fettle-1.0.0-win-x64.zip into work:tools

• Refused whole, or not at all. Every member is resolved through the boundary before a byte is written. An archive that would escape, or that lands anywhere it may not, leaves nothing behind. A half-unpacked archive is the state nobody can see the shape of — the same reason edit is all-or-nothing.
• Zip slip is refused by construction, not by a bolted-on check. Zip slip is the classic attack where an archive member is named something like ../../etc/passwd so it lands outside the unpack folder. Here that member resolves outside every tree and comes back exit 4, exactly like a path somebody typed.
• A member that escapes only the destination is refused too. out/../elsewhere.txt normalises to somewhere the boundary is perfectly happy with. The tree check passes, and the file still lands nowhere near where you said. Nothing is wrong with the path. What is wrong is that it is not where you put it.
• A link member is refused rather than skipped. Creating links is out of scope anyway. And a symbolic link inside a tar is the one member that can point out of the tree after every path check has passed. Skipping it silently would produce an extraction that looks complete and is not.
• The executable bit is carried. R6.9 is this project's own requirement clause about that bit, and its release depends on a fettle arriving out of a tar still able to run.
• Bounded, not endured. There is a cap on member count and on total unpacked bytes, refused with a reason — the same posture as the bound on a runaway pattern. A compressed archive can name far more content than it occupies, and finding that out by running out of disk is finding out too late.
• Nothing is overwritten without --overwrite. An existing file is a refusal before anything is written, not a surprise halfway through.

Declared tasks

run executes only what the configuration declares, and never composes a shell command. Declaring one is a step of setting up a project. What a declaration means is here.

The command grammar, in full

• Whitespace separates arguments. Runs of spaces and tabs are one separator.
• A double-quoted span is one argument, or part of one; the quotes are removed. "one two" is a single argument.
• Two double quotes inside a quoted span are one literal quote.
• A backslash is never an escape. It is an ordinary character, so a Windows path is written once rather than doubled.
• Nothing else is special. No single quotes, no variables, no globbing, no redirection, no &&. The string is split once, and the program is launched with the resulting list.
• An unclosed quote is refused, not guessed at.

$ fettle run build --release
refused: no such flag: --release - try: fettle help
$ fettle run build release
refused: run takes a task name and nothing else; 'release' is extra. A task is
declared whole and takes no arguments - declare a second task for the second
thing you want run.

cwd — the folder the task runs in — is optional, defaults to the top of the default tree, and is checked for containment like any other path.

Values the file supplies

Declaring a second task answers test versus machines. It cannot answer the branch to cut or the note to commit under, which are strings invented fresh each time. A command line may name a value the configuration declares:

"replacements": {
  "feature-branch": "hebdenbridge"
},
"tasks": {
  "feature": { "run": "pwsh -File scripts/shoddy-branch.ps1 feature {feature-branch}" }
}

• Filling happens after the split, into a word. A value is one argument whatever is in it — a space does not make two arguments, a quote does not change the parse. Filling the LINE and splitting afterwards would hand the grammar a value, which is the entire failure class the split-once rule exists to remove.
• A placeholder may be part of a word. --message={note} and v{release-tag} are each one argument.
• Only an identifier between braces is a name — a letter, then letters, digits, dots, underscores or hyphens. Everything else is ordinary text, so { $_.Name }, {a:.b} and {0} go on meaning what they meant. Write {{ for a literal brace where a name would otherwise be read.
• One pass. A value carrying braces is inserted literally and never looked up again, so a replacement cannot build another.
• An undeclared name is refused and the configuration does not load. It is never passed through — passed through, new {feature-branch} does not fail, it creates a branch called {feature-branch}.
• The overlay is where a value belongs. .fettler.local.json is gitignored and its replacements merge over the checked-in ones name by name, so the project declares the task while today's branch name stays out of the diff.
• They are not for secrets. tasks shows every value, deliberately, so that what is listed is what runs. A token belongs in the environment of the process a task launches.

When it refuses

Real transcripts. Each prints its whole answer on stdout, the normal output stream, so no redirection is needed to read a failure. The full code table is below.

A path outside every declared tree

$ fettle read ../secrets.txt
refused: the path is outside every declared tree; ask for the roots to see the boundary
$ echo $LASTEXITCODE
4

Climbing out with .., an absolute path elsewhere, and a link leaving the tree all land here. All of them answer the same whether or not the file exists.

Writing a file that says what the tool may do

$ fettle write .fettler.json --text "{}" --overwrite
refused: .fettler.json is one of the files that tell this tool what it may do,
and it does not edit those. Change it with an editor.
The files are: .fettler.json, .fettler.local.json (.fettler.json)
$ echo $LASTEXITCODE
11

This has its own outcome rather than a permission denial, because nothing is missing: no grant would have allowed it. Without the rule, the escape is two commands — write a task declaration, then run what you just wrote.

A write that would put a secret on disk

$ fettle write config.json --text-file staged.json --overwrite
refused: this write would add a credential to the file: line 14 (aws-access-key-id).
The secret itself is deliberately not quoted back, because a refusal that named it
would put it in the log and the transcript. Use a reference such as ${ENV_VAR}
instead, or pass the override if this is not a credential.
$ echo $LASTEXITCODE
12

It judges what the write ADDS, not what the file contains. A configuration that already holds a key stays editable. That is the whole difference between a rule people keep and a rule people switch off. Only a secret absent from the previous content stops anything, so reformatting, reordering, and editing the lines around one all still work.

The refusal never repeats what it found. A line number and a detector name, and nothing else. A message naming the secret would write it into the log, the transcript, and whatever ships those onward — a worse outcome than the write it was refusing.

--allow-credential is offered by the command line and by nothing else. No MCP tool carries it, and a test asserts none ever will. Deciding that a random-looking string is not a secret is a judgement about your own file, and a person makes it — the same reasoning that keeps setup out of a model's hands.

A read that would disclose regulated data

$ fettle read ward-round.docx
refused: this response would disclose regulated data: 2 in identifiers. What was found is
deliberately not quoted back, because a refusal that named it would put it in the
log and the transcript, which is the disclosure being refused. Read a narrower
range, or take the screen off this scope if the content is not what it looks like.
$ echo $LASTEXITCODE
13

The mirror of the credential refusal above — that one is a write going in, this one a payload coming out. It only happens in a scope whose configuration asks for it. Section 14 is the whole of it.

Running a task in a tree that does not grant execute

$ fettle run hello
refused: 'hello' would run in a tree that does not grant execute.
Add "execute" to that tree's or scope's "can" in .fettler.json.
It is never granted by default.
$ echo $LASTEXITCODE
8

The tree holding the configuration is writable by definition. So write-by-default plus execute-by-default would be arbitrary code execution — and a scope protected from delete means nothing to a task that can run del.

A task nobody declared

$ fettle run deploy
refused: no task called 'deploy'; .fettler.json declares: hello
$ echo $LASTEXITCODE
3

A flag with no value, and a flag no verb knows

$ fettle edit f.txt --insert-after 1 --text
refused: --text needs a value, and nothing followed it - write --NAME= for a deliberately empty one
$ fettle find --gob
refused: no such flag: --gob - try: fettle help

Both answer 2. Ignoring either would produce a wrong answer rather than a failure. A flag with no value would swallow the next word as its value and write the word true into the file.

Exit codes

An exit code is the number a program hands back when it finishes; 0 means success. Callers chain on exit codes because PowerShell 5.1 has no &&. The machine-readable answer carries the same word as an outcome field.

doctor is the exception, because it reports rather than operates: 0 healthy or not applicable, 1 warnings only, 2 anything broken. --hook always exits 0.

What it touches besides content

Arguments it will not guess at

• A flag no verb knows is refused, never ignored — one dash or two. A flag that takes a value swallows the argument after it. So a misspelt --gob "*.cs" would eat the pattern, and the search would then run against the whole tree with complete confidence. A single dash is the same trap wearing one fewer character. search PATTERN -i — the spelling every grep in the world uses — would otherwise be read as a second pattern and answer the union of two questions. -e is the only short flag there is. A pattern or path that genuinely starts with a hyphen goes after a bare --, or through --pattern-file or --pattern-stdin.
• A known flag with no value is refused too. The name was right; the value was missing. Write --NAME= for a deliberately empty one.
• A pattern may arrive as file content instead of an argument. --pattern-file and --pattern-stdin take one pattern per line; likewise --replace-file, --with-file and --text-file. Text with quotes and newlines never has to be escaped onto a command line.
• A leading byte-order mark on a stream is taken off. A byte-order mark is an invisible marker character some tools put at the start of text. Windows PowerShell emits one whether asked to or not. Keeping it made a pattern match nothing, and spliced an invisible character into the middle of a source file. This applies to the command line's streams and the MCP front end's alike. A mark further along is left alone.
• Text an edit brings in is rewritten into the file's own line endings; text already there is untouched. A PowerShell here-string is CRLF whatever the file is. Splicing that in verbatim leaves a file disagreeing with itself by one line — which nothing notices until a version control system does.
• A file that disagrees with itself says so. read marks it (MIXED) beside the dominant ending. Nothing is silently regularised.

The rules a caller has to know

How a declared path is written

Relative, forward-slashed, no drive letter. There is no formal standard for this. There is a convention, and it is git's. It is what .gitignore, Docker, npm and VS Code's own task files use, and it is the only spelling that means one thing on all three platforms.

Refused rather than converted, because converting would make a file legitimately called a\b unreachable on the platforms where that is a legal name. The same rule applies to a scope key and to a task's cwd.

Where to say it so it is read

Ranked by how much each actually changes behaviour.

Everything doctor can report, and how to clear it

fettle doctor's report is two halves. The wiring is one row per client per level, ending in a verdict. The findings are numbered, and each one is a way round the boundary. A finding marked ! is serious; one marked - is worth knowing. Running it is step 5 of setting up a project.

Note setup adds and never deletes. So anything below whose fix is "remove" is a person's edit, in an editor. That is deliberate: a tool that quietly removed your configuration would be doing the very thing this design objects to.

The wiring

The findings

What this defends against, and what it does not

That bound is load-bearing, because it says how far each rule has to go.

• The rule-file refusal has to be reliable, not tamper-proof. It must never be reached by a tool call in normal use. It does not have to survive somebody editing .fettler.json in a text editor. That person is the author of the rules, not a threat to them.
• No integrity checking, no signing, no lockfiles. All of that defends against an adversary who is not in the model.
• Path comparison is what containment is. It does not defend against another process replacing a path component between the check and the operation. Closing that gap needs operating-system support this does not have. A synced folder — Dropbox, OneDrive, a network share — is where it is likeliest to matter. Those are ordinary trees and get no special handling, because none exists and none is wanted.

This is stated because the alternative is scope creep. Every rule here could be hardened indefinitely against an attacker nobody is worried about.