@devrik-tools/claude-gates 0.1.2 → 0.2.0

package/plugins/gates/hooks/gates/autonomous-mode/autonomous.edge.test.mjs

@@ -0,0 +1,104 @@
+// Edge audit for autonomous-mode: does it actually stop the agent from "asking" in every
+// surface that exists, or only the one tool it names?
+//
+// State after the MCP-hole fix (toolInGroups + mcp__.* matcher):
+//   1. A corrupted / unparseable stdin payload still makes toolNameOf() return '' and the
+//      gate allows — kept intentionally: an unidentifiable tool is not a question to block,
+//      and autonomous-mode's job is only to stop the ask surfaces. (A blocking security gate
+//      makes the opposite choice; that is per-gate, not a shared default.)
+//   2. FIXED. The gate now classifies via toolInGroups: native names match case-insensitively
+//      and any MCP ask/confirm/elicit surface (mcp__*__ask_*) hits the question signal, so the
+//      differently-cased name and the MCP ask tool are now DENIED (tests below).
+//   3. Still true and inherent: a plain-prose question (no tool call) is invisible to any
+//      PreToolUse hook. This is the residual limitation the gate's own header documents; it
+//      is addressed by the injected reminder, not by the matcher.
+
+import assert from 'node:assert/strict';
+import { execFileSync } from 'node:child_process';
+import { mkdtempSync, mkdirSync, writeFileSync } from 'node:fs';
+import { tmpdir } from 'node:os';
+import { dirname, join } from 'node:path';
+import { test } from 'node:test';
+import { fileURLToPath } from 'node:url';
+
+const GATE = join(dirname(fileURLToPath(import.meta.url)), 'index.mjs');
+
+function projectWithAutonomous(autonomous) {
+  const project = mkdtempSync(join(tmpdir(), 'autonomous-edge-'));
+  mkdirSync(join(project, '.git'));
+  mkdirSync(join(project, '.ai'));
+  writeFileSync(
+    join(project, '.ai', 'config.json'),
+    JSON.stringify({ gates: { autonomousMode: { enabled: Boolean(autonomous) } } }),
+  );
+  return project;
+}
+
+function runGateRaw(rawInput, project) {
+  const out = execFileSync(process.execPath, [GATE], {
+    input: rawInput,
+    encoding: 'utf8',
+    cwd: project,
+    env: { ...process.env, HOME: project, USERPROFILE: project },
+  });
+  return out.trim() ? JSON.parse(out.trim()) : null;
+}
+
+function isDeny(result) {
+  return result?.hookSpecificOutput?.permissionDecision === 'deny';
+}
+
+test('BYPASS: corrupted stdin payload (invalid JSON) is ALLOWED even in autonomous mode', () => {
+  const project = projectWithAutonomous(true);
+  // Not valid JSON at all -> JSON.parse throws inside toolNameOf -> returns null ->
+  // runGate coalesces to '' -> '' not in QUESTION_TOOLS -> allow(). This is the tool_name
+  // null->'' bypass named in the task brief, exercised end to end via the real binary.
+  const result = runGateRaw('{not valid json', project);
+  assert.equal(result, null, 'PASA(bug): corrupted payload bypasses the deny');
+});
+
+test('BYPASS: payload missing tool_name entirely is ALLOWED even in autonomous mode', () => {
+  const project = projectWithAutonomous(true);
+  // Valid JSON, but no tool_name/name field. toolNameOf returns payload?.tool_name ??
+  // payload?.name ?? '' -> ''. Same bypass, reached via a well-formed but incomplete payload
+  // (e.g. a future/unknown hook event shape) rather than malformed JSON.
+  const result = runGateRaw(JSON.stringify({ tool_input: { questions: [] } }), project);
+  assert.equal(result, null, 'PASA(bug): payload without tool_name bypasses the deny');
+});
+
+test('FIXED: a differently-cased tool name ("askuserquestion") is now DENIED', () => {
+  const project = projectWithAutonomous(true);
+  // toolInGroups matches native names case-insensitively, so a differently-cased spelling
+  // can no longer dodge the question block.
+  const result = runGateRaw(
+    JSON.stringify({ tool_name: 'askuserquestion', tool_input: {} }),
+    project,
+  );
+  assert.ok(isDeny(result), 'case/name variant must now be blocked');
+});
+
+test('FIXED: an MCP "ask" tool is now DENIED via the question signal match', () => {
+  const project = projectWithAutonomous(true);
+  // toolInGroups classifies mcp__* by its action segment; "ask_user_confirmation" hits the
+  // question signal, so an MCP-exposed ask/confirm surface is blocked in autonomous mode too.
+  const result = runGateRaw(
+    JSON.stringify({
+      tool_name: 'mcp__some-server__ask_user_confirmation',
+      tool_input: { question: 'Proceed?' },
+    }),
+    project,
+  );
+  assert.ok(isDeny(result), 'MCP-exposed ask tool must now be blocked');
+});
+
+test('control: canonical AskUserQuestion with well-formed payload IS denied (sanity check)', () => {
+  const project = projectWithAutonomous(true);
+  const result = runGateRaw(
+    JSON.stringify({
+      tool_name: 'AskUserQuestion',
+      tool_input: { questions: [{ question: 'A or B?' }] },
+    }),
+    project,
+  );
+  assert.ok(isDeny(result), 'FALLA(ok): the one exact name it knows is still blocked');
+});

