harness.failharness.failharness.failharness.failharness.fail

One note per harness: what each score rests on, with the sources behind it.

Aider 0.86.2

.aiderignore, /read-only, --add-gitignore-files — long-standing, gitignore syntax (FAQ, options, commands) (A1/A3 ●, A5 ◐); the ignore file is aider's own and cannot name other tools (A4 ○), one per repository, "default: .aiderignore in git root" (A2 ◐). The FAQ describes it as a way to "ignore parts of the repo that aren’t relevant to your task"; enforcement is visible only in source. Matching is deterministic code — pathspec in repo.py (D1 ●) — and the tracked-file list that feeds the repo map ("a list of the files in the repo, along with the key symbols") drops ignored files (repo.py#L486); /add skips them "due to aiderignore or --subtree-only" (commands.py#L811-L812), but /read-only never consults it (B1 ◐). The edit path checks gitignore but not .aiderignore, and asks "Allow edits to file that has not been added to the chat?" instead (allowed_to_edit) (B3 ○); model-suggested shell commands run after a "Run shell command?" confirmation with no ignore check (base_coder.py#L2434-L2455) (B2 ○). The file is checked when a file is added and re-read when its mtime changes, at most once per second; files already in the chat are not re-checked (B4 ◐). Deny precedence, error handling, self-protection, policy-in-context, canonicalization, override and delegation are undocumented (?).

Claude Code 2.1.295

permissions.deny with Read()/Edit() path rules (permissions docs) (A1/A3 ●); rules are Claude Code's own JSON settings and bind no other tool (A4 ○, A5 ○); project settings can be committed with the repo (.claude/settings.json), but Claude Code reads that one file "from the session's primary working directory" (settings), with no per-directory files (A2 ◐). Vendor states enforcement is deterministic: "Permission rules are enforced by Claude Code, not by the model" (D1 ●), with documented precedence "deny, then ask, then allow". A Read deny also blocks Edit and Write on the same path, and Claude Code "refuses the call before any file access" (errors); NotebookEdit needs an Edit deny; rename and delete happen only through the shell, where deny rules reach "file commands Claude Code recognizes in Bash, such as cat, head, tail, sed, and tee" and redirection targets, with no statement for mv or rm (B3 ◐). Settings edits, permissions included, reach "the running session without a restart", but managed settings delivered by MDM or the claude.ai console "reach a running session on a schedule rather than on save" (B4 ◐). For context surfaces (Grep, Glob, @-mentions, IDE context) the vendor's own wording is a "best-effort attempt" (B1 ◐). Shell coverage is explicitly partial: rules "don't apply … to arbitrary subprocesses that read or write files indirectly"; the OS sandbox, which "is off by default", closes that, with an unsandboxed-retry escape hatch (allowUnsandboxedCommands, default true) approved by a prompt, by the auto-mode classifier, or by a matching allow rule, depending on mode (B2 ◐). Invalid managed sandbox values fail closed per the changelog (2.1.283), and an unparseable managed settings file stops every session; one the OS denies reading starts the session "without that file's policies" (2.1.285); in other settings files a malformed permission rule is skipped — Claude Code "skips those values and keeps the rest of the file in effect" (settings) (C2 ◐). Scoped rules "don't change which tools Claude sees. Claude Code checks them when Claude attempts a call, leaving the prefix intact", and a bare tool-name deny removes the tool rather than describing it (prompt caching) (C4 ●). CVE-2025-54794 was "prefix matching instead of canonical path comparison", fixed; deny rules now "apply when either the requested path or the file it resolves to matches", yet symlink bypasses of Read deny rules through @-mentions, IDE selections and @-mentioned folder listings were still being fixed in 2.1.289–2.1.290 (D2 ◐). Permission modes state that "Deny rules block in every mode, including bypassPermissions", and "PreToolUse hook decisions don't bypass permission rules" (C1 ●). Writes to protected paths, .claude among them, cannot be pre-approved by allow rules, yet in auto mode — "the built-in starting permission mode for interactive terminal and VS Code sessions" — they are "Routed to the classifier", and in bypassPermissions they are "Allowed" (C3 ◐). That is also the D3 gap: user deny rules lift only when the user edits them, but the built-in protection falls to a blanket mode, to a classifier model's judgment, and to a prompt option that allows .claude edits "for this session" (D3 ◐). Subagents: built-in ones inherit "the parent conversation's permission rules", a settings deny rule "applies to the main conversation and to subagents", and a subagent that declares bypassPermissions "keeps the main conversation's mode instead"; spawned shell processes carry the rules only inside the opt-in sandbox (D4 ◐).

