@bridge4dev/runner 0.13.1 → 0.22.1

package/dist/policy.js

@@ -36,7 +36,14 @@ const SECRET_PATTERNS = [
         label: 'secret-assignment',
         // The negative lookahead keeps an already-masked value from being masked a
         // second time under a less precise label.
-        re: /\b([A-Za-z0-9_]*(?:SECRET|PASSWORD|PASSWD|TOKEN|API_?KEY|APIKEY|ACCESS_?KEY|PRIVATE_?KEY)[A-Za-z0-9_]*)(\s*[:=]\s*)['"]?(?!\[MASKED:)[^\s'"]{12,}['"]?/gi,
+        //
+        // The prefix is lazy AND bounded (`{0,64}?`) rather than `*`: masking runs
+        // over whole diffs and whole build logs, and an unbounded greedy prefix
+        // rescans the identifier from every offset — quadratic, which a file full
+        // of `TOKENTOKEN…` turns into half a second per 50 KB and seven seconds
+        // per diff. No real variable name carries 64 characters in front of the
+        // word `SECRET`.
+        re: /\b([A-Za-z0-9_]{0,64}?(?:SECRET|PASSWORD|PASSWD|TOKEN|API_?KEY|APIKEY|ACCESS_?KEY|PRIVATE_?KEY)[A-Za-z0-9_]*)(\s*[:=]\s*)['"]?(?!\[MASKED:)[^\s'"]{12,}['"]?/gi,
         to: '$1$2[MASKED:secret-assignment]',
     },
 ];
