@codyswann/lisa 2.322.2 → 2.322.4

package/dist/core/upstream-evidence-manifest.js

@@ -527,7 +527,7 @@ export const UPSTREAM_EVIDENCE_MANIFEST = Object.freeze({
     "plugins/src/base/skills/lisa-quality-review/SKILL.md": "17ba45f4c4b7877c0b0c9a3c1cc1cb9e18c642ead74ff7263698d8034d3241da",
     "plugins/src/base/skills/lisa-queue-status/SKILL.md": "87c6d34d0511d4afd812d1af3fee80fa3b7aa47db8449760b12f2699fedc1d78",
     "plugins/src/base/skills/lisa-remote-dispatch/SKILL.md": "2cc999d2c3b61b10aabb849e0833fd58edb444c5013c05108dd58e5d7d60c4ba",
-    "plugins/src/base/skills/lisa-remote-dispatch/scripts/dispatch.mjs": "6ce559964964c65154d2105a017c751bba086dcb8b4ea209ea42ce7b4fdb7d63",
+    "plugins/src/base/skills/lisa-remote-dispatch/scripts/dispatch.mjs": "c473e8eddf0fd5f220a5ea7ff9eb92f5482cfb2893e77edce59acc36671418a3",
     "plugins/src/base/skills/lisa-repair-intake/SKILL.md": "4f85ac1381631e9f250d9cf3239baba633ae0df9ba1959f8835ed662592e2d77",
     "plugins/src/base/skills/lisa-reproduce-bug/SKILL.md": "4d460993fac6021219ca23eee29b1b9afa7c37479dddc662b2fcfaca510edd68",
     "plugins/src/base/skills/lisa-research/SKILL.md": "19de7c5910b117c4b3b1bb7ae42cf9c8b6ff2a376b2e21961526bc7ebde18e85",
@@ -550,7 +550,7 @@ export const UPSTREAM_EVIDENCE_MANIFEST = Object.freeze({
     "plugins/src/base/skills/lisa-sentry-access/SKILL.md": "ecaf49b42bbf399781a3ebd0b1595e5a8ac44422537832e0442b2f184da0c83c",
     "plugins/src/base/skills/lisa-setup-atlassian/SKILL.md": "3820aecb57d184fde1cfa988e7e1402d8f2a766a0b3ffbb576de5a6a72b3d5c5",
     "plugins/src/base/skills/lisa-setup-automations/SKILL.md": "3ad004148a54571a50df90f23abec71e8510ef3ea3562ac812f8e2e11beb157a",
-    "plugins/src/base/skills/lisa-setup-automations/scripts/generate-workflow.mjs": "bfb3867cc62dd37d84367859e4d796edb7a0c046595b3e0194ddb0b6d3b63d61",
+    "plugins/src/base/skills/lisa-setup-automations/scripts/generate-workflow.mjs": "f639c3f174378f0068b9c9d56e59b356c6da988730a1390c61e4348b4a4073ac",
     "plugins/src/base/skills/lisa-setup-confluence/SKILL.md": "e92d762dbdaeae671c3e52dfe8e10d40a10b606b5e050589181a3898649faedc",
     "plugins/src/base/skills/lisa-setup-github-repo/SKILL.md": "b9b223a5ffad2f88e3fde5831b60fea9bdc2c981750c49d03bb046d43772a0d3",
     "plugins/src/base/skills/lisa-setup-github/SKILL.md": "75435e81130abd21c678d302b7a220da95a19868d122ca93168278628b200666",
@@ -559,10 +559,10 @@ export const UPSTREAM_EVIDENCE_MANIFEST = Object.freeze({
     "plugins/src/base/skills/lisa-setup-linear/SKILL.md": "ec76f832a6df6f58b163f7f5ba6826ed2fcbddc91e44a8372e874858e4d0c518",
     "plugins/src/base/skills/lisa-setup-notion/SKILL.md": "f5a1e9290789fd1c33675168d30461fb24a11c98a433ef777c1f536bc2f905ef",
     "plugins/src/base/skills/lisa-setup-remote-aws/SKILL.md": "80fbf157f9c562c033886c25a99b37356602edd9e61cd2d492f339769ddcf97e",
-    "plugins/src/base/skills/lisa-setup-remote-env/SKILL.md": "e6530485e2564f35592a28bc5e547d185a38bf2a061feb210d533304acdc5cc2",
+    "plugins/src/base/skills/lisa-setup-remote-env/SKILL.md": "4fe124678cfc2b37188370af3b4e16895fcbad4d4b6f13b0fc7ac02bd99b0d26",
     "plugins/src/base/skills/lisa-setup-remote-env/assets/session-start.sh": "6e3871ec2f8d56b8ebb85376ebdd3956f3ed8fa4f7b278c2ed90ca9b8845897c",
     "plugins/src/base/skills/lisa-setup-remote-env/assets/setup.sh": "7f7cf8a2248dbaa31f2f039fdaf147d083427a21633f7cf06ad612f38344d6c1",
-    "plugins/src/base/skills/lisa-setup-remote-env/scripts/setup-remote-env.mjs": "c3fedb3f9cc50e706c197129cfe69baf705a96ab93194152c6d2f952f2d6d3b7",
+    "plugins/src/base/skills/lisa-setup-remote-env/scripts/setup-remote-env.mjs": "e8f1e74dd29104dc880eb2540024549d18d2a9c958b2b6fce0610ab0afd55cbb",
     "plugins/src/base/skills/lisa-setup-remote-env/scripts/toolchain.mjs": "ff66d33ba41a068d09be18f81ac68988238c2afa1d4e3733ae906b73eea74324",
     "plugins/src/base/skills/lisa-setup-remote-env/scripts/verify-remote-env.mjs": "82bc2a27a0a5afb2ff413a88365c619fd7f0eaada5de3ccabf2000938f0607a4",
     "plugins/src/base/skills/lisa-setup-sonar/SKILL.md": "53fbd8acce4b5e47e88195a7b90d5be424fa6ef7ad872f52c50467c690664c3b",

package/package.json

@@ -115,7 +115,7 @@
     "brace-expansion": ">=5.0.9"
   },
   "name": "@codyswann/lisa",
-  "version": "2.322.2",
+  "version": "2.322.4",
   "description": "Claude Code governance framework that applies guardrails, guidance, and automated enforcement to projects",
   "main": "dist/index.js",
   "exports": {

package/plugins/lisa/.claude-plugin/plugin.json

@@ -1,6 +1,6 @@
 {
   "name": "lisa",
-  "version": "2.322.2",
+  "version": "2.322.4",
   "description": "Universal governance — agents, skills, commands, hooks, and rules for all projects",
   "author": {
     "name": "Cody Swann"

package/plugins/lisa/.codex-plugin/plugin.json

@@ -1,6 +1,6 @@
 {
   "name": "lisa",
-  "version": "2.322.2",
+  "version": "2.322.4",
   "description": "Universal governance: agents, skills, commands, hooks, and rules for all projects.",
   "author": {
     "name": "Cody Swann"

package/plugins/lisa/.codex-plugin/skills/lisa-remote-dispatch/scripts/dispatch.mjs

@@ -416,6 +416,28 @@ function resolveBearerToken(block) {
   }
 }
 
+/**
+ * How each agent spells "run this skill".
+ *
+ * Codex invokes a skill with `$name`, Claude with `/name`. The prefix is the
+ * whole invocation: get it wrong and the agent reads a sentence that merely
+ * mentions a skill rather than a command that runs one — and being a capable
+ * model it will often do *something*, which is worse than failing, because the
+ * run looks successful while executing none of the skill's contract.
+ *
+ * Nothing downstream catches it either. The routine accepts any text, so the
+ * dispatch succeeds, a session identifier is recorded, and the ledger says the
+ * work was handed off. Only reading the session shows otherwise.
+ * @param {string} surface Execution surface.
+ * @param {string} skill Skill slug, without a prefix.
+ * @param {string} rest The payload the skill is invoked with.
+ * @returns {string} The thin invocation to send.
+ */
+export function buildInvocation(surface, skill, rest) {
+  const prefix = surface === "claude-web" ? "/" : "$";
+  return `${prefix}${skill} ${rest}`.trim();
+}
+
 async function main() {
   const { skill, raw } = splitSkillFlag(process.argv.slice(2));
   const { params, rest } = parseInvocation(raw);
@@ -432,7 +454,7 @@ async function main() {
   // The invocation stays thin on purpose. Every durable instruction lives in
   // the repository-local skill, so an interactive run, a scheduled run, and a
   // recovery run all execute one contract.
-  const prompt = `$${skill} ${rest}`.trim();
+  const prompt = buildInvocation(surface, skill, rest);
 
   if (surface === "claude-web") {
     const { sessionId, url } = await dispatchClaudeWeb(block, prompt, rest);

package/plugins/lisa/.codex-plugin/skills/lisa-setup-automations/scripts/generate-workflow.mjs

@@ -62,6 +62,51 @@ export function readAutomation(name, cwd = process.cwd()) {
   };
 }
 
+/**
+ * Emit shell that locates a Lisa skill script before running it.
+ *
+ * A hardcoded `.claude/skills/...` path is wrong in exactly the place this
+ * workflow runs. Claude and Codex receive Lisa skills as an installed plugin
+ * living in the user's home directory, which is emphatically not part of a
+ * clone — and a scheduled run is always a fresh clone with no plugin install.
+ * So the one path that reliably exists on a runner is the npm package, at the
+ * version the project pins, which is the version its automation should run.
+ *
+ * The same candidate list the remote-env entrypoint uses, for the same reason:
+ * the in-checkout copies are cheapest and need nothing installed, and
+ * `node_modules` is the fallback that makes the plugin-delivered harnesses work
+ * at all.
+ * @param {string} skill Skill slug that owns the script.
+ * @param {string} script Script filename.
+ * @param {string[]} args Arguments appended to the invocation, one per line.
+ * @returns {string} Shell, indented for a workflow `run:` block.
+ */
+function runSkillScript(skill, script, args) {
+  const candidates = [
+    `.claude/skills/${skill}/scripts/${script}`,
+    `.agents/skills/${skill}/scripts/${script}`,
+    `.codex/skills/${skill}/scripts/${script}`,
+    `node_modules/@codyswann/lisa/plugins/lisa/skills/${skill}/scripts/${script}`,
+  ]
+    .map(candidate => `            "${candidate}"`)
+    .join(" \\\n");
+  const tail = args.map(arg => `            ${arg}`).join(" \\\n");
+  return `          runner=""
+          for candidate in \\
+${candidates}; do
+            if [ -f "$candidate" ]; then runner="$candidate"; break; fi
+          done
+          if [ -z "$runner" ]; then
+            echo "cannot find ${skill}/scripts/${script}" >&2
+            echo "Checked the agent skill directories and node_modules." >&2
+            echo "Lisa skills reach Claude and Codex as an installed plugin," >&2
+            echo "so node_modules is the only copy a runner ever has." >&2
+            exit 1
+          fi
+          node "$runner" \\
+${tail}`;
+}
+
 /**
  * Render the workflow YAML for one loop.
  *
@@ -112,7 +157,7 @@ export function renderWorkflow(name, loop) {
           ${bootstrap}: \${{ secrets.${bootstrap} }}
         run: |
           set -euo pipefail
-          node .claude/skills/lisa-secrets-access/scripts/rotate-secret.mjs leases`;
+${runSkillScript("lisa-secrets-access", "rotate-secret.mjs", ["leases"])}`;
 
   const trigger = loop.enabled
     ? `  schedule:\n    - cron: '${loop.schedule}'\n  workflow_dispatch:`
@@ -172,9 +217,10 @@ jobs:
           ${bootstrap}: \${{ secrets.${bootstrap} }}
         run: |
           set -euo pipefail
-          node .claude/skills/lisa-remote-dispatch/scripts/dispatch.mjs \\
-            'executionEnv=${loop.executionEnv} ${loop.payload ?? ""}' \\
-            --skill ${loop.skill ?? `lisa-${name}`}
+${runSkillScript("lisa-remote-dispatch", "dispatch.mjs", [
+  `'executionEnv=${loop.executionEnv} ${loop.payload ?? ""}'`,
+  `--skill ${loop.skill ?? `lisa-${name}`}`,
+])}
 
 ${rotation}
 `;

package/plugins/lisa/.codex-plugin/skills/lisa-setup-remote-env/SKILL.md

@@ -13,8 +13,8 @@ Prepare a remote surface so a host project can execute there. Today that means *
 The remote environment's own configuration fields stay **one line into the repository**. Nothing else is pasted into a vendor UI.
 
 ```text
-setup:       for f in scripts/lisa-remote-env/setup.sh */scripts/lisa-remote-env/setup.sh; do [ -f "$f" ] && exec bash "$f"; done; echo "lisa-remote-env entrypoint not found under $PWD" >&2; exit 1
-maintenance: for f in scripts/lisa-remote-env/setup.sh */scripts/lisa-remote-env/setup.sh; do [ -f "$f" ] && exec bash "$f"; done; echo "lisa-remote-env entrypoint not found under $PWD" >&2; exit 1
+setup:       n=0; rc=0; for f in scripts/lisa-remote-env/setup.sh */scripts/lisa-remote-env/setup.sh; do [ -f "$f" ] || continue; n=$((n+1)); bash "$f" || rc=$?; done; [ "$n" -gt 0 ] || { echo "lisa-remote-env entrypoint not found under $PWD" >&2; exit 1; }; exit "$rc"
+maintenance: n=0; rc=0; for f in scripts/lisa-remote-env/setup.sh */scripts/lisa-remote-env/setup.sh; do [ -f "$f" ] || continue; n=$((n+1)); bash "$f" || rc=$?; done; [ "$n" -gt 0 ] || { echo "lisa-remote-env entrypoint not found under $PWD" >&2; exit 1; }; exit "$rc"
 ```
 
 **That line is identical for every project AND every surface.** Nothing in it names the
@@ -34,10 +34,18 @@ and neither mentions `$HOME`. An earlier version of this field used
 the checkout is not under `$HOME` at all: the glob matches nothing and bash reports
 `No such file or directory` for a path still containing a literal `*`.
 
-`exec` on the first hit means no subshell and no `ls` output to parse, and the explicit
-`exit 1` means a missing entrypoint says so rather than the field silently succeeding. The
-script then anchors itself on the repository root, so it behaves the same however it was
-reached.
+**Every** match is prepared, not the first. A Claude Code web environment can hold more than
+one checkout, and stopping at the first glob hit would prepare whichever repository sorts
+first and silently ignore the rest — arbitrary rather than merely limited. Each script
+anchors itself on its own repository root, and each project's secrets land under its own
+`secrets.namespace`, so preparing several is well defined rather than a collision.
+
+The exit status is the **first failure**, and every checkout is still attempted: one broken
+repository must not hide the state of the others, and it must not report success either.
+
+The explicit `exit 1` on `n=0` means a missing entrypoint says so rather than the field
+silently succeeding — a `for` loop over a glob that matches nothing otherwise exits `0`,
+which is the quiet failure this whole section exists to avoid.
 
 They are the same command. A container may be built fresh or resumed from cache; every step is idempotent and version-aware, so running it twice is correct, and running it on resume is what picks up a rotated value, an edited note, or a changed version pin.
 
@@ -156,8 +164,8 @@ When emitting, produce exactly:
 ```text
 Environment name:  <project> remote executor
 Repository:        <org>/<repo>        (must be the default checkout)
-Setup script:      for f in scripts/lisa-remote-env/setup.sh */scripts/lisa-remote-env/setup.sh; do [ -f "$f" ] && exec bash "$f"; done; echo "lisa-remote-env entrypoint not found under $PWD" >&2; exit 1
-Maintenance:       for f in scripts/lisa-remote-env/setup.sh */scripts/lisa-remote-env/setup.sh; do [ -f "$f" ] && exec bash "$f"; done; echo "lisa-remote-env entrypoint not found under $PWD" >&2; exit 1
+Setup script:      n=0; rc=0; for f in scripts/lisa-remote-env/setup.sh */scripts/lisa-remote-env/setup.sh; do [ -f "$f" ] || continue; n=$((n+1)); bash "$f" || rc=$?; done; [ "$n" -gt 0 ] || { echo "lisa-remote-env entrypoint not found under $PWD" >&2; exit 1; }; exit "$rc"
+Maintenance:       n=0; rc=0; for f in scripts/lisa-remote-env/setup.sh */scripts/lisa-remote-env/setup.sh; do [ -f "$f" ] || continue; n=$((n+1)); bash "$f" || rc=$?; done; [ "$n" -gt 0 ] || { echo "lisa-remote-env entrypoint not found under $PWD" >&2; exit 1; }; exit "$rc"
                    (identical for every project — the script finds the
                    checkout and installs from the committed lockfile)
 Environment vars:  LISA_SECRETS_SURFACE=codex-cloud

package/plugins/lisa/.codex-plugin/skills/lisa-setup-remote-env/scripts/setup-remote-env.mjs

@@ -308,20 +308,29 @@ export function installAssets(cwd = process.cwd()) {
  * at all — so a `$HOME` glob matched nothing there and bash was handed a path
  * still containing a literal asterisk.
  *
- * Both candidates are therefore tried relative to cwd. `exec` on the first hit
- * avoids a subshell and avoids parsing `ls`; the explicit `exit 1` means a
- * missing entrypoint says so rather than the field quietly succeeding. The
- * script then anchors itself on the repository root and installs dependencies
- * from whichever lockfile the project commits.
+ * Both candidates are therefore tried relative to cwd, and EVERY match is
+ * prepared rather than the first. A Claude Code web environment can hold more
+ * than one checkout, so stopping at the first hit would prepare whichever
+ * repository sorts first and silently ignore the rest — arbitrary rather than
+ * merely limited. Each script anchors itself on its own repository root and
+ * each project materializes under its own `secrets.namespace`, so preparing
+ * several is well defined rather than a collision.
+ *
+ * The status is the first failure and every checkout is still attempted: one
+ * broken repository must neither hide the others nor report success. The
+ * explicit `exit 1` on no matches matters because a `for` loop over a glob that
+ * matches nothing otherwise exits 0 — the quiet success this guards against.
  *
  * A field that named the repository and package manager was a string a human
  * had to get right, in a settings box with no review, no version history and no
  * test — and the logic it encoded belongs in a file that has all three.
  */
 export const SETUP_FIELD =
+  "n=0; rc=0; " +
   "for f in scripts/lisa-remote-env/setup.sh */scripts/lisa-remote-env/setup.sh; " +
-  'do [ -f "$f" ] && exec bash "$f"; done; ' +
-  'echo "lisa-remote-env entrypoint not found under $PWD" >&2; exit 1';
+  'do [ -f "$f" ] || continue; n=$((n+1)); bash "$f" || rc=$?; done; ' +
+  '[ "$n" -gt 0 ] || { echo "lisa-remote-env entrypoint not found under $PWD" >&2; exit 1; }; ' +
+  'exit "$rc"';
 
 /**
  * The settings block that wires the session-start hook into a repository.

package/plugins/lisa/skills/lisa-remote-dispatch/scripts/dispatch.mjs

@@ -416,6 +416,28 @@ function resolveBearerToken(block) {
   }
 }
 
+/**
+ * How each agent spells "run this skill".
+ *
+ * Codex invokes a skill with `$name`, Claude with `/name`. The prefix is the
+ * whole invocation: get it wrong and the agent reads a sentence that merely
+ * mentions a skill rather than a command that runs one — and being a capable
+ * model it will often do *something*, which is worse than failing, because the
+ * run looks successful while executing none of the skill's contract.
+ *
+ * Nothing downstream catches it either. The routine accepts any text, so the
+ * dispatch succeeds, a session identifier is recorded, and the ledger says the
+ * work was handed off. Only reading the session shows otherwise.
+ * @param {string} surface Execution surface.
+ * @param {string} skill Skill slug, without a prefix.
+ * @param {string} rest The payload the skill is invoked with.
+ * @returns {string} The thin invocation to send.
+ */
+export function buildInvocation(surface, skill, rest) {
+  const prefix = surface === "claude-web" ? "/" : "$";
+  return `${prefix}${skill} ${rest}`.trim();
+}
+
 async function main() {
   const { skill, raw } = splitSkillFlag(process.argv.slice(2));
   const { params, rest } = parseInvocation(raw);
@@ -432,7 +454,7 @@ async function main() {
   // The invocation stays thin on purpose. Every durable instruction lives in
   // the repository-local skill, so an interactive run, a scheduled run, and a
   // recovery run all execute one contract.
-  const prompt = `$${skill} ${rest}`.trim();
+  const prompt = buildInvocation(surface, skill, rest);
 
   if (surface === "claude-web") {
     const { sessionId, url } = await dispatchClaudeWeb(block, prompt, rest);

package/plugins/lisa/skills/lisa-setup-automations/scripts/generate-workflow.mjs

@@ -62,6 +62,51 @@ export function readAutomation(name, cwd = process.cwd()) {
   };
 }
 
+/**
+ * Emit shell that locates a Lisa skill script before running it.
+ *
+ * A hardcoded `.claude/skills/...` path is wrong in exactly the place this
+ * workflow runs. Claude and Codex receive Lisa skills as an installed plugin
+ * living in the user's home directory, which is emphatically not part of a
+ * clone — and a scheduled run is always a fresh clone with no plugin install.
+ * So the one path that reliably exists on a runner is the npm package, at the
+ * version the project pins, which is the version its automation should run.
+ *
+ * The same candidate list the remote-env entrypoint uses, for the same reason:
+ * the in-checkout copies are cheapest and need nothing installed, and
+ * `node_modules` is the fallback that makes the plugin-delivered harnesses work
+ * at all.
+ * @param {string} skill Skill slug that owns the script.
+ * @param {string} script Script filename.
+ * @param {string[]} args Arguments appended to the invocation, one per line.
+ * @returns {string} Shell, indented for a workflow `run:` block.
+ */
+function runSkillScript(skill, script, args) {
+  const candidates = [
+    `.claude/skills/${skill}/scripts/${script}`,
+    `.agents/skills/${skill}/scripts/${script}`,
+    `.codex/skills/${skill}/scripts/${script}`,
+    `node_modules/@codyswann/lisa/plugins/lisa/skills/${skill}/scripts/${script}`,
+  ]
+    .map(candidate => `            "${candidate}"`)
+    .join(" \\\n");
+  const tail = args.map(arg => `            ${arg}`).join(" \\\n");
+  return `          runner=""
+          for candidate in \\
+${candidates}; do
+            if [ -f "$candidate" ]; then runner="$candidate"; break; fi
+          done
+          if [ -z "$runner" ]; then
+            echo "cannot find ${skill}/scripts/${script}" >&2
+            echo "Checked the agent skill directories and node_modules." >&2
+            echo "Lisa skills reach Claude and Codex as an installed plugin," >&2
+            echo "so node_modules is the only copy a runner ever has." >&2
+            exit 1
+          fi
+          node "$runner" \\
+${tail}`;
+}
+
 /**
  * Render the workflow YAML for one loop.
  *
@@ -112,7 +157,7 @@ export function renderWorkflow(name, loop) {
           ${bootstrap}: \${{ secrets.${bootstrap} }}
         run: |
           set -euo pipefail
-          node .claude/skills/lisa-secrets-access/scripts/rotate-secret.mjs leases`;
+${runSkillScript("lisa-secrets-access", "rotate-secret.mjs", ["leases"])}`;
 
   const trigger = loop.enabled
     ? `  schedule:\n    - cron: '${loop.schedule}'\n  workflow_dispatch:`
@@ -172,9 +217,10 @@ jobs:
           ${bootstrap}: \${{ secrets.${bootstrap} }}
         run: |
           set -euo pipefail
-          node .claude/skills/lisa-remote-dispatch/scripts/dispatch.mjs \\
-            'executionEnv=${loop.executionEnv} ${loop.payload ?? ""}' \\
-            --skill ${loop.skill ?? `lisa-${name}`}
+${runSkillScript("lisa-remote-dispatch", "dispatch.mjs", [
+  `'executionEnv=${loop.executionEnv} ${loop.payload ?? ""}'`,
+  `--skill ${loop.skill ?? `lisa-${name}`}`,
+])}
 
 ${rotation}
 `;

package/plugins/lisa/skills/lisa-setup-remote-env/SKILL.md

@@ -13,8 +13,8 @@ Prepare a remote surface so a host project can execute there. Today that means *
 The remote environment's own configuration fields stay **one line into the repository**. Nothing else is pasted into a vendor UI.
 
 ```text
-setup:       for f in scripts/lisa-remote-env/setup.sh */scripts/lisa-remote-env/setup.sh; do [ -f "$f" ] && exec bash "$f"; done; echo "lisa-remote-env entrypoint not found under $PWD" >&2; exit 1
-maintenance: for f in scripts/lisa-remote-env/setup.sh */scripts/lisa-remote-env/setup.sh; do [ -f "$f" ] && exec bash "$f"; done; echo "lisa-remote-env entrypoint not found under $PWD" >&2; exit 1
+setup:       n=0; rc=0; for f in scripts/lisa-remote-env/setup.sh */scripts/lisa-remote-env/setup.sh; do [ -f "$f" ] || continue; n=$((n+1)); bash "$f" || rc=$?; done; [ "$n" -gt 0 ] || { echo "lisa-remote-env entrypoint not found under $PWD" >&2; exit 1; }; exit "$rc"
+maintenance: n=0; rc=0; for f in scripts/lisa-remote-env/setup.sh */scripts/lisa-remote-env/setup.sh; do [ -f "$f" ] || continue; n=$((n+1)); bash "$f" || rc=$?; done; [ "$n" -gt 0 ] || { echo "lisa-remote-env entrypoint not found under $PWD" >&2; exit 1; }; exit "$rc"
 ```
 
 **That line is identical for every project AND every surface.** Nothing in it names the
@@ -34,10 +34,18 @@ and neither mentions `$HOME`. An earlier version of this field used
 the checkout is not under `$HOME` at all: the glob matches nothing and bash reports
 `No such file or directory` for a path still containing a literal `*`.
 
-`exec` on the first hit means no subshell and no `ls` output to parse, and the explicit
-`exit 1` means a missing entrypoint says so rather than the field silently succeeding. The
-script then anchors itself on the repository root, so it behaves the same however it was
-reached.
+**Every** match is prepared, not the first. A Claude Code web environment can hold more than
+one checkout, and stopping at the first glob hit would prepare whichever repository sorts
+first and silently ignore the rest — arbitrary rather than merely limited. Each script
+anchors itself on its own repository root, and each project's secrets land under its own
+`secrets.namespace`, so preparing several is well defined rather than a collision.
+
+The exit status is the **first failure**, and every checkout is still attempted: one broken
+repository must not hide the state of the others, and it must not report success either.
+
+The explicit `exit 1` on `n=0` means a missing entrypoint says so rather than the field
+silently succeeding — a `for` loop over a glob that matches nothing otherwise exits `0`,
+which is the quiet failure this whole section exists to avoid.
 
 They are the same command. A container may be built fresh or resumed from cache; every step is idempotent and version-aware, so running it twice is correct, and running it on resume is what picks up a rotated value, an edited note, or a changed version pin.
 
@@ -156,8 +164,8 @@ When emitting, produce exactly:
 ```text
 Environment name:  <project> remote executor
 Repository:        <org>/<repo>        (must be the default checkout)
-Setup script:      for f in scripts/lisa-remote-env/setup.sh */scripts/lisa-remote-env/setup.sh; do [ -f "$f" ] && exec bash "$f"; done; echo "lisa-remote-env entrypoint not found under $PWD" >&2; exit 1
-Maintenance:       for f in scripts/lisa-remote-env/setup.sh */scripts/lisa-remote-env/setup.sh; do [ -f "$f" ] && exec bash "$f"; done; echo "lisa-remote-env entrypoint not found under $PWD" >&2; exit 1
+Setup script:      n=0; rc=0; for f in scripts/lisa-remote-env/setup.sh */scripts/lisa-remote-env/setup.sh; do [ -f "$f" ] || continue; n=$((n+1)); bash "$f" || rc=$?; done; [ "$n" -gt 0 ] || { echo "lisa-remote-env entrypoint not found under $PWD" >&2; exit 1; }; exit "$rc"
+Maintenance:       n=0; rc=0; for f in scripts/lisa-remote-env/setup.sh */scripts/lisa-remote-env/setup.sh; do [ -f "$f" ] || continue; n=$((n+1)); bash "$f" || rc=$?; done; [ "$n" -gt 0 ] || { echo "lisa-remote-env entrypoint not found under $PWD" >&2; exit 1; }; exit "$rc"
                    (identical for every project — the script finds the
                    checkout and installs from the committed lockfile)
 Environment vars:  LISA_SECRETS_SURFACE=codex-cloud

package/plugins/lisa/skills/lisa-setup-remote-env/scripts/setup-remote-env.mjs

@@ -308,20 +308,29 @@ export function installAssets(cwd = process.cwd()) {
  * at all — so a `$HOME` glob matched nothing there and bash was handed a path
  * still containing a literal asterisk.
  *
- * Both candidates are therefore tried relative to cwd. `exec` on the first hit
- * avoids a subshell and avoids parsing `ls`; the explicit `exit 1` means a
- * missing entrypoint says so rather than the field quietly succeeding. The
- * script then anchors itself on the repository root and installs dependencies
- * from whichever lockfile the project commits.
+ * Both candidates are therefore tried relative to cwd, and EVERY match is
+ * prepared rather than the first. A Claude Code web environment can hold more
+ * than one checkout, so stopping at the first hit would prepare whichever
+ * repository sorts first and silently ignore the rest — arbitrary rather than
+ * merely limited. Each script anchors itself on its own repository root and
+ * each project materializes under its own `secrets.namespace`, so preparing
+ * several is well defined rather than a collision.
+ *
+ * The status is the first failure and every checkout is still attempted: one
+ * broken repository must neither hide the others nor report success. The
+ * explicit `exit 1` on no matches matters because a `for` loop over a glob that
+ * matches nothing otherwise exits 0 — the quiet success this guards against.
  *
  * A field that named the repository and package manager was a string a human
  * had to get right, in a settings box with no review, no version history and no
  * test — and the logic it encoded belongs in a file that has all three.
  */
 export const SETUP_FIELD =
+  "n=0; rc=0; " +
   "for f in scripts/lisa-remote-env/setup.sh */scripts/lisa-remote-env/setup.sh; " +
-  'do [ -f "$f" ] && exec bash "$f"; done; ' +
-  'echo "lisa-remote-env entrypoint not found under $PWD" >&2; exit 1';
+  'do [ -f "$f" ] || continue; n=$((n+1)); bash "$f" || rc=$?; done; ' +
+  '[ "$n" -gt 0 ] || { echo "lisa-remote-env entrypoint not found under $PWD" >&2; exit 1; }; ' +
+  'exit "$rc"';
 
 /**
  * The settings block that wires the session-start hook into a repository.

package/plugins/lisa-agy/plugin.json

@@ -1,6 +1,6 @@
 {
   "name": "lisa",
-  "version": "2.322.2",
+  "version": "2.322.4",
   "description": "Universal governance — agents, skills, commands, hooks, and rules for all projects",
   "author": {
     "name": "Cody Swann"

package/plugins/lisa-agy/skills/lisa-remote-dispatch/scripts/dispatch.mjs

@@ -416,6 +416,28 @@ function resolveBearerToken(block) {
   }
 }
 
+/**
+ * How each agent spells "run this skill".
+ *
+ * Codex invokes a skill with `$name`, Claude with `/name`. The prefix is the
+ * whole invocation: get it wrong and the agent reads a sentence that merely
+ * mentions a skill rather than a command that runs one — and being a capable
+ * model it will often do *something*, which is worse than failing, because the
+ * run looks successful while executing none of the skill's contract.
+ *
+ * Nothing downstream catches it either. The routine accepts any text, so the
+ * dispatch succeeds, a session identifier is recorded, and the ledger says the
+ * work was handed off. Only reading the session shows otherwise.
+ * @param {string} surface Execution surface.
+ * @param {string} skill Skill slug, without a prefix.
+ * @param {string} rest The payload the skill is invoked with.
+ * @returns {string} The thin invocation to send.
+ */
+export function buildInvocation(surface, skill, rest) {
+  const prefix = surface === "claude-web" ? "/" : "$";
+  return `${prefix}${skill} ${rest}`.trim();
+}
+
 async function main() {
   const { skill, raw } = splitSkillFlag(process.argv.slice(2));
   const { params, rest } = parseInvocation(raw);
@@ -432,7 +454,7 @@ async function main() {
   // The invocation stays thin on purpose. Every durable instruction lives in
   // the repository-local skill, so an interactive run, a scheduled run, and a
   // recovery run all execute one contract.
-  const prompt = `$${skill} ${rest}`.trim();
+  const prompt = buildInvocation(surface, skill, rest);
 
   if (surface === "claude-web") {
     const { sessionId, url } = await dispatchClaudeWeb(block, prompt, rest);

package/plugins/lisa-agy/skills/lisa-setup-automations/scripts/generate-workflow.mjs

@@ -62,6 +62,51 @@ export function readAutomation(name, cwd = process.cwd()) {
   };
 }
 
+/**
+ * Emit shell that locates a Lisa skill script before running it.
+ *
+ * A hardcoded `.claude/skills/...` path is wrong in exactly the place this
+ * workflow runs. Claude and Codex receive Lisa skills as an installed plugin
+ * living in the user's home directory, which is emphatically not part of a
+ * clone — and a scheduled run is always a fresh clone with no plugin install.
+ * So the one path that reliably exists on a runner is the npm package, at the
+ * version the project pins, which is the version its automation should run.
+ *
+ * The same candidate list the remote-env entrypoint uses, for the same reason:
+ * the in-checkout copies are cheapest and need nothing installed, and
+ * `node_modules` is the fallback that makes the plugin-delivered harnesses work
+ * at all.
+ * @param {string} skill Skill slug that owns the script.
+ * @param {string} script Script filename.
+ * @param {string[]} args Arguments appended to the invocation, one per line.
+ * @returns {string} Shell, indented for a workflow `run:` block.
+ */
+function runSkillScript(skill, script, args) {
+  const candidates = [
+    `.claude/skills/${skill}/scripts/${script}`,
+    `.agents/skills/${skill}/scripts/${script}`,
+    `.codex/skills/${skill}/scripts/${script}`,
+    `node_modules/@codyswann/lisa/plugins/lisa/skills/${skill}/scripts/${script}`,
+  ]
+    .map(candidate => `            "${candidate}"`)
+    .join(" \\\n");
+  const tail = args.map(arg => `            ${arg}`).join(" \\\n");
+  return `          runner=""
+          for candidate in \\
+${candidates}; do
+            if [ -f "$candidate" ]; then runner="$candidate"; break; fi
+          done
+          if [ -z "$runner" ]; then
+            echo "cannot find ${skill}/scripts/${script}" >&2
+            echo "Checked the agent skill directories and node_modules." >&2
+            echo "Lisa skills reach Claude and Codex as an installed plugin," >&2
+            echo "so node_modules is the only copy a runner ever has." >&2
+            exit 1
+          fi
+          node "$runner" \\
+${tail}`;
+}
+
 /**
  * Render the workflow YAML for one loop.
  *
@@ -112,7 +157,7 @@ export function renderWorkflow(name, loop) {
           ${bootstrap}: \${{ secrets.${bootstrap} }}
         run: |
           set -euo pipefail
-          node .claude/skills/lisa-secrets-access/scripts/rotate-secret.mjs leases`;
+${runSkillScript("lisa-secrets-access", "rotate-secret.mjs", ["leases"])}`;
 
   const trigger = loop.enabled
     ? `  schedule:\n    - cron: '${loop.schedule}'\n  workflow_dispatch:`
@@ -172,9 +217,10 @@ jobs:
           ${bootstrap}: \${{ secrets.${bootstrap} }}
         run: |
           set -euo pipefail
-          node .claude/skills/lisa-remote-dispatch/scripts/dispatch.mjs \\
-            'executionEnv=${loop.executionEnv} ${loop.payload ?? ""}' \\
-            --skill ${loop.skill ?? `lisa-${name}`}
+${runSkillScript("lisa-remote-dispatch", "dispatch.mjs", [
+  `'executionEnv=${loop.executionEnv} ${loop.payload ?? ""}'`,
+  `--skill ${loop.skill ?? `lisa-${name}`}`,
+])}
 
 ${rotation}
 `;