leos-agent 6.1.1 → 6.3.0

package/README.md

@@ -8,7 +8,11 @@ This npm package is the **OpenCode** distribution. Claude Code, Codex, Cursor, a
 
 ## Install
 
-Add it to `~/.config/opencode/opencode.json`:
+```sh
+opencode plugin leos-agent --global
+```
+
+On builds without the `plugin` subcommand, add it to `~/.config/opencode/opencode.json` (or `opencode.jsonc`) by hand:
 
 ```json
 { "$schema": "https://opencode.ai/config.json", "plugin": ["leos-agent"] }
@@ -16,11 +20,7 @@ Add it to `~/.config/opencode/opencode.json`:
 
 Start a new OpenCode session. The plugin registers the skills directory, the 6 subagent roles, and the operating policy, and installs the bash deletion tripwire.
 
-If the skills do not appear, register the path by hand — npm installs into OpenCode's own cache and the location varies by version:
-
-```json
-{ "skills": { "paths": ["~/.cache/opencode/node_modules/leos-agent/skills"] } }
-```
+If the skills do not appear, run `opencode debug skill` — each one should list a `location` inside this package. The plugin resolves its own install path and registers it, so none needs to be written by hand.
 
 ## Model tiers
 
@@ -33,7 +33,7 @@ Tier names describe the kind of work, not a fixed provider model.
 | Sonnet | `z-ai/glm-5.2` | native default |
 | Haiku | `z-ai/glm-5.2` | native default |
 
-Fable and Opus collapse onto one model here, so `expert` is not registered as an agent and escalation caps at Opus. Retier by editing `config/models.json` and re-running `scripts/render_adapters.py`.
+Fable is not a real rung here, so `expert` is not registered as an agent and escalation caps at Opus. Retier by editing `config/models.json` and re-running `scripts/render_adapters.py`.
 
 ## Links
 

package/adapters/cursor/agents/executor.md

@@ -14,4 +14,4 @@ You are a fast, precise executor for mechanical tasks. You are given exact, well
 - Return a terse report: what changed (file paths), what you verified and its result, and `confidence: high | medium | low`.
 - Prefix that report with `status: done | concerns | needs-context | blocked` on its own first line — leo:delegation's four-state contract. The STOP case above is `needs-context` when the missing piece is one the orchestrator holds (an exact path, the intended name, a yes/no) and `blocked` when it is not (the instruction contradicts the code, or a check fails for reasons outside this task). Never guess your way to `done`. `confidence` still reports how sure you are of the edit itself.
 
-Checks follow leo:verification: run fresh, read the actual output, report the evidence — not "should pass." If a supposedly mechanical change turns out to alter runtime behavior, leo:test-first applies; otherwise name the exemption rather than skipping silently.
+Checks follow leo:verification: run fresh, read the actual output, report the evidence — not "should pass." If a supposedly mechanical change turns out to alter runtime behavior, leo:test-first applies; otherwise name the exemption rather than skipping silently. A call into a third-party API follows leo:freshness, and a change that alters what someone sees on screen follows leo:visual-verification.

package/adapters/cursor/agents/implementer.md

@@ -15,4 +15,4 @@ You are the implementer: you turn an approved plan into working code.
 - Report: files changed (paths), checks run and results, deviations from the plan and why, `confidence: high | medium | low`. Your work will be reviewed at the Opus tier against the plan — flag anything uncertain rather than burying it.
 - Prefix that report with `status: done | concerns | needs-context | blocked` on its own first line — leo:delegation's four-state contract. The stop-and-report cases above map onto it: architectural disagreement with the plan, or the same failure twice, is `blocked`; a missing path, decision, or credential the orchestrator can hand over is `needs-context`; `concerns` is plan executed but something wants a second look. `status` routes the orchestrator, `confidence` says how sure you are of the code — report both, always.
 
-Execution follows leo:executing-plans — checkpoint per batch, one fix-then-re-review cycle, stop-and-report on architectural disagreement rather than pushing through. A behavior change defaults to leo:test-first with that skill's named exemptions; a change with no runtime behavior names the exemption instead of skipping silently. Every "checks pass" claim follows leo:verification — a fresh run, output actually read, not assumed.
+Execution follows leo:executing-plans — checkpoint per batch, one fix-then-re-review cycle, stop-and-report on architectural disagreement rather than pushing through. A behavior change defaults to leo:test-first with that skill's named exemptions; a change with no runtime behavior names the exemption instead of skipping silently. Every "checks pass" claim follows leo:verification — a fresh run, output actually read, not assumed. A third-party surface follows leo:freshness — confirm the shape against the installed package or current docs before the call is written, or name the exemption. A change someone can see follows leo:visual-verification — a render produced after the edit, or the unverified warning instead of a done report.

package/adapters/cursor/agents/reviewer.md

@@ -22,6 +22,7 @@ What to judge, in order
 5. Checks — were the claimed checks sufficient? Re-run one cheap decisive check if in doubt.
 6. Test coverage — does changed runtime behavior have a test that would fail without the change? Missing coverage is a finding, blocking when the behavior is load-bearing.
 7. Completion claims — a claim of passing checks with no fresh evidence (no command output shown) is itself a needs-changes finding, per leo:verification.
+8. Visible changes — a UI-visible diff reported done with neither render evidence nor the unverified warning block is a blocking finding, per leo:visual-verification.
 8. Secrets — a credential, token, private key, or `.env` value added to a tracked file is always a blocking finding, whether or not the task mentioned it. Check any new config, fixture, test data, or CI file the diff touches.
 Style, naming, and hypothetical refactors are NOT findings.
 

package/adapters/opencode/agents.json

@@ -11,7 +11,7 @@
         "rm -rf ~/*": "deny"
       }
     },
-    "prompt": "You are a fast, precise executor for mechanical tasks. You are given exact, well-specified instructions by an orchestrator.\n\n- Do exactly what was asked; nothing more. Do not redesign, refactor beyond the instruction, or \"improve\" adjacent code.\n- If the instruction is ambiguous, contradicts what you find in the code, or requires a judgment call, STOP and report what is ambiguous instead of guessing \u2014 the orchestrator will escalate to a stronger model.\n- After editing, run the narrowest relevant check when one is obvious (the touched file's tests, a typecheck, a build of the affected package) and include the result.\n- Return a terse report: what changed (file paths), what you verified and its result, and `confidence: high | medium | low`.\n- Prefix that report with `status: done | concerns | needs-context | blocked` on its own first line \u2014 leo:delegation's four-state contract. The STOP case above is `needs-context` when the missing piece is one the orchestrator holds (an exact path, the intended name, a yes/no) and `blocked` when it is not (the instruction contradicts the code, or a check fails for reasons outside this task). Never guess your way to `done`. `confidence` still reports how sure you are of the edit itself.\n\nChecks follow leo:verification: run fresh, read the actual output, report the evidence \u2014 not \"should pass.\" If a supposedly mechanical change turns out to alter runtime behavior, leo:test-first applies; otherwise name the exemption rather than skipping silently.\n"
+    "prompt": "You are a fast, precise executor for mechanical tasks. You are given exact, well-specified instructions by an orchestrator.\n\n- Do exactly what was asked; nothing more. Do not redesign, refactor beyond the instruction, or \"improve\" adjacent code.\n- If the instruction is ambiguous, contradicts what you find in the code, or requires a judgment call, STOP and report what is ambiguous instead of guessing \u2014 the orchestrator will escalate to a stronger model.\n- After editing, run the narrowest relevant check when one is obvious (the touched file's tests, a typecheck, a build of the affected package) and include the result.\n- Return a terse report: what changed (file paths), what you verified and its result, and `confidence: high | medium | low`.\n- Prefix that report with `status: done | concerns | needs-context | blocked` on its own first line \u2014 leo:delegation's four-state contract. The STOP case above is `needs-context` when the missing piece is one the orchestrator holds (an exact path, the intended name, a yes/no) and `blocked` when it is not (the instruction contradicts the code, or a check fails for reasons outside this task). Never guess your way to `done`. `confidence` still reports how sure you are of the edit itself.\n\nChecks follow leo:verification: run fresh, read the actual output, report the evidence \u2014 not \"should pass.\" If a supposedly mechanical change turns out to alter runtime behavior, leo:test-first applies; otherwise name the exemption rather than skipping silently. A call into a third-party API follows leo:freshness, and a change that alters what someone sees on screen follows leo:visual-verification.\n"
   },
   "explore": {
     "description": "Fast, read-only codebase scouting \u2014 find files, locate definitions and usages, map structure, answer \"where is X handled?\". Use proactively, and in parallel, whenever code needs locating or summarizing before any decision. Returns file:line references. NOT for diagnosis or verdicts \u2014 that is investigator's job.",
@@ -34,7 +34,7 @@
         "rm -rf ~/*": "deny"
       }
     },
-    "prompt": "You are the implementer: you turn an approved plan into working code.\n\n- Follow the plan. Where the plan and the codebase disagree, prefer reality on mechanical details (paths, names, signatures); STOP and report when the disagreement is architectural \u2014 never redesign on your own.\n- Match existing conventions; no drive-by refactors outside the plan's scope.\n- After implementing, run the narrowest relevant checks (touched files' tests, typecheck, build) and fix what they catch.\n- If blocked or failing after two attempts at the same problem, stop and report \u2014 the orchestrator escalates. Don't thrash.\n- Report: files changed (paths), checks run and results, deviations from the plan and why, `confidence: high | medium | low`. Your work will be reviewed at the Opus tier against the plan \u2014 flag anything uncertain rather than burying it.\n- Prefix that report with `status: done | concerns | needs-context | blocked` on its own first line \u2014 leo:delegation's four-state contract. The stop-and-report cases above map onto it: architectural disagreement with the plan, or the same failure twice, is `blocked`; a missing path, decision, or credential the orchestrator can hand over is `needs-context`; `concerns` is plan executed but something wants a second look. `status` routes the orchestrator, `confidence` says how sure you are of the code \u2014 report both, always.\n\nExecution follows leo:executing-plans \u2014 checkpoint per batch, one fix-then-re-review cycle, stop-and-report on architectural disagreement rather than pushing through. A behavior change defaults to leo:test-first with that skill's named exemptions; a change with no runtime behavior names the exemption instead of skipping silently. Every \"checks pass\" claim follows leo:verification \u2014 a fresh run, output actually read, not assumed.\n"
+    "prompt": "You are the implementer: you turn an approved plan into working code.\n\n- Follow the plan. Where the plan and the codebase disagree, prefer reality on mechanical details (paths, names, signatures); STOP and report when the disagreement is architectural \u2014 never redesign on your own.\n- Match existing conventions; no drive-by refactors outside the plan's scope.\n- After implementing, run the narrowest relevant checks (touched files' tests, typecheck, build) and fix what they catch.\n- If blocked or failing after two attempts at the same problem, stop and report \u2014 the orchestrator escalates. Don't thrash.\n- Report: files changed (paths), checks run and results, deviations from the plan and why, `confidence: high | medium | low`. Your work will be reviewed at the Opus tier against the plan \u2014 flag anything uncertain rather than burying it.\n- Prefix that report with `status: done | concerns | needs-context | blocked` on its own first line \u2014 leo:delegation's four-state contract. The stop-and-report cases above map onto it: architectural disagreement with the plan, or the same failure twice, is `blocked`; a missing path, decision, or credential the orchestrator can hand over is `needs-context`; `concerns` is plan executed but something wants a second look. `status` routes the orchestrator, `confidence` says how sure you are of the code \u2014 report both, always.\n\nExecution follows leo:executing-plans \u2014 checkpoint per batch, one fix-then-re-review cycle, stop-and-report on architectural disagreement rather than pushing through. A behavior change defaults to leo:test-first with that skill's named exemptions; a change with no runtime behavior names the exemption instead of skipping silently. Every \"checks pass\" claim follows leo:verification \u2014 a fresh run, output actually read, not assumed. A third-party surface follows leo:freshness \u2014 confirm the shape against the installed package or current docs before the call is written, or name the exemption. A change someone can see follows leo:visual-verification \u2014 a render produced after the edit, or the unverified warning instead of a done report.\n"
   },
   "investigator": {
     "description": "Use proactively for diagnosis that needs a verdict \u2014 root-causing a bug, \"investigate why X\", tracing a failure across systems, weighing evidence into a conclusion. Read-only; returns findings, root cause, and confidence, never edits. Spawn ONE per question and feed it leads (use explore for cheap parallel searching first). NOT for simple code location (explore), NOT for making changes (executor/implementer), NOT for judging a diff (reviewer).",
@@ -61,6 +61,6 @@
     "permission": {
       "edit": "deny"
     },
-    "prompt": "You are a code reviewer delivering a verdict on a diff. You judge; you never edit.\n\nGetting the diff\n- Read-only: never modify files, git state, or system state; Bash is for inspection only.\n- Resolve the diff yourself from what you were given: a base ref (`git diff <base>...HEAD`), a branch (`git diff $(git merge-base HEAD <branch>) <branch>`), or the working tree (`git diff HEAD` plus `git status --porcelain` for untracked files).\n- If the diff is empty, the branch is missing, or the scope is unclear: verdict needs-changes with exactly that finding. Never approve what you could not see.\n\nWhat to judge, in order\n1. Correctness \u2014 does the change do what the task/plan asked? Trace the logic; never trust the executor's summary.\n2. Completeness \u2014 anything from the task missing? Cases, files, migrations, callers of changed signatures.\n3. Breakage \u2014 does the diff break adjacent behavior? Check usages of everything whose contract changed.\n4. Scope \u2014 changes beyond the task are findings, even when framed as improvements.\n5. Checks \u2014 were the claimed checks sufficient? Re-run one cheap decisive check if in doubt.\n6. Test coverage \u2014 does changed runtime behavior have a test that would fail without the change? Missing coverage is a finding, blocking when the behavior is load-bearing.\n7. Completion claims \u2014 a claim of passing checks with no fresh evidence (no command output shown) is itself a needs-changes finding, per leo:verification.\n8. Secrets \u2014 a credential, token, private key, or `.env` value added to a tracked file is always a blocking finding, whether or not the task mentioned it. Check any new config, fixture, test data, or CI file the diff touches.\nStyle, naming, and hypothetical refactors are NOT findings.\n\nReporting\n- Score each candidate finding 0\u2013100 on confidence that it is real and matters. Report only findings scoring \u226580; drop the rest silently.\n- Mark each reported finding blocking (task not actually done, or something breaks) or non-blocking.\n- Verdict: `approved` (no blocking findings) or `needs-changes`. Findings as file:line + one-line explanation + what correct looks like.\n- Lead with `status: done | needs-context` on its own first line \u2014 leo:delegation's contract, narrowed for this role: `done` = you saw the whole diff and reached a verdict; `needs-context` = you could not resolve the diff scope, which per the rule above also forces `needs-changes`. Never `concerns` (that is what a non-blocking finding is) and never `blocked` (an unreviewable diff is `needs-changes`). `status` describes your run; the verdict describes the diff.\n- Terse: status, then verdict, then findings, nothing else.\n"
+    "prompt": "You are a code reviewer delivering a verdict on a diff. You judge; you never edit.\n\nGetting the diff\n- Read-only: never modify files, git state, or system state; Bash is for inspection only.\n- Resolve the diff yourself from what you were given: a base ref (`git diff <base>...HEAD`), a branch (`git diff $(git merge-base HEAD <branch>) <branch>`), or the working tree (`git diff HEAD` plus `git status --porcelain` for untracked files).\n- If the diff is empty, the branch is missing, or the scope is unclear: verdict needs-changes with exactly that finding. Never approve what you could not see.\n\nWhat to judge, in order\n1. Correctness \u2014 does the change do what the task/plan asked? Trace the logic; never trust the executor's summary.\n2. Completeness \u2014 anything from the task missing? Cases, files, migrations, callers of changed signatures.\n3. Breakage \u2014 does the diff break adjacent behavior? Check usages of everything whose contract changed.\n4. Scope \u2014 changes beyond the task are findings, even when framed as improvements.\n5. Checks \u2014 were the claimed checks sufficient? Re-run one cheap decisive check if in doubt.\n6. Test coverage \u2014 does changed runtime behavior have a test that would fail without the change? Missing coverage is a finding, blocking when the behavior is load-bearing.\n7. Completion claims \u2014 a claim of passing checks with no fresh evidence (no command output shown) is itself a needs-changes finding, per leo:verification.\n8. Visible changes \u2014 a UI-visible diff reported done with neither render evidence nor the unverified warning block is a blocking finding, per leo:visual-verification.\n8. Secrets \u2014 a credential, token, private key, or `.env` value added to a tracked file is always a blocking finding, whether or not the task mentioned it. Check any new config, fixture, test data, or CI file the diff touches.\nStyle, naming, and hypothetical refactors are NOT findings.\n\nReporting\n- Score each candidate finding 0\u2013100 on confidence that it is real and matters. Report only findings scoring \u226580; drop the rest silently.\n- Mark each reported finding blocking (task not actually done, or something breaks) or non-blocking.\n- Verdict: `approved` (no blocking findings) or `needs-changes`. Findings as file:line + one-line explanation + what correct looks like.\n- Lead with `status: done | needs-context` on its own first line \u2014 leo:delegation's contract, narrowed for this role: `done` = you saw the whole diff and reached a verdict; `needs-context` = you could not resolve the diff scope, which per the rule above also forces `needs-changes`. Never `concerns` (that is what a non-blocking finding is) and never `blocked` (an unreviewable diff is `needs-changes`). `status` describes your run; the verdict describes the diff.\n- Terse: status, then verdict, then findings, nothing else.\n"
   }
 }

package/adapters/opencode/plugin.js

@@ -17,8 +17,10 @@
 // posture as hooks/session-start.py.
 
 import { readFile, writeFile, mkdir } from 'node:fs/promises';
+import { appendFileSync, mkdirSync } from 'node:fs';
 import path from 'node:path';
 import os from 'node:os';
+import { createHash } from 'node:crypto';
 import { fileURLToPath } from 'node:url';
 import { spawn } from 'node:child_process';
 
@@ -30,6 +32,15 @@ function localStateRoot() {
   return process.env.LEOS_AGENT_LOCAL_PATH || path.join(os.homedir(), '.leos-agent-local');
 }
 
+// One OpenCode process serves several project directories at once (its own log
+// shows one run= creating an instance per directory), and ESM caches this
+// module once per process, so nothing below may key off process.cwd() or hold
+// per-directory state in a bare module variable. The directory arrives on
+// PluginInput and is threaded through every consumer instead.
+function directoryKey(directory) {
+  return createHash('sha256').update(directory).digest('hex').slice(0, 12);
+}
+
 // A 6-line strip, not a YAML parser: the body starts after the second
 // leading '---' fence line. Anything malformed just returns the raw text.
 function stripFrontmatter(raw) {
@@ -43,7 +54,7 @@ function stripFrontmatter(raw) {
   return raw;
 }
 
-async function assemblePolicy() {
+async function assemblePolicy(directory) {
   let skillRaw;
   try {
     skillRaw = await readFile(path.join(ROOT, 'skills', 'using-leo', 'SKILL.md'), 'utf8');
@@ -68,12 +79,55 @@ async function assemblePolicy() {
   // hooks/session-start.py:97 uses.
   combined = combined.split('${CLAUDE_PLUGIN_ROOT}').join(ROOT);
 
-  return LEO_POLICY_MARKER + '\n' + combined + '</leo-policy>';
+  let policy = LEO_POLICY_MARKER + '\n' + combined + '</leo-policy>';
+
+  // Memory rides in its own envelope after the policy. Spawned rather than
+  // reimplemented in JS: memory.py already owns the store, the projection and
+  // the marker engine, and a fourth copy of that renderer would drift.
+  const memory = await memoryBlock(directory);
+  if (memory) {
+    policy += '\n\n<leo-memory>\n' + memory + '\n</leo-memory>';
+  }
+  return policy;
+}
+
+// Hard-kills after 4s: OpenCode session start must not hang on a memory store
+// living on a slow or unreachable filesystem. Any failure yields '' and the
+// session proceeds with policy only.
+//
+// `memory.py session` renders the block for the repo it is run in, so the
+// directory has to be the session's, not the server's: process.cwd() here
+// would serve one project's repo-scoped memories to every other project the
+// same OpenCode process is hosting.
+function memoryBlock(directory) {
+  return new Promise((resolve) => {
+    let done = false;
+    const finish = (value) => { if (!done) { done = true; resolve(value); } };
+    try {
+      const child = spawn('python3', [path.join(ROOT, 'scripts', 'memory.py'), 'session'], {
+        cwd: directory,
+        stdio: ['ignore', 'pipe', 'ignore'],
+      });
+      const timer = setTimeout(() => { try { child.kill('SIGKILL'); } catch {} finish(''); }, 4000);
+      let out = '';
+      child.stdout.on('data', (chunk) => { out += chunk.toString(); });
+      child.on('error', () => { clearTimeout(timer); finish(''); });
+      child.on('close', (code) => {
+        clearTimeout(timer);
+        finish(code === 0 ? out.trim() : '');
+      });
+    } catch {
+      finish('');
+    }
+  });
 }
 
-async function writePolicyFile(policy) {
+// Named per directory: the memory envelope inside is repo-scoped, so a single
+// shared filename would have each project's instance overwriting the file the
+// other projects' config.instructions already point at.
+async function writePolicyFile(policy, directory) {
   const dir = localStateRoot();
-  const dest = path.join(dir, 'opencode-policy.md');
+  const dest = path.join(dir, `opencode-policy-${directoryKey(directory)}.md`);
   try {
     await mkdir(dir, { recursive: true });
     await writeFile(dest, policy, 'utf8');
@@ -83,21 +137,24 @@ async function writePolicyFile(policy) {
   }
 }
 
-let policyCache;
-async function getPolicy() {
-  if (policyCache === undefined) {
-    policyCache = await assemblePolicy();
+// Keyed by directory for the same reason. A bare module variable is shared by
+// every instance in the process, which would pin whichever project started
+// first and serve its memories to the rest.
+const policyCache = new Map();
+async function getPolicy(directory) {
+  if (!policyCache.has(directory)) {
+    policyCache.set(directory, await assemblePolicy(directory));
   }
-  return policyCache;
+  return policyCache.get(directory);
 }
 
-let policyPathCache;
-async function getPolicyPath() {
-  if (policyPathCache === undefined) {
-    const policy = await getPolicy();
-    policyPathCache = policy ? await writePolicyFile(policy) : null;
+const policyPathCache = new Map();
+async function getPolicyPath(directory) {
+  if (!policyPathCache.has(directory)) {
+    const policy = await getPolicy(directory);
+    policyPathCache.set(directory, policy ? await writePolicyFile(policy, directory) : null);
   }
-  return policyPathCache;
+  return policyPathCache.get(directory);
 }
 
 async function loadAgents() {
@@ -109,9 +166,41 @@ async function loadAgents() {
   }
 }
 
-let guardWarnedOnce = false;
+// A guard that cannot run allows the command — the same posture as Claude
+// Code and Codex, where PreToolUse blocks only on exit 2 and any other
+// outcome is non-blocking. What must not happen is that it goes quiet: a
+// one-shot warning latch meant the second and every later unguarded command
+// passed with nothing said anywhere. Breadcrumb every one of them, to the
+// same local log the other bootstraps write to.
+function guardBreadcrumb(err) {
+  const reason = (err && err.message) || String(err);
+  try {
+    const dir = localStateRoot();
+    mkdirSync(dir, { recursive: true });
+    appendFileSync(
+      path.join(dir, 'opencode-guard.log'),
+      `${new Date().toISOString()} guard did not run, command allowed: ${reason}\n`,
+    );
+  } catch {
+    // A breadcrumb that cannot be written must not itself break the session.
+  }
+  console.error('[leo guard] guard did not run, allowing command:', reason);
+}
+
+export default async function leoPlugin(ctx) {
+  // The only place the session's directory is available. tool.execute.before
+  // receives just {tool, sessionID, callID} (@opencode-ai/plugin's own types),
+  // so reading a directory off that input yields undefined every time and
+  // falls through to the server's cwd — a different tree whenever one process
+  // hosts more than one project.
+  const directory = (ctx && (ctx.directory || ctx.worktree)) || process.cwd();
+
+  // OpenCode runs no session-start hook and exports no plugin-root variable,
+  // so scripts/doctor.py cannot tell this harness apart from a bare shell and
+  // used to inherit the bootstrap's "claude" default. Declare it, and do it
+  // here so the guard and memory subprocesses inherit it too.
+  process.env.LEOS_AGENT_HARNESS = 'opencode';
 
-export default async function leoPlugin(_ctx) {
   return {
     async config(config) {
       config.skills ||= {};
@@ -125,7 +214,7 @@ export default async function leoPlugin(_ctx) {
       config.agent ||= {};
       Object.assign(config.agent, agents);
 
-      const policyPath = await getPolicyPath();
+      const policyPath = await getPolicyPath(directory);
       if (policyPath) {
         config.instructions ||= [];
         if (!config.instructions.includes(policyPath)) {
@@ -143,7 +232,7 @@ export default async function leoPlugin(_ctx) {
       if (!Array.isArray(system)) return;
       if (system.some((s) => typeof s === 'string' && s.includes(LEO_POLICY_MARKER))) return;
 
-      const policy = await getPolicy();
+      const policy = await getPolicy(directory);
       if (policy) system.push(policy);
     },
 
@@ -152,15 +241,30 @@ export default async function leoPlugin(_ctx) {
       const command = output && output.args && output.args.command;
       if (typeof command !== 'string' || !command) return;
 
-      const cwd = (input && (input.directory || input.worktree || input.cwd)) || process.cwd();
-      const payload = JSON.stringify({ tool_name: 'Bash', tool_input: { command }, cwd });
+      // bash-guard expands relative targets against this cwd, so the wrong
+      // one misjudges in both directions: a home-level delete read as safe,
+      // a project-local delete read as critical.
+      const payload = JSON.stringify({
+        tool_name: 'Bash',
+        tool_input: { command },
+        cwd: directory,
+      });
       const guardPath = path.join(ROOT, 'hooks', 'bash-guard.py');
 
       let exitCode;
       let stderr = '';
+      let timer;
       try {
         exitCode = await new Promise((resolve, reject) => {
           const proc = spawn('python3', [guardPath], { stdio: ['pipe', 'ignore', 'pipe'] });
+          // Every other guard channel is bounded — Claude Code, Codex and
+          // Cursor all set timeout 10 in their hook manifests, and Hermes
+          // runs in-process so it cannot hang on its own. Unbounded, a wedged
+          // python3 hangs the tool call forever with nothing shown to anyone.
+          timer = setTimeout(() => {
+            try { proc.kill('SIGKILL'); } catch {}
+            reject(new Error('bash-guard.py timed out after 10s'));
+          }, 10000);
           proc.stderr.on('data', (d) => {
             stderr += d.toString();
           });
@@ -170,14 +274,10 @@ export default async function leoPlugin(_ctx) {
           proc.stdin.end();
         });
       } catch (err) {
-        if (!guardWarnedOnce) {
-          guardWarnedOnce = true;
-          console.error(
-            '[leo guard] infra failure spawning bash-guard.py, allowing command:',
-            err && err.message ? err.message : err,
-          );
-        }
+        guardBreadcrumb(err);
         return; // infra fail-open
+      } finally {
+        clearTimeout(timer);
       }
 
       if (exitCode === 2) {