@@ -73,6 +80,23 @@ const SECRET_PATH_PATTERNS = [
     /(^|\/)\.claude\/\.credentials\.json$/,
     /(^|\/)\.codex\/auth\.json$/,
     /(^|\/)devbridge-runner\/config\.toml$/,
+    // Ticket #119: the per-session MCP config the runner writes for the CLI. It
+    // holds the project's live `dbk_…` key, and the agent runs as the same uid,
+    // so 0600 alone protects nothing — these entries are what actually do.
+    //
+    // The basename rule holds wherever stateDir() resolves to, including under a
+    // DEVBRIDGE_RUNNER_HOME override where the path carries no `devbridge-runner`
+    // segment. The directory rule covers the WHOLE runner tree, not just `mcp/`:
+    // `Grep {path: '…/devbridge-runner'}` searches a DIRECTORY by design, so a
+    // rule scoped to `mcp/` let the parent through and `output_mode: content`
+    // handed the key straight back (QA-114 MAJOR-2). Same shape as `.aws(\/|$)`
+    // and `.kube(\/|$)` above, and it covers `config.toml` a second time.
+    //
+    // The exclusions are NOT optional. `worktrees/` and `previews/` live under the
+    // same runner directory, so a blanket rule here denies the agent every file in
+    // its own workspace — caught by the existing suite the moment it was tried.
+    /(^|\/)devbridge-mcp\.[^/]*\.json$/,
+    /(^|\/)devbridge-runner(\/(?!worktrees(\/|$)|previews(\/|$))|$)/,
     /(^|\/)(shadow|passwd|sudoers)$/,
     /(^|\/)\.netrc$/,
     /(^|\/)\.git-credentials$/,
@@ -92,6 +116,13 @@ const SECRET_PATH_PATTERNS = [
     /(^|\/)terraform\.tfstate(\.backup)?$/,
     /(^|\/)[^/]*credentials[^/]*\.(json|ya?ml|ini|txt)$/i,
     /\.(key|p12|pfx|jks|keystore)$/i,
+    // Session 13: git-forge CLIs keep a live OAuth token in plain text, and this
+    // is the release that puts a Push button next to the agent. A token that can
+    // push is exactly as dangerous as the ssh key two lines up.
+    /(^|\/)\.config\/gh(\/|$)/,
+    /(^|\/)\.config\/glab-cli(\/|$)/,
+    /(^|\/)\.config\/hub$/,
+    /(^|\/)\.config\/gcloud(\/|$)/,
 ];
 function normalize(p, cwd) {
     const expanded = p.startsWith('~') ? path.join(os.homedir(), p.slice(1)) : p;
@@ -118,6 +149,26 @@ export function isInsideWorktree(p, worktreePath) {
     const rel = path.relative(path.resolve(worktreePath), p);
     return rel === '' || (!rel.startsWith('..') && !path.isAbsolute(rel));
 }
+/**
+ * Anything inside a `.git` directory (session 16, QA-110 B2).
+ *
+ * This became load-bearing the day DIRECT mode made the repository ROOT the
+ * agent's confinement. In a linked worktree the real `.git` lives elsewhere, so
+ * «outside the worktree» happened to cover it; in the project folder it sits
+ * right there, one level down, and «inside the worktree» happened to allow it.
+ *
+ * A file in `.git/hooks/` is not data — it is code git runs on the next commit,
+ * outside every rule on the Bash denylist, including the `git clean` and
+ * `git reset --hard` this same session added to it. `.git/config` is worse: it
+ * can set `core.fsmonitor` or a credential helper and run a command on the very
+ * next git invocation. Neither is ever ordinary agent work.
+ */
+export function isGitInternalPath(p) {
+    return path
+        .resolve(p)
+        .split(path.sep)
+        .some((segment) => segment === '.git');
+}
 // ─── Command rules (Bash tool) ───────────────────────────────────────
 // String-level checks can never be a perfect shell parser (QA-96 F8/F9), so
 // the model is: deny patterns run against BOTH the raw command and a
@@ -125,11 +176,60 @@ export function isInsideWorktree(p, worktreePath) {
 // and the NORMAL-mode safe list applies ONLY to commands with no shell
 // metacharacters at all — anything with ; & | $( ` > < newline falls
 // through to "ask". A prompt-injected agent can therefore at worst ask.
-// `git <flags> push` — flags like -C/-c must not hide the subcommand.
-const GIT_PUSH = String.raw `git\s+(?:-\S+\s+|-C\s+\S+\s+|-c\s+\S+\s+)*push`;
+/**
+ * A run of `-f`, `--project-name=x`, `-p x` flags.
+ *
+ * The value is `[^\s-]\S*` rather than `\S+` on purpose: a value that cannot
+ * itself start with a dash removes the ambiguity between «this is the flag's
+ * argument» and «this is the next flag», which is what would otherwise make
+ * this pattern backtrack quadratically on a long command.
+ */
+const FLAGS = String.raw `(?:-{1,2}[A-Za-z0-9][A-Za-z0-9-]*(?:[= ][^\s-]\S*)?\s+)*`;
+/**
+ * `git <flags> push` — flags like `-C`/`-c` must not hide the subcommand.
+ *
+ * Uses the same unambiguous `FLAGS` run as the docker rules, and that is a
+ * denial-of-service fix rather than tidying. The previous form was
+ * `(?:-\S+\s+|-C\s+\S+\s+|-c\s+\S+\s+)*`, whose three alternatives can each
+ * consume the same input, so a command that never reaches `push` made the
+ * engine try every partition of the flag run: `git ` + `-c ` ×34 took 300 ms,
+ * ×44 minutes. Every Bash call the agent proposes is tested against this
+ * synchronously, so one such string froze the runner — and every other session
+ * on the machine with it — from inside a normal turn.
+ */
+const GIT_PUSH = String.raw `\bgit\s+${FLAGS}push\b`;
+const DOCKER = String.raw `\bdocker\s+${FLAGS}`;
+/** `docker compose …` and the legacy `docker-compose …` binary. */
+const DOCKER_COMPOSE = String.raw `(?:${DOCKER}compose\s+${FLAGS}|\bdocker-compose\s+${FLAGS})`;
+/**
+ * The management-command nouns: `docker container stop` is `docker stop`.
+ *
+ * Docker has had two spellings of every destructive verb since 1.13, and the
+ * modern one — the one its own documentation uses — puts an object between the
+ * binary and the verb. Session 14 rewrote this rule so that flags could not
+ * hide the subcommand and stopped there, so `docker container stop <name>`,
+ * `docker volume rm`, `docker image rm`, `docker network rm` and
+ * `docker system prune` were all still allowed, in every trust mode. On a
+ * machine that also runs the customer's production stack — which is exactly
+ * where a dev runner lives — that is the whole rule missing its target.
+ */
+const DOCKER_OBJECT = String.raw `(?:container|volume|network|image|images|system|builder|buildx|stack|service|node|swarm|plugin|secret|config|context)\s+${FLAGS}`;
+/**
+ * State-changing verbs. `prune` and `start`/`pause` join the session-14 set:
+ * the rule is «docker control is not allowed», and freeing somebody else's
+ * build cache or starting a container is control. Read verbs (`ps`, `logs`,
+ * `inspect`) stay allowed — the agent has to be able to look.
+ */
+const DOCKER_VERB = String.raw `(?:stop|rm|rmi|kill|restart|start|pause|unpause|prune)`;
 const DENIED_COMMAND_PATTERNS = [
-    // `(`/`$(`/backtick before sudo covers command substitution.
-    { reason: 'sudo is not allowed', re: /(^|[\s;&|`(])sudo\b/ },
+    // `(`/`$(`/backtick before sudo covers command substitution; a leading path
+    // (`/usr/bin/sudo`) and a backslash-escaped name (`\sudo`, which the shell
+    // reads as plain `sudo`) are the two forms that used to walk straight past a
+    // rule that only looked for a word boundary in front (found in QA-108).
+    { reason: 'sudo is not allowed', re: /(^|[\s;&|`(])(?:[\w./\\-]*\/)?\\?sudo\b/ },
+    { reason: 'sudo is not allowed', re: /(^|[\s;&|`(])(?:doas|pkexec)\b/ },
+    // The two specific push rules stay ahead of the blanket one purely so the
+    // agent is told the most useful thing when it tries the worst version.
     {
         reason: 'force-push is not allowed',
         re: new RegExp(`${GIT_PUSH}[^;&|]*(\\s--force\\b|\\s-f\\b|\\s\\+\\S+)`),
@@ -139,6 +239,42 @@ const DENIED_COMMAND_PATTERNS = [
         reason: 'push to a protected branch is not allowed',
         re: new RegExp(`${GIT_PUSH}[^;&|]*[\\s:](main|master)\\b`),
     },
+    // Session 13, owner's decision 2026-07-27: agents never push, at all.
+    //
+    // Until now only force-push and push-to-main were denied, and a plain
+    // `git push` was not on the NORMAL-mode safe list — which reads like a
+    // refusal but is not one: under AUTO trust the Bash branch returns `allow`
+    // before the safe list is ever consulted, so an ordinary push went out
+    // silently. Pushing is an outgoing write to somebody else's repository; it
+    // belongs to the human who owns the credentials, behind a button.
+    {
+        reason: 'git push is not allowed — a human presses «Push» in the Git panel',
+        re: new RegExp(GIT_PUSH),
+    },
+    /**
+     * The two git commands that destroy work nobody has committed (session 16).
+     *
+     * This became urgent the day a session's working folder stopped being a
+     * private worktree and became the PERSON'S OWN project folder. In there,
+     * `git clean -fd` deletes their untracked files — the planning documents that
+     * went that way on 2026-07-28 existed nowhere else — and `git reset --hard`
+     * throws away every uncommitted edit in the tree, theirs included.
+     *
+     * Denied outright rather than left to a permission card, because under AUTO
+     * trust there is no card: Bash is allowed before the safe list is consulted,
+     * exactly as with `git push`. An agent that needs to remove build output can
+     * name the paths; an agent that wants to undo its own work has `git checkout
+     * -- <file>`, and the person has «Discard» in the Git panel with a
+     * confirmation that says how many files it is about to delete.
+     */
+    {
+        reason: 'git clean is not allowed — it deletes files git is not tracking, and that folder may be somebody else’s. Remove the paths you mean by name.',
+        re: new RegExp(String.raw `\bgit\s+${FLAGS}clean\b`),
+    },
+    {
+        reason: 'git reset --hard is not allowed — it throws away every uncommitted change in the folder, including the human’s. Use «Discard» in the Git panel, or `git checkout -- <file>`.',
+        re: new RegExp(String.raw `\bgit\s+${FLAGS}reset\b[^;&|]*--hard\b`),
+    },
     {
         reason: 'service control is not allowed',
         re: /\b(systemctl|service)\s+(stop|disable|mask|restart|kill)\b/,
@@ -159,8 +295,54 @@ const DENIED_COMMAND_PATTERNS = [
     },
     { reason: 'firewall changes are not allowed', re: /\b(iptables|nft|ufw|firewall-cmd)\b/ },
     {
+        id: 'docker-control',
         reason: 'docker control is not allowed',
-        re: /\bdocker\s+(stop|rm|kill|restart|compose\s+down)\b/,
+        // Flags must not hide the subcommand — the same lesson `GIT_PUSH` above
+        // encodes. Session 14 found this the hard way: the previous form required
+        // `compose` and `down` to be ADJACENT, so `docker compose -p devbridge down`
+        // and `docker compose -f x.yml down` sailed straight past — for the agent's
+        // Bash tool too, in every trust mode, since session 4. `docker-compose` (the
+        // legacy binary) was not covered at all.
+        // Both forms of the verb: `docker stop x` AND `docker compose stop`. The
+        // first rewrite of this rule (session 14) covered only `compose down`, so
+        // `docker compose stop` — which takes the same stack down, just politely —
+        // was still allowed.
+        //
+        // Session 15 adds the third spelling, and it was the one that mattered
+        // most: `docker container stop`. See `DOCKER_OBJECT`.
+        re: new RegExp(`${DOCKER}(?:${DOCKER_OBJECT})?${DOCKER_VERB}\\b` +
+            `|${DOCKER_COMPOSE}(?:down|stop|kill|rm|restart|pause)\\b`),
+    },
+    /**
+     * Same rule as `docker`, for the CLI that is deliberately identical to it.
+     *
+     * Podman ships a `docker` alias on many distributions and takes the same
+     * verbs; a denylist that names only one binary is a denylist that names the
+     * one the agent did not use.
+     */
+    {
+        // A DIFFERENT id from the docker rule on purpose. The preview carve-out
+        // below re-tests the rule that fired, and an id shared with docker would
+        // hand a podman command the docker regex — which matches none of its
+        // segments, so every segment would «pass» and the whole thing would be
+        // lifted. A carve-out that only ever meant `docker compose down` must not
+        // widen because two rules happened to share a name.
+        id: 'podman-control',
+        reason: 'container control is not allowed',
+        re: new RegExp(`\\bpodman(?:-compose)?\\s+${FLAGS}(?:${DOCKER_OBJECT})?(?:${DOCKER_VERB}|down)\\b`),
+    },
+    /**
+     * An inline git alias is a `push` with a different name.
+     *
+     * `git -c alias.p=push p origin main` runs a push while containing no
+     * `push` subcommand for the rule above to find — and the rule above is
+     * absolute («agents never push»), so a rule that a rename defeats is not
+     * the rule it claims to be. Nothing the agent legitimately does needs to
+     * define an alias, so the whole construct is refused rather than parsed.
+     */
+    {
+        reason: 'git aliases are not allowed — they can rename a forbidden command; a human presses «Push» in the Git panel',
+        re: /\bgit\s[^;&|]*\balias\./i,
     },
 ];
 // Commands considered safe enough to run without asking under NORMAL trust.
@@ -174,10 +356,36 @@ const SAFE_COMMAND_PATTERNS = [
 ];
 // Shell metacharacters that can smuggle a second command past the safe list.
 const SHELL_METACHARS = /[;&|`$<>\n]/;
-// Claude Code's idiomatic commit body — `$(cat <<'EOF' … EOF\n)` with a
-// QUOTED delimiter runs exactly `cat` on a literal heredoc; whitelisting it
-// keeps `git commit` auto-allowed under NORMAL without opening $() in general.
-const SAFE_COMMIT_HEREDOC = /\$\(cat <<'EOF'\n[\s\S]*?\nEOF\n\s*\)/g;
+/**
+ * Claude Code's idiomatic commit body — `$(cat <<'EOF' … EOF\n)`.
+ *
+ * With a QUOTED delimiter this runs exactly `cat` on a literal heredoc, so
+ * whitelisting it keeps `git commit` auto-allowed under NORMAL without opening
+ * `$()` in general. The body is then removed before the metacharacter check,
+ * because a commit message legitimately contains `$`, backticks and newlines.
+ *
+ * The tempered token `(?:(?!\nEOF\n)[\s\S])*` is the whole security of this
+ * rule, and `[\s\S]*?` was not enough (session 15). Lazy still BACKTRACKS: on
+ *
+ *     git commit -m "$(cat <<'EOF'
+ *     chore: tidy
+ *     EOF
+ *     $(touch /tmp/pwned)
+ *     EOF
+ *     )"
+ *
+ * it stretched to the LAST `EOF\n)` and deleted the nested `$( … )` with the
+ * rest — leaving `git commit -m ""`, which is on the safe list, so the verdict
+ * was `allow` with no permission card at all. The shell disagrees: a quoted
+ * heredoc ends at the FIRST line equal to the delimiter, so `touch` really
+ * runs (verified with `/bin/sh`). Swap `touch` for `curl … | sh` and that is
+ * silent remote code execution on the user's machine under the DEFAULT trust
+ * mode, with nothing on the denylist involved.
+ *
+ * The tempered form cannot cross an `EOF` line, so it matches exactly what the
+ * shell treats as the heredoc — and anything after it survives into the check.
+ */
+const SAFE_COMMIT_HEREDOC = /\$\(cat <<'EOF'\n(?:(?!\nEOF\n)[\s\S])*\nEOF\n\s*\)/g;
 function isSafeCommand(command) {
     // `a && b` / `a; b` chains are safe only when EVERY segment is safe on its
     // own; any other metacharacter ( | $( ` > < & \n ) disqualifies outright.
@@ -205,13 +413,177 @@ const SECRET_COMMAND_PATTERNS = [
     /\.codex\/auth\.json/,
     /\.docker\/config\.json/,
     /devbridge-runner\/config\.toml/,
+    // Ticket #119 — the command form of the MCP-config entries above. Without it
+    // `cat …/devbridge-mcp.<id>.json` walks straight past the Read-tool guard.
+    //
+    // Matched against the LITERAL command text, so anything the shell expands
+    // itself defeats a narrow pattern: `…/devbridge-runner/*/*.json` and
+    // `…/devbridge-runner/m*p/*` both dodged the original `devbridge-runner/mcp`
+    // (QA-114 BLOCKER-1). Hence the whole runner directory, not just `mcp/`.
+    //
+    // Honest about what this still does NOT stop: a path that never spells
+    // `devbridge-runner` at all — `grep -r dbk_ /root/.local/state/`, or
+    // `/root/.local/state/*/mcp/*`. Closing that needs `cat`/`grep` with an
+    // absolute path outside the worktree to stop counting as a safe command,
+    // which is a product-wide trust-mode change and its own ticket. What makes
+    // the residue small is that the file now exists for about a second
+    // (`publishCapabilities` unlinks it), not for the life of the session.
+    // Two rules, and the exclusion in the first is NOT optional: `worktrees/` and
+    // `previews/` sit under the same directory, so a blanket match would deny
+    // every ordinary `cat <abs path>/src/foo.ts` in the agent's own workspace.
+    //   1. any path under the runner directory that is not the workspace
+    //   2. the bare directory name, for `grep -r … /…/devbridge-runner`
+    // Accepted cost of rule 2: `devbridge-runner doctor` is refused too. Losing a
+    // diagnostic an operator can run by hand is the cheaper side of the trade.
+    // Just the distinctive stem, not `devbridge-mcp\.<id>\.json`: the command text
+    // is what the shell has not expanded yet, so `find … -name 'devbridge-mcp*'`
+    // never contains the suffix.
+    /devbridge-mcp/,
+    /devbridge-runner\/(?!worktrees|previews)/,
+    /devbridge-runner(?=\s|$|['"])/,
     /\/etc\/(shadow|passwd|sudoers)/,
     /\.git-credentials/,
     /\.netrc\b/,
+    // Session 13 — same list as SECRET_PATH_PATTERNS, in command form.
+    /\.config\/(gh|glab-cli|hub|gcloud)\b/,
 ];
 function commandMentionsSecretPath(command) {
     return SECRET_COMMAND_PATTERNS.some((re) => re.test(command));
 }
+/**
+ * Does this command name the compose project it claims to own?
+ *
+ * The literal project name, in one of the three forms compose accepts. A
+ * substring match would be a hole — `-p devbridge-preview` must not authorise a
+ * `down` on `devbridge`, and the anchors are what stop it.
+ */
+function namesDockerProject(command, project) {
+    // Resolve the project the way COMPOSE does, instead of searching for the
+    // approved name anywhere in the string (session 15).
+    //
+    // Compose takes the LAST `-p`/`--project-name`, and a flag beats
+    // `COMPOSE_PROJECT_NAME`. Searching for the name meant
+    //
+    //     COMPOSE_PROJECT_NAME=devbridge-preview docker compose -p devbridge down
+    //     docker compose -p devbridge-preview -p devbridge down
+    //
+    // both passed — the approved name IS in there — while compose tore down
+    // `devbridge`, which on a dev-runner machine is the production stack.
+    //
+    // So: collect every occurrence, require exactly ONE, require it to be ours,
+    // and refuse any disagreeing environment assignment.
+    const flags = [...command.matchAll(/(?:^|\s)(?:-p|--project-name)[=\s]+["']?([^\s"']+)["']?/g)];
+    const envs = [...command.matchAll(/(?:^|\s)COMPOSE_PROJECT_NAME=["']?([^\s"']+)["']?/g)];
+    const named = [...flags, ...envs].map((match) => match[1]);
+    if (named.length === 0)
+        return false;
+    return named.every((value) => value === project);
+}
+/**
+ * Layer 1 for a command that came out of an APPROVED project recipe.
+ *
+ * The semantics, fixed here rather than left to be discovered: **an approved
+ * recipe does not ask, but it cannot get past the denylist.** Both halves
+ * matter and neither is what `evaluateToolUse` would do on its own.
+ *
+ *  - It does not ask, because there is nobody to ask: a build runs for minutes
+ *    with no agent turn around it, and the human already read every command on
+ *    the approval screen. Running it through the strict-mode branch would turn
+ *    `docker compose up --build` — which is not on any safe list — into a
+ *    permission card nobody can answer.
+ *  - It cannot get past the denylist, because approval is a statement about a
+ *    build, not a grant of `sudo`, of the firewall, or of the machine's power
+ *    switch.
+ *
+ * One denial is liftable, and only one: `docker … down`. A preview that cannot
+ * tear its own stack down leaks containers forever, so a recipe that NAMES its
+ * compose project may run `down` on that project in its `stop` command — and
+ * nowhere else. Without the name, the refusal stands and says why.
+ */
+export function evaluateRecipeCommand(command, ctx = {}) {
+    for (const variant of [command, dequote(command)]) {
+        for (const { id, re, reason } of DENIED_COMMAND_PATTERNS) {
+            if (!re.test(variant))
+                continue;
+            if (id === 'docker-control') {
+                // The rule object itself, not a lookup by id: the carve-out has to
+                // re-test the very pattern that fired.
+                const lift = liftDockerControl(variant, ctx, re);
+                if (lift.lifted)
+                    continue;
+                return { allowed: false, reason: lift.reason ?? reason };
+            }
+            return { allowed: false, reason };
+        }
+        if (commandMentionsSecretPath(variant)) {
+            return { allowed: false, reason: 'the command touches protected secret paths' };
+        }
+    }
+    return { allowed: true };
+}
+/**
+ * May THIS command's docker control be allowed through?
+ *
+ * Decided per SEGMENT, not per command, and that distinction is the whole
+ * point. The first version skipped the rule for the entire string as soon as
+ * the project name appeared anywhere in it, so
+ *
+ *     docker compose -p mine down && docker stop the-real-stack
+ *
+ * was allowed on the strength of its first half (QA-108). Now every segment
+ * that touches docker control has to be a `down` on the named project by
+ * itself; one segment that is not sinks the whole command.
+ */
+function liftDockerControl(command, ctx, firedRule) {
+    if (!ctx.isPreviewStop)
+        return { lifted: false };
+    if (!ctx.dockerProject) {
+        return {
+            lifted: false,
+            reason: 'docker control is not allowed — set `preview.project` in the recipe to the compose project this preview owns, and the stop command may take that one down',
+        };
+    }
+    const project = ctx.dockerProject;
+    // Nesting is refused OUTRIGHT, before any segment is looked at (session 15).
+    //
+    // The per-segment check splits on `&& || ; & | \n` — and `$( … )`, backticks
+    // and process substitution start a command using NONE of those, so
+    //
+    //     docker compose -p devbridge-preview down $(docker stop devbridge-api)
+    //
+    // was one clean-looking segment and was lifted. QA-108 closed exactly this
+    // class for `&&` and chose a separator list, so the class survived in the
+    // form the list does not enumerate. A preview stop has no legitimate need
+    // for substitution at all, so the shape is refused rather than parsed.
+    if (/\$\(|`|\$\{|<\(|>\(/.test(command)) {
+        return {
+            lifted: false,
+            reason: 'docker control is not allowed — the preview stop command may not use command substitution',
+        };
+    }
+    // Every shell separator that can begin a new command. Segments that do not
+    // touch docker are somebody else's problem — the other rules in the loop
+    // above already ran against the whole string.
+    for (const segment of command.split(/&&|\|\||[;&|\n]/).map((part) => part.trim())) {
+        if (!firedRule.test(segment))
+            continue;
+        // `down`, and only `down`: `stop`/`kill`/`rm` on a named project stay
+        // refused, because removing its own stack is all a preview ever needs.
+        const isDown = new RegExp(`${DOCKER_COMPOSE}down\\b`).test(segment);
+        if (!isDown || !namesDockerProject(segment, project)) {
+            return {
+                lifted: false,
+                reason: `docker control is not allowed — only \`down\` on the preview's own compose project (\`${project}\`) is`,
+            };
+        }
+    }
+    return { lifted: true };
+}
+/**
+ * `git <flags> commit` — the same flag-tolerant shape as `GIT_PUSH`, and for
+ * the same reason: `git -C . commit` is a commit.
+ */
+const AGENT_COMMIT = new RegExp(String.raw `\bgit\s+${FLAGS}commit\b`);
 // ─── Tool-use evaluation ─────────────────────────────────────────────
 const READ_TOOLS = new Set(['Read', 'Glob', 'Grep', 'NotebookRead']);
 const WRITE_TOOLS = new Set(['Write', 'Edit', 'MultiEdit', 'NotebookEdit']);
@@ -232,6 +604,20 @@ export function evaluateToolUse(toolName, input, ctx) {
                 return { decision: 'deny', reason: 'command touches protected secret paths' };
             }
         }
+        // The project said the agent does not commit. Checked BEFORE the trust
+        // modes, exactly like the deny list above it: under AUTO the Bash branch
+        // returns `allow` before anything else is consulted, which is how «agents
+        // never push» quietly failed for a whole release (session 13).
+        if (ctx.agentAutoCommit === false) {
+            for (const variant of [command, dequote(command)]) {
+                if (AGENT_COMMIT.test(variant)) {
+                    return {
+                        decision: 'deny',
+                        reason: 'this project commits by hand — leave the changes in the working tree and a person presses «Commit» in the Git panel',
+                    };
+                }
+            }
+        }
         if (ctx.trustMode === 'STRICT')
             return { decision: 'ask', reason: 'strict mode' };
         if (ctx.trustMode === 'AUTO')
@@ -247,6 +633,22 @@ export function evaluateToolUse(toolName, input, ctx) {
         if (isSecretPath(resolved)) {
             return { decision: 'deny', reason: 'protected secret path' };
         }
+        // `Glob`'s target is its PATTERN, not its `path` — and nothing looked at it,
+        // so `Glob {pattern: '…/devbridge-runner/mcp/*.json'}` listed the file names
+        // under NORMAL without a card (QA-114 MAJOR-2). Names are not contents, but
+        // they hand over the exact sessionId for the next step. Tested against the
+        // raw string: a pattern is not a real path, so `normalize` would resolve it
+        // against the worktree and lose the very prefix that matters.
+        const rawPattern = String(input['pattern'] ?? '');
+        if (rawPattern && isSecretPath(rawPattern)) {
+            return { decision: 'deny', reason: 'protected secret path' };
+        }
+        if (WRITE_TOOLS.has(toolName) && isGitInternalPath(resolved)) {
+            return {
+                decision: 'deny',
+                reason: 'writing inside .git is not allowed — a hook or a config entry is code git runs on its own, past every rule here',
+            };
+        }
         if (WRITE_TOOLS.has(toolName) && !isInsideWorktree(resolved, ctx.worktreePath)) {
             return { decision: 'deny', reason: 'writes outside the session worktree are not allowed' };
         }