Cline 4.1.23

.clineignore, gitignore syntax, one file "in your project root" — multi-root workspaces get one per workspace root, not per directory (A1/A3 ●, A2 ◐, A5 ◐); it cannot name other tools (A4 ○). Matching files are excluded from "the file listing Cline sees when starting a task", automatic context gathering and search results, but the docs state plainly that the file "is not a security or access-control boundary — ignored files can still be read via explicit @ mentions or shell commands" (B1 ◐). The page carries a deprecation banner and offers a PreToolUse hook script as the enforced replacement: opt-in, user-installed code that "actively blocks the tool call whenever a file read (read_files), edit (editor, apply_patch), or shell command (run_commands) targets a file matching a .clineignore pattern", parsing apply_patch add, update, delete and move headers (D1 ◐, B3 ◐). The hook "cancels the tool call before it runs — the file is never accessed", and the script reads .clineignore afresh on every call (B4 ◐). Its shell guard "is a conservative token check, not a full shell parser … a sufficiently creative command could still slip through" (B2 ◐); it "also blocks attempts to modify .clineignore itself so the agent cannot un-ignore files", though the hook file itself is not on its list (C3 ◐); "Paths are canonicalized lexically, but symlinks are not resolved" (D2 ◐); and "In the CLI, hooks are disabled in --yolo mode", so a blanket mode lifts the restriction (C1 ○, D3 ○). Subagents run with "Cline's built-in tools for the current mode", and "Approval settings don't apply inside a subagent"; whether hooks run for a subagent's tool calls is not stated (D4 ?). Error handling for a malformed or unreadable .clineignore and whether the policy reaches model context are undocumented (?).

Cursor 3.24.9

.cursorignore, gitignore syntax, one file "in your root directory", with an opt-in setting that searches parent directories, not subdirectories (ignore docs) (A1/A3 ●, A2 ◐, A5 ◐); the file binds all of Cursor's surfaces alike — "Agent, Tab, and Inline Edit" — with no way to name a tool (A4 ○). The docs disclaim completeness — "complete protection isn't guaranteed due to LLM unpredictability" — and state plainly that "the terminal and MCP server tools used by Agent cannot block access to code governed by .cursorignore" (B1 ◐, B2 ○); the IDE release notes record name leaks closed one surface at a time — "autocomplete in the prompt no longer suggests files excluded by .cursorignore", and directory listings now "honor .cursorignore patterns from parent folders when listing a subfolder" (B1 ◐). Whether the rules gate writes, and when rule changes take effect, is undocumented (B3/B4 ?). CVE-2025-64110: an agent could write a new .cursorignore that invalidated the existing ones; since 2.0, "the agents ability to create and edit cursorignore files has been blocked in all cases", and the terminal sandbox lists .cursorignore among paths "always write-protected, regardless of your sandbox.json configuration" (sandbox.json reference) — but that list does not name the .gitignore files Cursor also honors, and Run Everything mode runs with no sandbox (run modes) (C3 ◐). How malformed rules are handled is undocumented; for a file that fails to load, 3.22 has Cursor retry a failed startup .cursorignore scan "instead of leaving agent context reads stuck for the rest of the session" (3.22 notes), without saying what reads see meanwhile (C2 ?). CVE-2026-50548 and CVE-2026-50549 (Cato AI Labs) let the agent write files outside the workspace through a sandbox write-path override and a failed-canonicalization fallback through an in-workspace symlink; both fixed in Cursor 3.0 per the NVD records (D2 ◐). "Cursor blocks access to files listed in .cursorignore", under the same no-guarantee caveat (D1 ◐). Whether the rules hold against Run Modes grants, whether they reach model context, how they are overridden, and whether they carry to subagents is undocumented (C1/C4/D3/D4 ?).

DeepSeek Harness 0.2.1-alpha.1