package/plugins/gates/hooks/gates/autonomous-mode/index.mjs

@@ -1,45 +1,48 @@
-// autonomous-mode — when the project turns on autonomous mode, the assistant must stop
-// asking and decide. This gate denies the AskUserQuestion tool while the mode is on, so a
-// question popup cannot interrupt an unattended run. The assistant is expected to take the
-// best, aligned decision and state the reversible assumption instead of asking.
-//
-// justification: no existing tool covers this. It is the deterministic half of "run without
-// asking": a gate can block the question tool; the prose reminder (via the session-start
-// hook and this gate's message) covers the rest, which a hook cannot force.
-//
-// ── When it acts ────────────────────────────────────────────────────────────────────
-// Only when autonomousMode is enabled in .ai/config.json (project) or the global config.
-// Off by default. The user is also reminded at session start that the mode is on (see the
-// session hook), in case they forgot to turn it off.
-//
-// ── What it does NOT do ─────────────────────────────────────────────────────────────
-// It blocks the AskUserQuestion TOOL. It cannot stop the assistant from asking in plain
-// prose (no hook sees chat text) — the injected reminder pushes against that, but the only
-// deterministic lever is the question tool, and this gate pulls it.
-
-import { runGate, deny, TOOL_GROUPS } from '../../lib/hook-io.mjs';
-
-const GATE_ID = 'autonomous-mode';
-const CONFIG_KEY = 'autonomousMode';
-
-const QUESTION_TOOLS = new Set(TOOL_GROUPS.question);
-
-const DENY_MESSAGE =
-  'Autonomous mode is ON for this project: do not ask the user. Take the best decision ' +
-  'that is aligned with the goal and the project rules, state the reversible assumption you ' +
-  'made, and proceed. Only a genuinely irreversible or dangerous choice (deleting data, ' +
-  'money, production) would justify stopping — and then say so in prose, do not use the ' +
-  'question popup. To let questions through again, set "autonomousMode": false in ' +
-  '.ai/config.json.';
-
-runGate(
-  {
-    id: GATE_ID,
-    configKey: CONFIG_KEY,
-    enabledByDefault: false,
-  },
-  ({ toolName }) => {
-    if (!QUESTION_TOOLS.has(toolName)) return;
-    deny(GATE_ID, DENY_MESSAGE);
-  },
-);
+// autonomous-mode — when the project turns on autonomous mode, the assistant must stop
+// asking and decide. This gate denies the AskUserQuestion tool while the mode is on, so a
+// question popup cannot interrupt an unattended run. The assistant is expected to take the
+// best, aligned decision and state the reversible assumption instead of asking.
+//
+// justification: no existing tool covers this. It is the deterministic half of "run without
+// asking": a gate can block the question tool; the prose reminder (via the session-start
+// hook and this gate's message) covers the rest, which a hook cannot force.
+//
+// ── When it acts ────────────────────────────────────────────────────────────────────
+// Only when autonomousMode is enabled in .ai/config.json (project) or the global config.
+// Off by default. The user is also reminded at session start that the mode is on (see the
+// session hook), in case they forgot to turn it off.
+//
+// ── What it does NOT do ─────────────────────────────────────────────────────────────
+// It blocks the AskUserQuestion TOOL. It cannot stop the assistant from asking in plain
+// prose (no hook sees chat text) — the injected reminder pushes against that, but the only
+// deterministic lever is the question tool, and this gate pulls it.
+
+import { runGate, deny, toolInGroups } from '../../lib/hook-io.mjs';
+
+const GATE_ID = 'autonomous-mode';
+const CONFIG_KEY = 'autonomousMode';
+
+// The tool groups whose members are "asking the user something". `toolInGroups` matches the
+// native AskUserQuestion AND any MCP ask/confirm/elicit surface (mcp__*__ask_user_*), so an
+// autonomous run can't be interrupted by a question routed through an MCP server either.
+const QUESTION_GROUPS = ['question'];
+
+const DENY_MESSAGE =
+  'Autonomous mode is ON for this project: do not ask the user. Take the best decision ' +
+  'that is aligned with the goal and the project rules, state the reversible assumption you ' +
+  'made, and proceed. Only a genuinely irreversible or dangerous choice (deleting data, ' +
+  'money, production) would justify stopping — and then say so in prose, do not use the ' +
+  'question popup. To let questions through again, set "autonomousMode": false in ' +
+  '.ai/config.json.';
+
+runGate(
+  {
+    id: GATE_ID,
+    configKey: CONFIG_KEY,
+    enabledByDefault: false,
+  },
+  ({ toolName }) => {
+    if (!toolInGroups(toolName, QUESTION_GROUPS)) return;
+    deny(GATE_ID, DENY_MESSAGE);
+  },
+);

