The default FileBackend: files in thread state, under one key of its own (files, id keyId). They are committed with the call that wrote them, so they are part of every checkpoint, of history and of fork, and a mutation needs no replay guard: its effect is the update the runtime commits.
Directories are implicit: a path is a directory when an entry lies beneath it. Every mutation holds the lock files/state/<keyId>, so the mutations of one batch apply in call order, each against the state the previous one committed. That makes the bounds exact: the total bytes of paths and contents, as JSON strings (what a checkpoint stores, escapes included), is at most maxBytes, and the number of files at most maxFiles, checked when the tool runs (rules 1, 2, 12).
Each checkpoint copies the whole map (rule 6), so pair the backend with a RetentionPolicy.
The lock is what keeps two edits of one file in a batch from losing one, and the bounds exact: the calls of a batch otherwise share one snapshot. Adding tools over this backend to an existing agent adds the files key and the loop's tool-queue: a thread at rest continues with no files, and one in flight is refused until it is finished (ยง4.29). The last file's delete removes the key's entry, so taking the tools out again refuses only a thread that still holds files.
Replaces old with replacement in the file path: the one occurrence, or every occurrence when replaceAll. Refused when old is empty or absent, or occurs more than once and not replaceAll.
Replaces old with replacement in the file path: the one occurrence, or every occurrence when replaceAll. Refused when old is empty or absent, or occurs more than once and not replaceAll.
The files within under that accept takes, in path order, at most limit: accept is applied before the limit, so a file it refuses never takes a place (a composite passes a predicate that refuses the paths a mount shadows, and relies on this to fill its limit with visible files). search likewise.
The files within under that accept takes, in path order, at most limit: accept is applied before the limit, so a file it refuses never takes a place (a composite passes a predicate that refuses the paths a mount shadows, and relies on this to fill its limit with visible files). search likewise.
The lines matching regex of the files within under that accept takes, in path then line order. regex is the model's: match it with org.llm4s.security.RegexSafetyManager.safeFind, never a bare matcher, so a catastrophic pattern is bounded and cannot overflow the stack.
The lines matching regex of the files within under that accept takes, in path then line order. regex is the model's: match it with org.llm4s.security.RegexSafetyManager.safeFind, never a bare matcher, so a catastrophic pattern is bounded and cannot overflow the stack.
The lines matching regex in the files within under. include filters the files: a pattern with no / matches a file's name, one with a / its path relative to under (as ripgrep's --glob).
The lines matching regex in the files within under. include filters the files: a pattern with no / matches a file's name, one with a / its path relative to under (as ripgrep's --glob).