No path rules: the file-effect policy is one of three sandbox modes (read-only, workspace-write, danger-full-access) over a workspace root, and "Normal tool calls derive workspaceRoot from the calling session's immutable cwd" (sandbox docs) (A1–A5 ○). One policy applies "to every confined bash, filesystem, and terminal call" (sandbox-policy README): subprocesses run under Seatbelt, bwrap/Landlock, or a Windows ACL runner whose "hard-link, unconfined-read, and AppContainer-ACL boundaries are current partial cases" (B2 ◐), and file-tool writes the mode fence refuses fail with FS_SANDBOX_DENIED (filesystem docs) — a mode, not a per-path do-not-touch (B3 ◐). "Tool layers call resolve for each execution", and the effective mode is the session's last sandbox/mode event, so a switch applies from the next call (B4 ●). An approved escalated retry "is a new call with a wider policy" (C1 ○), and danger-full-access, which "bypasses confinement", ships in the default preset table (permission presets), where "Session choices survive restart" (D3 ○). The same presets doc has misconfiguration fail at plugin load — configured entries named custom or auto throw — and "a missing projection key fails explicitly", and the sandbox seam rules that "Silent unconfined passthrough is never legal for a confined policy"; that covers mode and executor configuration, not path rules, which don't exist (C2 ◐). "Before each model request, the model receives the effective policy and workspace": enforced in sandbox code, but also stated to the model (C4 ◐). In-process subagents "retain the inherited sandbox override plus approval: never"; the statement is scoped to in-process backends, not the external ACP, Codex, and Claude Code providers (subagent docs) (D4 ◐). Enforcement fixes track the classic classes: POSIX symlink/parent-directory combinations, Windows drive-relative paths (v0.1.6-alpha.1, carried into v0.1.7-rc.1), Windows sandbox deletions escaping the authorized directory and across workspaces (v0.1.7-alpha.1); "Enforcing providers canonicalize the root where the files exist" (D2 ◐). CVE-2026-82533 (OX Research): the sandboxed agent could reach the harness's own unauthenticated control interface and elevate its session to unconfined execution — the enforcement layer operable by the thing it governs; fixed August 27, 2026 in 0.1.2-alpha.1, whose release notes require a one-time token for network access to the web interface, and the web-server docs now have the shipped Connection plugin supply "Host/Origin checks plus browser-session authentication for every Host API route and stream" (C3 ◐: the bar exists now, its guarantee is undocumented). SAFETY.md states plainly that sandboxing, approval prompts, and permission controls "do not guarantee isolation or prevent damage" (D1 ◐). Whether reads and listings are kept out of model context is undocumented (B1 ?).

Gemini CLI 0.63.0

.geminiignore (docs) plus .gitignore reuse (source) (A1/A3 ●, A5 ◐); .geminiignore is one file "in the root of your project directory" — nested .gitignore files are honored per directory (source), but that is the version-control file, not the harness's policy file (A2 ◐). The docs scope the file to "tools that support this feature" (B1 ◐). read_file enforces deterministically via shouldIgnoreFile(), but the listing and search tools let the model switch the check off: glob, list_directory and read_many_files take a model-set respect_gemini_ignore (tool definitions), and grep's no_ignore drops the .geminiignore filter (source) (B1/D1 ◐; D3 ○: the restriction lifts with no user action) — and a feature request on the project's tracker, closed as not planned, names cat via run_shell_command as the workaround for reading ignored files (#13775); only the opt-in tool sandbox, security.toolSandboxing with default: false (settings schema), turns ignored paths into kernel-denied paths for shell commands (source) (B2 ◐). "To apply the changes, you must restart your Gemini CLI session", per the same docs (B4 ◐). Negation handling has shipped a bug that errs restrictive (! rules fail to un-ignore, #5444, closed by the project's bot after a Stale label, with no linked fix), but the error paths fail open: the matcher library skips a pattern ending in an unescaped backslash without a warning (node-ignore), an unreadable .geminiignore loads as no rules — "continue without it" (source) — and the ignore check returns not-ignored on any exception (source) (C2 ○). The write tools carry no ignore check at all — write_file and replace never consult the ignore service, verifiable in source (write-file.ts, edit.ts); with the opt-in sandbox on, "individual tool executions (like shell_exec and write_file)" run inside it (sandbox docs), where ignored paths are masked (B3 ◐). Nothing protects .geminiignore itself: "If the workspace is writable, we allow editing .gitignore and .geminiignore by default" (sandbox source) (C3 ○). read_file checks the ignore rules against both the requested path and its resolved real path (source); other surfaces are undocumented (D2 ◐). Whether the rules hold against approval modes, whether ignore patterns reach model context, and whether they carry to subagents is undocumented (C1/C4/D4 ?).