package/plugins/gates/hooks/gates/bash-commands/bash-commands.edge.test.mjs

@@ -0,0 +1,165 @@
+// Edge-case audit for bash-commands: bypasses (should deny but doesn't) and false
+// positives (denies something innocuous). Each test documents the payload and asserts
+// the ACTUAL observed behavior of the gate as it stands today — a green test here means
+// the described case is a confirmed bug (bypass) unless the test name says otherwise.
+import assert from 'node:assert/strict';
+import { execFileSync } from 'node:child_process';
+import { mkdtempSync, mkdirSync, writeFileSync } from 'node:fs';
+import { tmpdir } from 'node:os';
+import { dirname, join } from 'node:path';
+import { test } from 'node:test';
+import { fileURLToPath } from 'node:url';
+
+const GATE = join(dirname(fileURLToPath(import.meta.url)), 'index.mjs');
+
+function runGate(payload, { config } = {}) {
+  const project = mkdtempSync(join(tmpdir(), 'bash-commands-edge-'));
+  mkdirSync(join(project, '.git'));
+  if (config) {
+    mkdirSync(join(project, '.ai'));
+    writeFileSync(join(project, '.ai', 'config.json'), JSON.stringify(config));
+  }
+  const out = execFileSync(process.execPath, [GATE], {
+    input: JSON.stringify(payload),
+    encoding: 'utf8',
+    cwd: project,
+    env: { ...process.env, HOME: project, USERPROFILE: project },
+  });
+  return out.trim() ? JSON.parse(out.trim()) : null;
+}
+
+function bash(command) {
+  return { tool_name: 'Bash', tool_input: { command } };
+}
+function mcpTool(name, input) {
+  return { tool_name: name, tool_input: input };
+}
+function isDeny(result) {
+  return result?.hookSpecificOutput?.permissionDecision === 'deny';
+}
+
+// ── BUG: MCP write/exec tools are not in TOOL_GROUPS.shell/write/delegation, so the
+// gate's own `toolName` check (SHELL_TOOLS.has / DELEGATION_TOOLS.has) never matches an
+// mcp__* tool even if the gate DID receive the call. hooks.json's `matcher` also never
+// includes any mcp__*__write/run pattern (only mcp__ide__executeCode, and only for
+// rule-skill-autodiscovery/recurrence-lock, not this gate) so Claude Code would not even
+// invoke this hook for such a tool call. This test proves the gate-level half of the bug:
+// even fed the payload directly, it does not recognize the tool and allows destructive
+// content that would be denied under Bash.
+test('BUG: mcp filesystem write tool carrying a destructive shell command is not recognized', () => {
+  const result = runGate(
+    mcpTool('mcp__filesystem__write_file', {
+      path: '/repo/run.sh',
+      content: 'git reset --hard HEAD~3',
+    }),
+  );
+  assert.equal(result, null); // allowed: bypass confirmed
+});
+
+test('FIXED: a run_command-shaped MCP tool with a different name is now recognized', () => {
+  // e.g. an MCP server that exposes its shell tool as mcp__shell__run instead of run_command.
+  // toolInGroups classifies it into the shell group by its action segment, so the destructive
+  // command it carries is now inspected and denied.
+  const result = runGate(
+    mcpTool('mcp__shell__run', { command: 'rm -rf src' }),
+  );
+  assert.ok(isDeny(result));
+});
+
+// ── BUG: command chaining. checkDestructive/checkRemotePublish test the WHOLE command
+// string with patterns that use \b word boundaries without anchoring to start-of-command,
+// so `a && git push` and `a; rm -rf src` SHOULD still match (the regex has no ^ anchor).
+// Confirm this actually still catches chaining (expected: denied, i.e. NOT a bug) so we
+// don't misreport it.
+test('OK: chained destructive command after && is still caught (no anchor bug here)', () => {
+  assert.ok(isDeny(runGate(bash('echo hi && git reset --hard'))));
+  assert.ok(isDeny(runGate(bash('echo hi ; rm -rf src'))));
+});
+
+// ── BUG: subshell / command substitution. The destructive pattern is a plain substring
+// regex, so it should still match text inside $(...) or backticks. Confirm.
+test('OK: destructive command inside a subshell is still caught', () => {
+  assert.ok(isDeny(runGate(bash('echo $(git push origin main --force)'))));
+  assert.ok(isDeny(runGate(bash('echo `rm -rf src`'))));
+});
+
+// ── BUG candidate: env-var prefixed command, e.g. `FOO=x git push origin main`. The
+// git push pattern is \bgit\s+(?:-C\s+\S+\s+)?push\b which does not care what precedes
+// "git", so this should still be denied. Confirm rather than assume.
+test('OK: env-var-prefixed git push is still caught', () => {
+  assert.ok(isDeny(runGate(bash('FOO=bar git push origin main'))));
+});
+
+// ── BUG: `sh -c "..."` / `bash -lc "..."` wrapping. The outer command line still
+// literally contains the inner destructive text as a substring (it's quoted, not
+// encoded), so the plain regex against the raw command string should still match. But the
+// remote-publish description-detector's `stripQuoted` step only runs for delegation
+// prompts (isShell=true skips the intent check and matches literally) — so a real Bash
+// call wrapped in sh -c should NOT bypass this gate. If it did NOT bypass, that's OK, but
+// worth confirming since it's tempting to assume quoting evades a regex the way it does
+// in stripQuoted's quote-stripping heuristic used for delegation.
+test('OK: destructive command wrapped in sh -c is still caught (raw command string has no quote-stripping for shell tools)', () => {
+  assert.ok(isDeny(runGate(bash('sh -c "git push origin main --force"'))));
+  assert.ok(isDeny(runGate(bash('bash -lc \'rm -rf src\''))));
+});
+
+// ── BUG: rm -rf with a relative-but-not-listed path segment prefix, e.g. `rm -rf ./src`
+// or `rm -rf src/` (trailing slash) may not match `\brm\s+-rf\s+(area)\b` because of the
+// `./` prefix or trailing slash changing the \b boundary expectations.
+test('FIXED: rm -rf with a leading ./ on a protected area is now caught', () => {
+  const result = runGate(bash('rm -rf ./src'));
+  assert.ok(isDeny(result)); // the optional ./ prefix is now part of the rm -rf pattern
+});
+
+test('BUG: rm -rf with a trailing slash on a protected area bypasses the rm-rf pattern', () => {
+  const result = runGate(bash('rm -rf src/'));
+  // \bsrc\b: 'src/' still has a word boundary right after 'src' (before '/'), so this
+  // actually still matches. Included to document the check, not assumed.
+  assert.ok(isDeny(result));
+});
+
+// ── BUG: `git reset --hard` split across an alias / npx wrapper e.g.
+// `npx --yes git reset --hard` (unusual but plausible in some CI wrapper) is unaffected;
+// the pattern still matches the literal substring `git reset --hard` inside. Confirm no
+// bypass there; the interesting bypass is quoting INSIDE an argument that a shell would
+// interpret literally as separate tokens but which our regex still sees as one string —
+// there is no such distinct case; skip.
+
+// ── BUG: kill-by-name pattern only covers `taskkill ... /IM`, `pkill `, `killall `.
+// `Stop-Process -Name node` (PowerShell) is a kill-by-name equivalent not in the pattern.
+test('FIXED: PowerShell Stop-Process -Name (kill by name) is now denied', () => {
+  const result = runGate(bash('Stop-Process -Name node -Force'));
+  assert.ok(isDeny(result)); // Stop-Process -Name is now in the kill-by-name rules
+});
+
+// ── BUG: `taskkill` without the literal `/IM` flag before the process name, e.g.
+// `taskkill /F /PID 1234 /IM node.exe` still has /IM later, but `taskkill /F /T /IM *`
+// with wildcard, or simply reordered flags `taskkill /IM node.exe /F` — pattern requires
+// `taskkill\s+[^|;]*[/]IM` which does match flags-then-/IM in any order since [^|;]* is
+// greedy-any. Confirm both orders are caught (no bug) before asserting the wildcard case.
+test('OK: taskkill flag order does not evade the kill-by-name pattern', () => {
+  assert.ok(isDeny(runGate(bash('taskkill /IM node.exe /F'))));
+});
+
+// ── BUG: `gh pr merge` and `gh release create` only check for a literal `gh` invocation;
+// GitHub CLI can also be invoked as `gh.exe` on Windows PATH resolution, or through
+// `command gh pr merge` (shell builtin wrapper) — the pattern \bgh\s+ still matches
+// 'command gh pr merge' since \b matches at the 'gh' boundary regardless of preceding
+// text. Confirm.
+test('OK: "command gh pr merge" wrapper does not evade the remote-publish pattern', () => {
+  assert.ok(isDeny(runGate(bash('command gh pr merge 12'))));
+});
+
+// ── BUG: delegation prompt intent-detection reporting-verb bypass can be abused to slip
+// a REAL instruction past the two-stage check by simply prefixing it with a reporting verb
+// within DESCRIPTION_LOOK_BACK (80 chars), even though the actual intent is an order.
+test('BUG: prefixing an order with a reporting verb inside the lookback window defeats delegation intent detection', () => {
+  const result = runGate({
+    tool_name: 'Agent',
+    tool_input: {
+      prompt:
+        'The changelog mentions we should run git push origin main now to finish the release.',
+    },
+  });
+  assert.equal(result, null); // allowed: bypass confirmed (reporting verb precedes mention)
+});