GitHub Copilot (agent surfaces) Copilot CLI 1.0.93, VS Code 1.141.0

Content exclusion exists and is deterministic for completions, chat, and review. For the agent surfaces, GitHub's own pages disagree: the how-to still says "GitHub Copilot CLI and Agent mode in Copilot Chat in IDEs do not support content exclusion" (configuring exclusions), while the concepts page marks Copilot CLI as supported and states "Content exclusion is currently not supported in Edit and Agent modes of Copilot Chat in Visual Studio Code and other editors." The CLI changelog shows exclusion enforced there, shell commands included (v1.0.33, v1.0.64), and since v1.0.64 failing open: "Access is allowed until rules can be fetched" when the rules service is unreachable. Server-managed settings likewise "fail open" when no cached policy is available (v1.0.78), unless an administrator sets forceRemoteSettingsRefresh: then "An unsuccessful refresh leaves the policy unconfirmed, so affected operations are restricted" (enterprise managed settings), and an unrecognized disableBypassPermissionsMode value is enforced as "disable" "as a fail-closed default" (C2 ◐). The path rules that do reach an agent surface are Copilot CLI's own: Read(...), Edit(...), and Write(...) glob rules in enterprise managed settings, session --deny-tool patterns such as read(.env) and write(PATH) (configuration reference, command reference), and sandbox denied paths, which "take precedence over both kinds of grant" (local sandboxing) (A1/A3 ●). Agent mode in VS Code has narrower equivalents: deniedPaths in chat.agent.sandbox.fileSystem.userConfiguredPaths for terminal commands and their child processes, while "Built-in tools that don't start operating system processes use their own permission checks" (agent sandboxing), and chat.tools.edits.autoApprove globs that require approval for edits to sensitive files (sensitive files). None of them lives in the tree: for the repository settings file .github/copilot/settings.json, "Only the keys listed in the following table are supported at the repository level", permission rules not among them; sandbox policy is per project in app settings; content exclusion is server-delivered; repository hooks (.github/hooks/) can deny tool calls, but as code, not declarative path rules (A2 ○). Coverage is CLI-only: Read rules gate file reads, Edit/Write rules also cover a recognized set of shell redirections and in-place sed edits, but when the path "comes from a variable" "these path rules do not apply"; shell commands and built-in searches "run as sandboxed child processes, so the operating system enforces the policy directly" (B1/B2/B3 ◐). Managed settings re-apply hourly "without restarting the session", content exclusion "can take up to 30 minutes to take effect in IDEs", and "A running child process keeps the policy it received at launch" (B4 ◐). A write(PATH) match "resolves symlinks and . / .. segments", sandbox denied paths resolve "their written path and current target" though on Linux "a denied symbolic link protects its target, but does not reliably prevent the link itself from being replaced", and "content exclusions do not apply to symbolic links (symlinks) and repositories located on remote filesystems" (D2 ◐). The CLI's rules are enforced by the harness, but the restriction an organization declares through content exclusion is not enforced in IDE agent mode (D1 ◐). File-based managed settings are rejected when they are "symlinks, not owned by root, or world-writable"; the docs state no such guard for the user-level settings file (C3 ◐). v1.0.88 closed a management-layer fail-open where ACP, AHP-host, and --server sessions "previously ran with no managed MCP, permission, or plugin policy". Copilot CLI's own deny rules hold against grants: "Deny rules always take precedence over allow rules, even when --allow-all is set or a matching approval has been saved" (allowing tools). Sandbox denials do not: in VS Code "Approval to run outside the sandbox removes file system and network restrictions for that operation" (C1 ◐). A CLI sandbox bypass "applies to that attempt", but "A bypass prompt can also let you disable sandboxing for the rest of the current session" (sandbox settings), and in VS Code "If you approve a session-wide bypass, subsequent terminal commands in that session also run without those restrictions" (D3 ◐). For subagents, "Whether the policy applies, and how, depends on the tool a subagent invokes" (D4 ◐). Whether rule text ever reaches the model is undocumented (C4 ?).

goose 1.54.0

.gooseignore is gone from the current tree: the docs carry no page for it, the string survives in the repo's own .gitignore, and v1.44.0's "Remove stale gooseignore references" (#10203) was the cleanup. Tool permissions are per tool, not per path: "Each tool can be set to one of three permission levels" (Always Allow, Ask Before, Never Allow) (tool permissions) (A1–A5 ○). The only file-access policy a user can write is adversary mode's ~/.config/goose/adversary.md, "your policy, written in plain language" (for example "SSH keys, .env files, or credentials are read or transmitted"), judged by a reviewer that "uses the same model and provider goose is already configured with": model judgment over prose, not a rule (C4 ○). By default it reviews only shell calls, and "If the reviewer fails for any reason, the tool call is allowed through (fail-open)". v1.49.0 shipped "Give permission denies precedence" (#11477), giving "persisted hard-deny entries precedence over overlapping allow or prompt entries". But Auto mode approves every tool without consulting them (permission inspector: GooseMode::Auto => InspectionAction::Allow) (C1 ◐), and "Autonomous Mode is applied by default" (permission modes): a blanket mode that lifts every restriction (D3 ○). Subagents run only in that mode: "Subagents are disabled in manual approval, smart approval, and chat-only modes" (subagents). Hooks carry a documented deny contract (v1.44.0), though "By default a hook failure is logged and the tool call proceeds" unless set to on_failure: block (hooks docs) (D1 ◐). A malformed hook configuration "skips that plugin's hooks.json with a warning", and on_failure "does not make configuration-loading or matcher errors fail closed" (C2 ○). Read, shell and write gating, timing, self-protection, canonicalization, and delegation of restrictions are undocumented (B1–B4, C3, D2, D4 ?).

JetBrains AI Assistant / Junie AI Assistant 263.6800.10, Junie 262.2144.120

.aiignore uses "the same syntax as a .gitignore file" (A1/A3 ●), and AI Assistant also honors .cursorignore, .codeiumignore, or .aiexclude "as long as they are located in the root folder of the project" (A5 ◐); .noai "in the root directory of the project" is a whole-project kill switch (docs). Junie reads .aiignore "in the project root directory" (Junie docs), not per directory (A2 ◐). The file names no tool and binds only Junie: AI Assistant's agents page lists .aiignore as "Respected" for Junie and "Not respected" for Claude Agent, Codex, and GitHub Copilot, and "files listed in .aiignore can be processed by Claude Agent" (Claude Agent) (A4 ○). Enforcement is vendor-admitted best-effort: "ignored files may still be processed due to unforeseen issues" (docs), and "Only the contents of files listed in .aiignore are protected" (Junie docs); file names and paths stay visible (support KB) (B1/D1 ◐). Edits to ignored files are approval-gated rather than hard-blocked: Junie "will ask for explicit approval before viewing or editing" them (Junie docs) (B3 ◐). The Junie docs name two exceptions where Junie "might still have access to the files listed in .aiignore": "If Brave Mode is turned on", and "When executing a command that is added to the Action Allowlist". So a remembered allowlist entry and a bypass mode both lift the restriction: "if a command is allowlisted, Junie will not ask for confirmation, even if that command accesses files and folders listed in .aiignore" (support KB) (C1 ○). Other shell access stays approval-gated (B2 ◐), and Brave Mode lets Junie "execute all potentially sensitive actions without user approval" (D3 ○). These statements are from the IDE plugin; the Junie CLI docs do not mention .aiignore. Timing, fail direction, self-protection, policy-as-data, canonicalization, and delegation are undocumented (B4, C2, C3, C4, D2, D4 ?).

OpenAI Codex CLI 0.162.0

The long-standing read-restriction gap has begun closing: beta permission profiles ("Beta. Permission profiles are under active development and may change.") add per-path filesystem rules — a deny entry "Denies both reads and writes under the path", and glob deny entries are supported — configurable in project .codex/config.toml files: "Codex walks from the project root to your current working directory and loads every .codex/config.toml it finds", "the closest file to your working directory wins", and "Codex loads project-scoped config files only when the project is trusted" (advanced config). User-authorable per-path rules exist, in beta (A1/A3 ●); the files travel with the repo, but which ones apply depends on where the session starts, not on the path being accessed (A2 ◐). The .codexignore request #1397 was closed as a duplicate; its successor #2847 was closed as completed on 2026-06-29, a maintainer citing "a new feature in beta that implements this functionality". The format is a Codex-specific TOML profile (A5 ○), and a profile names no agent (A4 ○). A read grant means "Commands cannot create, modify, rename, or delete files there" (B3 ●). The profile semantics lean fail-closed: "When two entries target the same path, deny takes precedence over write, and write takes precedence over read", though "A more specific path can also reopen a narrower subtree inside a broader deny"; "Missing or empty filesystem tables keep filesystem access restricted and emit a startup warning", and "If the selected policy cannot be enforced by the platform sandbox, Codex refuses to run the command instead of silently running it unsandboxed" — but "If sandbox_mode appears in any loaded config file … Codex uses those older sandbox settings instead of default_permissions" (C2 ◐). Extending :workspace "keeps the workspace root's .codex directory read-only unless you explicitly override it" (C3 ◐). The deny list is enforced in sandbox code, but the harness also writes the denied paths and globs into model context as a developer message — "The active permission profile denies reading these paths/globs" (source) — so the names of denied paths reach the model (C4 ◐, B1 ◐). The enforcement substrate is an OS sandbox (macOS Seatbelt, Linux bubblewrap): "The sandbox applies to spawned commands, not just to built-in file operations", and commands like git or test runners "inherit the same sandbox boundaries" (sandboxing) (B2/B3 ●, D1 ●); rust-v0.162.0 fixed a crack in that substrate, where a user ripgrep config could leave "files matching deny globs unmasked" (#51527). "Subagents inherit your current sandbox policy" (subagents), but "Connectors, MCP servers, browser or computer-use surfaces, Codex cloud environment settings, and approved escalations use their own controls" (permissions) (D4 ◐). Whether an edited profile reaches a running session without a restart is undocumented; on Linux, WSL and Windows, deny-read globs are expanded when "Codex snapshots matches before sandbox startup" (B4 ?). On Linux, an approved command will "Preserve literal deny paths alongside resolved targets so Linux can reject denials that cross writable symlinks" (#48155) (D2 ◐). Approved commands "retain explicit filesystem denials" (rust-v0.159.0), and "Approved filesystem escalation can now grant broader write access while preserving denied reads" (rust-v0.161.0), yet :danger-full-access "removes local sandbox restrictions" (permissions) (C1 ◐). That blanket mode is the only lift short of editing the rule: there is no one-invocation override, and the model is told "Do not request escalation or additional permissions to read them" (D3 ○).

Pi 1.1.0

Ships no file-access rules: an issue on its tracker lists the only mechanisms as the coarse --tools flag, custom TypeScript hooks, and interactive confirmation (#4459, which proposed native allow/deny policy files and was auto-closed during a refactor: "Issues closed during this period will not be reviewed") (A1–B4 ○, C1–C4 and D1–D3 —). The security doc places safety outside the harness — "Safety comes from limiting the files, credentials, processes, and network services Pi can access and affect" — and spells out the consequence: the working folder "does not prevent commands from accessing other paths available to the Pi process", project trust "does not limit what tool calls can access or affect", and child processes "run with those same permissions" (D4 ○); it also counts "lack of a built-in sandbox" as expected behavior. What Pi does have is a deterministic enforcement point: the tool_call hook can block operations in host-side code before execution. The shipped permission-gate example blocks three pattern-matched bash commands (rm -rf, sudo, chmod/chown 777) when no UI is present, and a sibling protected-paths example blocks write/edit calls to a hard-coded list (.env, .git/, node_modules/). A policy layer could attach there, but these are opt-in examples: with no restriction shipped, there is nothing for the harness to enforce yet (D1 —).

Windsurf / Devin Devin Desktop 3.10.48, CLI 3000.11.3

.devinignore (with legacy .windsurfignore / .codeiumignore "still read and enforced alongside .devinignore"), gitignore syntax, one file at "the root of your repository": paths matched "are excluded from indexing and cannot be viewed, edited, or created by Devin" (docs) (A1/A3 ●, A2 ◐, A5 ◐, B3 ●); whether the names of ignored paths stay out of listings and context is not stated (B1 ◐). Since v3.9.19, "Cascade has been removed" and "Devin Local is now the only agent available in Devin Desktop" (changelog); Devin Local shares Devin CLI's permission rules, where "A deny rule always wins", and v3.7.16 has rules "from different levels (enterprise, mode, user, project, subagent) now compose predictably — an explicit deny: always wins". But the precedence table still ranks "Session-level grants (interactive approvals)" above project and user config, and only "Organization-level deny and ask rules cannot be overridden by project or user config" (C1 ◐). The same holds for Bypass mode, where "all tool calls are auto-approved without prompting": only organization rules are guaranteed against it (D3 ◐). Smart mode's model judgment "only applies where no rule already decides the call, so a deny rule blocks the action" (D1 ●); the .devinignore docs do not name where that file is enforced. An opt-in OS sandbox hides Read(...)-denied paths "from sandboxed commands entirely", "hidden for the whole session" (B2 ◐), and errs restrictive in places — non-Exec rules in sandbox.excluded are "ignored with a warning", and if sandbox resolution fails, the CLI "will refuse to start rather than running unsandboxed" — but not everywhere: on Linux, "unsupported glob rules are ignored and logged" (CLI v3000.4.16) (C2 ◐). The edit, write, apply_patch, and notebook_edit tools "now refuse to write through a symlink" (Desktop v3.6.27, CLI v3000.3.27), with reads unstated (D2 ◐), and background subagents "inherit any tool permissions you have already granted during the current session"; "Any tool that has not been pre-approved is automatically denied" (D4 ◐). Unstated: whether edits to rule files take effect mid-session (B4 ?), whether the agent is barred from editing .devinignore or .devin/config.json (C3 ?), and whether ignore patterns or rules enter model context (C4 ?).

Zed 1.23.2

private_files and read_only_files glob settings, project-resident (all settings); project settings files can also sit in subdirectories — "You can also add settings files in subdirectories for more granular control" (configuring Zed) — and the agent's file tools look the settings up for the path being accessed (source) (A1/A2/A3 ●). Tool permissions add path-matched always_deny rules for edit_file, write_file, delete_path, move_path and create_directory (B3 ●). Content of private files is gated, and list_directory and grep skip private entries, but find_path returns matching worktree entries without a private_files check (source), so names can still reach the model (B1 ◐). The terminal tool is governed by command-pattern rules, not path rules, and under the OS sandbox "Terminal commands can read most of the filesystem" (B2 ○). Fail direction is split: an invalid tool_permissions regex blocks the tool — "If any patterns failed to compile, block the tool call entirely" (source) — while v1.22.0 only stopped one invalid file pattern from discarding the valid exclusion/read-only/private rules beside it: the invalid entry itself is still dropped, only logged, and "If the combined set cannot be built, reports the error and matches nothing" (#64525, source) (C2 ◐). always_deny is "highest priority, cannot be overridden", and global auto-approve leaves "always_deny, always_confirm, built-in security rules, and paths inside Zed settings directories" still prompting or blocking (C1 ●). Agent edits inside .zed/, where project private_files live, always prompt (source), but sandboxed "Terminal commands can write inside open project directories, except for protected Git metadata" (C3 ◐). The sandbox's own restrictions lift through remembered grants, for "the rest of the current thread" or "always", up to allow_unsandboxed (D3 ◐). Subagents get "the same tools as the parent agent" (tools), so the file-tool checks carry, but processes spawned from the terminal are not bound by private_files, and the sandbox "does not sandbox … External Agents" (D4 ◐). Enforcement is deterministic editor code, confirmed by the project's own advisory for CVE-2026-27967: agent file tools checked private_files on logical paths, so symlinks escaped; patched in 0.225.9. Today, symlinks resolving outside the project trigger an always-prompt, while the private check still runs on the project-relative path (D1 ●, D2 ◐). Not documented: whether a settings edit reaches a running agent before its next operation (B4 ?), and whether private-file patterns or names enter model context (C4 ?). Rules name no agent (A4 ○) and use Zed's own settings format (A5 ○).