@codyswann/lisa 2.321.5 → 2.322.1

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

@@ -1,6 +1,6 @@
 {
   "name": "lisa-nestjs",
-  "version": "2.321.5",
+  "version": "2.322.1",
   "description": "NestJS-specific skills (GraphQL, TypeORM) and hooks (migration write-protection)",
   "author": {
     "name": "Cody Swann"

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

@@ -1,6 +1,6 @@
 {
   "name": "lisa-nestjs",
-  "version": "2.321.5",
+  "version": "2.322.1",
   "description": "NestJS-specific skills and migration write-protection hooks.",
   "author": {
     "name": "Cody Swann"

package/plugins/lisa-nestjs-agy/plugin.json

@@ -1,6 +1,6 @@
 {
   "name": "lisa-nestjs",
-  "version": "2.321.5",
+  "version": "2.322.1",
   "description": "NestJS-specific skills (GraphQL, TypeORM) and hooks (migration write-protection)",
   "author": {
     "name": "Cody Swann"

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

@@ -1,6 +1,6 @@
 {
   "name": "lisa-nestjs",
-  "version": "2.321.5",
+  "version": "2.322.1",
   "description": "NestJS-specific skills (GraphQL, TypeORM) and hooks (migration write-protection)",
   "author": {
     "name": "Cody Swann"

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

@@ -1,6 +1,6 @@
 {
   "name": "lisa-nestjs",
-  "version": "2.321.5",
+  "version": "2.322.1",
   "description": "NestJS-specific skills (GraphQL, TypeORM) and hooks (migration write-protection)",
   "author": {
     "name": "Cody Swann"

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

@@ -1,6 +1,6 @@
 {
   "name": "lisa-openclaw",
-  "version": "2.321.5",
+  "version": "2.322.1",
   "description": "Connect staff roles to Telegram or Slack via OpenClaw — facilitator/specialist hub-and-spoke routing and repo-coding topics, for Claude Code and Codex",
   "author": {
     "name": "Cody Swann"

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

@@ -1,6 +1,6 @@
 {
   "name": "lisa-openclaw",
-  "version": "2.321.5",
+  "version": "2.322.1",
   "description": "Connect staff roles to Telegram or Slack via OpenClaw — facilitator/specialist hub-and-spoke routing and repo-coding topics, across Claude and Codex.",
   "author": {
     "name": "Cody Swann"

package/plugins/lisa-openclaw-agy/plugin.json

@@ -1,6 +1,6 @@
 {
   "name": "lisa-openclaw",
-  "version": "2.321.5",
+  "version": "2.322.1",
   "description": "Connect staff roles to Telegram or Slack via OpenClaw — facilitator/specialist hub-and-spoke routing and repo-coding topics, for Claude Code and Codex",
   "author": {
     "name": "Cody Swann"

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

@@ -1,6 +1,6 @@
 {
   "name": "lisa-openclaw",
-  "version": "2.321.5",
+  "version": "2.322.1",
   "description": "Connect staff roles to Telegram or Slack via OpenClaw — facilitator/specialist hub-and-spoke routing and repo-coding topics, for Claude Code and Codex",
   "author": {
     "name": "Cody Swann"

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

@@ -1,6 +1,6 @@
 {
   "name": "lisa-openclaw",
-  "version": "2.321.5",
+  "version": "2.322.1",
   "description": "Connect staff roles to Telegram or Slack via OpenClaw — facilitator/specialist hub-and-spoke routing and repo-coding topics, for Claude Code and Codex",
   "author": {
     "name": "Cody Swann"

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

@@ -1,6 +1,6 @@
 {
   "name": "lisa-phaser",
-  "version": "2.321.5",
+  "version": "2.322.1",
   "description": "Phaser 4 game-development rules for TypeScript projects",
   "author": {
     "name": "Cody Swann"

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

@@ -1,6 +1,6 @@
 {
   "name": "lisa-phaser",
-  "version": "2.321.5",
+  "version": "2.322.1",
   "description": "Phaser 4 game-development rules for TypeScript projects",
   "author": {
     "name": "Cody Swann"

package/plugins/lisa-phaser-agy/plugin.json

@@ -1,6 +1,6 @@
 {
   "name": "lisa-phaser",
-  "version": "2.321.5",
+  "version": "2.322.1",
   "description": "Phaser 4 game-development rules for TypeScript projects",
   "author": {
     "name": "Cody Swann"

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

@@ -1,6 +1,6 @@
 {
   "name": "lisa-phaser",
-  "version": "2.321.5",
+  "version": "2.322.1",
   "description": "Phaser 4 game-development rules for TypeScript projects",
   "author": {
     "name": "Cody Swann"

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

@@ -1,6 +1,6 @@
 {
   "name": "lisa-phaser",
-  "version": "2.321.5",
+  "version": "2.322.1",
   "description": "Phaser 4 game-development rules for TypeScript projects",
   "author": {
     "name": "Cody Swann"

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

@@ -1,6 +1,6 @@
 {
   "name": "lisa-rails",
-  "version": "2.321.5",
+  "version": "2.322.1",
   "description": "Ruby on Rails-specific hooks — RuboCop linting/formatting and ast-grep scanning on edit",
   "author": {
     "name": "Cody Swann"

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

@@ -1,6 +1,6 @@
 {
   "name": "lisa-rails",
-  "version": "2.321.5",
+  "version": "2.322.1",
   "description": "Ruby on Rails-specific skills and hooks for RuboCop and ast-grep scanning on edit.",
   "author": {
     "name": "Cody Swann"

package/plugins/lisa-rails-agy/plugin.json

@@ -1,6 +1,6 @@
 {
   "name": "lisa-rails",
-  "version": "2.321.5",
+  "version": "2.322.1",
   "description": "Ruby on Rails-specific hooks — RuboCop linting/formatting and ast-grep scanning on edit",
   "author": {
     "name": "Cody Swann"

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

@@ -1,6 +1,6 @@
 {
   "name": "lisa-rails",
-  "version": "2.321.5",
+  "version": "2.322.1",
   "description": "Ruby on Rails-specific hooks — RuboCop linting/formatting and ast-grep scanning on edit",
   "author": {
     "name": "Cody Swann"

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

@@ -1,6 +1,6 @@
 {
   "name": "lisa-rails",
-  "version": "2.321.5",
+  "version": "2.322.1",
   "description": "Ruby on Rails-specific hooks — RuboCop linting/formatting and ast-grep scanning on edit",
   "author": {
     "name": "Cody Swann"

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

@@ -1,6 +1,6 @@
 {
   "name": "lisa-typescript",
-  "version": "2.321.5",
+  "version": "2.322.1",
   "description": "TypeScript-specific hooks — Prettier formatting, ESLint linting, ast-grep scanning, and error-suppression blocking on edit",
   "author": {
     "name": "Cody Swann"

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

@@ -1,6 +1,6 @@
 {
   "name": "lisa-typescript",
-  "version": "2.321.5",
+  "version": "2.322.1",
   "description": "TypeScript-specific hooks for formatting, linting, and ast-grep scanning on edit.",
   "author": {
     "name": "Cody Swann"

package/plugins/lisa-typescript-agy/plugin.json

@@ -1,6 +1,6 @@
 {
   "name": "lisa-typescript",
-  "version": "2.321.5",
+  "version": "2.322.1",
   "description": "TypeScript-specific hooks — Prettier formatting, ESLint linting, ast-grep scanning, and error-suppression blocking on edit",
   "author": {
     "name": "Cody Swann"

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

@@ -1,6 +1,6 @@
 {
   "name": "lisa-typescript",
-  "version": "2.321.5",
+  "version": "2.322.1",
   "description": "TypeScript-specific hooks — Prettier formatting, ESLint linting, ast-grep scanning, and error-suppression blocking on edit",
   "author": {
     "name": "Cody Swann"

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

@@ -1,6 +1,6 @@
 {
   "name": "lisa-typescript",
-  "version": "2.321.5",
+  "version": "2.322.1",
   "description": "TypeScript-specific hooks — Prettier formatting, ESLint linting, ast-grep scanning, and error-suppression blocking on edit",
   "author": {
     "name": "Cody Swann"

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

@@ -1,6 +1,6 @@
 {
   "name": "lisa-wiki",
-  "version": "2.321.5",
+  "version": "2.322.1",
   "description": "LLM Wiki — a distributable, git-native markdown knowledge base for Claude Code and Codex",
   "author": {
     "name": "Cody Swann"

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

@@ -1,6 +1,6 @@
 {
   "name": "lisa-wiki",
-  "version": "2.321.5",
+  "version": "2.322.1",
   "description": "Distributable LLM Wiki kernel — ingest, query, lint, and maintain a git-native markdown knowledge base across Claude and Codex.",
   "author": {
     "name": "Cody Swann"

package/plugins/lisa-wiki-agy/plugin.json

@@ -1,6 +1,6 @@
 {
   "name": "lisa-wiki",
-  "version": "2.321.5",
+  "version": "2.322.1",
   "description": "LLM Wiki — a distributable, git-native markdown knowledge base for Claude Code and Codex",
   "author": {
     "name": "Cody Swann"

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

@@ -1,6 +1,6 @@
 {
   "name": "lisa-wiki",
-  "version": "2.321.5",
+  "version": "2.322.1",
   "description": "LLM Wiki — a distributable, git-native markdown knowledge base for Claude Code and Codex",
   "author": {
     "name": "Cody Swann"

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

@@ -1,6 +1,6 @@
 {
   "name": "lisa-wiki",
-  "version": "2.321.5",
+  "version": "2.322.1",
   "description": "LLM Wiki — a distributable, git-native markdown knowledge base for Claude Code and Codex",
   "author": {
     "name": "Cody Swann"

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

@@ -21,14 +21,53 @@
 
 import { execFileSync } from "node:child_process";
 import { existsSync, mkdirSync, readFileSync, writeFileSync } from "node:fs";
-import { join } from "node:path";
+import { dirname, join, resolve } from "node:path";
+import { fileURLToPath } from "node:url";
 
 /** Surfaces this dispatcher knows how to reach. `local` means "do not dispatch". */
-export const EXECUTION_ENVS = new Set(["local", "codex-cloud"]);
+export const EXECUTION_ENVS = new Set(["local", "codex-cloud", "claude-web"]);
+
+/**
+ * What each surface must have recorded before anything may dispatch to it.
+ *
+ * Not uniform, because the two surfaces do not bind the same way. A Codex Cloud
+ * environment is bound to one repository, so naming both is what proves the
+ * environment is the right one. A Claude cloud environment binds no repository
+ * at all — it is account-scoped configuration and the repository arrives per
+ * session — so its durable handle is the routine that dispatch fires.
+ */
+const SURFACE_PRECONDITIONS = {
+  "codex-cloud": ["environmentId", "repository"],
+  "claude-web": ["routineId", "fireUrl"],
+};
+
+/**
+ * The beta this endpoint ships under.
+ *
+ * Dated and rotating: the two most recent previous versions keep working, so a
+ * bump here is a migration with a window rather than a break. Stated once so
+ * there is a single place to move it.
+ */
+const ROUTINE_BETA = "experimental-cc-routine-2026-04-01";
+
+/**
+ * How long to wait for the routine to accept the dispatch.
+ *
+ * `fetch` has no timeout of its own, so a routine endpoint that accepts the
+ * connection and then says nothing leaves dispatch waiting forever — the one
+ * failure mode that never reaches the error path below and never reaches the
+ * operator either. Generous, because the endpoint only has to *accept* the
+ * dispatch: the session's own work happens long after this call returns, so
+ * this bounds a handshake rather than a run.
+ */
+const FIRE_TIMEOUT_MS = 30_000;
 
 /** Where dispatched work is recorded so a later session can find it. */
 const LEDGER = join(".lisa", "remote-dispatch.json");
 
+/** This file's directory, for locating the sibling secrets skill. */
+const HERE = dirname(fileURLToPath(import.meta.url));
+
 /**
  * Split `key=value` parameters from the rest of an invocation.
  *
@@ -101,9 +140,11 @@ export function readSurfaceConfig(surface, cwd = process.cwd()) {
  * @param {string} surface Execution surface.
  */
 export function assertPreconditions(block, surface) {
-  const missing = [];
-  if (!block.environmentId) missing.push("environmentId");
-  if (!block.repository) missing.push("repository");
+  const required = SURFACE_PRECONDITIONS[surface] ?? [
+    "environmentId",
+    "repository",
+  ];
+  const missing = required.filter(field => !block[field]);
   if (missing.length) {
     throw new Error(
       `remoteEnv.surfaces["${surface}"] is missing: ${missing.join(", ")}.\n` +
@@ -230,7 +271,152 @@ export function splitSkillFlag(argv) {
   return { skill, raw: rest.join(" ") };
 }
 
-function main() {
+/**
+ * Read the response a routine returns when it accepts a dispatch.
+ *
+ * Kept separate from the request so the shape can be exercised against a
+ * recorded body. The identifier is a field here rather than something scraped
+ * out of console output, which is the one respect in which this surface is
+ * easier to reconcile than the other.
+ * @param {string} body Raw response body.
+ * @returns {{sessionId: string, url: string}} The accepted session.
+ */
+export function readFireResponse(body) {
+  let parsed;
+  try {
+    parsed = JSON.parse(body);
+  } catch {
+    throw new Error(
+      `routine returned a body that is not JSON:\n${String(body).slice(0, 400)}`
+    );
+  }
+  const sessionId = parsed.claude_code_session_id;
+  const url = parsed.claude_code_session_url;
+  if (!sessionId) {
+    throw new Error(
+      `routine accepted the request but returned no session identifier.\n` +
+        `${JSON.stringify(parsed).slice(0, 400)}\n` +
+        `Refusing to report success: without the identifier nothing can ` +
+        `reconcile this run, and a retry would duplicate it.`
+    );
+  }
+  return { sessionId, url: url ?? "" };
+}
+
+/**
+ * Fire a routine and record the session it created.
+ *
+ * The payload is deliberately the work item and nothing else. It arrives on the
+ * far side wrapped in a block the platform marks as untrusted data, and a
+ * routine acts on it only because its saved prompt says to — which is the
+ * boundary this plan wanted anyway, enforced by the platform rather than by
+ * convention. Nothing here can widen the remote run's authority.
+ *
+ * The bearer token is resolved through the secrets chokepoint at the moment of
+ * use and never stored in configuration.
+ * Its three side effects — resolving a credential, making a request, writing the
+ * ledger — are all injectable, so the accept and refuse paths can be exercised
+ * without a token, a network, or a write into the working repository.
+ * @param {object} block Surface configuration.
+ * @param {string} prompt The thin skill invocation.
+ * @param {string} payload The caller's original payload, for the record.
+ * @param {{post?: Function, getToken?: Function, cwd?: string}} [options] Seams for tests.
+ * @returns {Promise<{sessionId: string, url: string}>} The accepted session.
+ */
+export async function dispatchClaudeWeb(block, prompt, payload, options = {}) {
+  const {
+    post = fetch,
+    getToken = resolveBearerToken,
+    cwd = process.cwd(),
+  } = options;
+  const token = getToken(block);
+  let response;
+  try {
+    response = await post(block.fireUrl, {
+      method: "POST",
+      headers: {
+        authorization: `Bearer ${token}`,
+        "anthropic-beta": ROUTINE_BETA,
+        "anthropic-version": "2023-06-01",
+        "content-type": "application/json",
+      },
+      body: JSON.stringify({ text: prompt }),
+      signal: AbortSignal.timeout(FIRE_TIMEOUT_MS),
+    });
+  } catch (err) {
+    // A timeout arrives here as an abort rather than a network error, and
+    // "could not reach" is the true and useful thing to say about both. It is
+    // named separately so the operator can tell a silent endpoint from a
+    // refused connection, since only one of those is worth retrying.
+    const reason =
+      err.name === "TimeoutError"
+        ? `no response within ${FIRE_TIMEOUT_MS / 1000}s`
+        : err.message;
+    throw new Error(`could not reach the routine endpoint: ${reason}`);
+  }
+
+  const body = await response.text();
+  if (!response.ok) {
+    // The token is the usual cause and the usual thing to leak, so the message
+    // names the status and the routine rather than echoing the request.
+    throw new Error(
+      `routine ${block.routineId} refused the dispatch (HTTP ${response.status}).\n` +
+        `${body.slice(0, 400)}\n` +
+        `A 401 means the bearer token is wrong, revoked, or regenerated.`
+    );
+  }
+
+  const { sessionId, url } = readFireResponse(body);
+  record(
+    {
+      taskId: sessionId,
+      surface: "claude-web",
+      routineId: block.routineId,
+      sessionUrl: url,
+      prompt,
+      payload,
+      dispatchedAt: new Date().toISOString(),
+    },
+    cwd
+  );
+  return { sessionId, url };
+}
+
+/**
+ * Resolve the dispatcher's own credential through the secrets chokepoint.
+ *
+ * Never read from configuration: the token authorises starting work on someone
+ * else's infrastructure, and it can be regenerated and revoked, so it belongs
+ * in the credential manager and in `secrets.rotating` alongside it.
+ * @param {object} block Surface configuration.
+ * @returns {string} The bearer token.
+ */
+function resolveBearerToken(block) {
+  const name = block.tokenKey ?? "CLAUDE_ROUTINE_TOKEN";
+  const resolver = resolve(
+    HERE,
+    "..",
+    "..",
+    "lisa-secrets-access",
+    "scripts",
+    "resolve-secret.mjs"
+  );
+  try {
+    return execFileSync("node", [resolver, "get", name], {
+      encoding: "utf8",
+      stdio: ["ignore", "pipe", "pipe"],
+    }).trim();
+  } catch (err) {
+    throw new Error(
+      `could not resolve ${name} through lisa-secrets-access.\n` +
+        `${String(err.stderr ?? err.message).trim()}\n` +
+        `It is the dispatcher's own credential; store it in the provider ` +
+        `rather than in .lisa.config.json.`
+    );
+  }
+}
+
+async function main() {
   const { skill, raw } = splitSkillFlag(process.argv.slice(2));
   const { params, rest } = parseInvocation(raw);
   const surface = resolveExecutionEnv(params);
@@ -247,6 +433,15 @@ function main() {
   // the repository-local skill, so an interactive run, a scheduled run, and a
   // recovery run all execute one contract.
   const prompt = `$${skill} ${rest}`.trim();
+
+  if (surface === "claude-web") {
+    const { sessionId, url } = await dispatchClaudeWeb(block, prompt, rest);
+    console.log(`dispatched: ${sessionId}`);
+    if (url) console.log(url);
+    console.log(`recorded in ${LEDGER}; not polling — this process is done.`);
+    return;
+  }
+
   const taskId = dispatchCodexCloud(block, prompt, rest);
 
   console.log(`dispatched: ${taskId}`);
@@ -255,10 +450,11 @@ function main() {
 }
 
 if (import.meta.url === `file://${process.argv[1]}`) {
-  try {
-    main();
-  } catch (err) {
+  // Awaited rather than called bare: one dispatch path is async, so a synchronous
+  // try/catch would let a rejection escape as an unhandled rejection and exit 0 —
+  // reporting dispatched work that was never accepted.
+  main().catch(err => {
     console.error(err.message);
     process.exit(1);
-  }
+  });
 }

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

@@ -10,26 +10,48 @@ Prepare a remote surface so a host project can execute there. Today that means *
 
 ## What lives where
 
-The remote environment's own configuration fields stay **one line into the repository, preceded by the project's dependency install**. Nothing else is pasted into a vendor UI.
+The remote environment's own configuration fields stay **one line into the repository**. Nothing else is pasted into a vendor UI.
 
 ```text
-setup:       <install> && bash scripts/lisa-remote-env/setup.sh
-maintenance: <install> && bash scripts/lisa-remote-env/setup.sh
+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
 ```
 
-`<install>` is whatever the project already uses — `bun install`, `npm ci`, `pnpm install`. Substitute it; do not invent one.
+**That line is identical for every project AND every surface.** Nothing in it names the
+repository, the package manager, or a home directory, so it can be pasted unchanged anywhere.
+
+Locating the checkout is the only hard part, because the surfaces disagree about where the
+field runs:
+
+| Surface | cwd when the field runs | Checkout |
+| --- | --- | --- |
+| Codex Cloud | **is** the checkout | `/workspace/<repo>` |
+| Claude Code web | `$HOME` | `$HOME/<repo>` |
+
+So both candidates are tried **relative to cwd** — the checkout itself, then one level down —
+and neither mentions `$HOME`. An earlier version of this field used
+`bash "$HOME"/*/scripts/...`, which works on Claude Code web and fails on Codex Cloud, where
+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.
 
 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.
 
-The complete logic is repository-owned so it is reviewed, versioned, tested, and reusable. A large inline installer in a settings field is none of those things.
+The complete logic is repository-owned so it is reviewed, versioned, tested, and reusable. A large inline installer in a settings field is none of those things — and neither is a repository name and a package manager, which is what this field used to carry.
 
-### Why the install has to come first
+### The script installs the dependencies itself
 
 **A clone does not contain the skills on the harnesses that matter here.** OpenCode and Antigravity have them written into the checkout by `lisa apply`. Claude and Codex receive them as an *installed plugin*, which lives in the user's home directory — so a container that has just cloned the repository has never seen it.
 
 `node_modules/@codyswann/lisa` is therefore the only copy present on a fresh container, and it is a good one: it is the version that project pins, which is the version its setup should run. The entrypoint searches the agent directories first and falls back to it.
 
-Omitting the install does not degrade gracefully. The entrypoint exits before the toolchain, secrets, and hook phases have done anything, so the environment looks provisioned and fails on first dispatch.
+So the install has to happen before the runner is resolved — and the entrypoint does it, rather than the settings field. Which package manager is read from the lockfile the project actually commits (`bun.lock`, `pnpm-lock.yaml`, `yarn.lock`, `package-lock.json`), never guessed: a guessed one fails on the container's first command with an error that blames the project rather than the guess. The step is skipped when `node_modules` already exists, which is what keeps a resumed container cheap, and `LISA_SKIP_INSTALL=1` opts out entirely for a caller that has already installed.
+
+A project with no lockfile is not fatal on its own — a checkout may carry the skill directly — so the script says so and lets the resolver decide.
 
 ## The three phases
 
@@ -134,11 +156,10 @@ When emitting, produce exactly:
 ```text
 Environment name:  <project> remote executor
 Repository:        <org>/<repo>        (must be the default checkout)
-Setup script:      <install> && bash scripts/lisa-remote-env/setup.sh
-Maintenance:       <install> && bash scripts/lisa-remote-env/setup.sh
-                   (<install> is the project's own: bun install, npm ci, ...
-                   It must precede the script — on a fresh container
-                   node_modules is the only copy of the skills present.)
+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
+                   (identical for every project — the script finds the
+                   checkout and installs from the committed lockfile)
 Environment vars:  LISA_SECRETS_SURFACE=codex-cloud
                    BWS_ACCESS_TOKEN=<from the provider; an environment
                    variable, not a task secret — setup and cache-resume
@@ -157,11 +178,11 @@ Generate the exact text to paste:
 node scripts/setup-remote-env.mjs --emit=claude-web
 ```
 
-It reads the project's own install command from its lockfile and the bootstrap name from `secrets.bootstrap.key`, then emits the environment fields, the `.claude/settings.json` hook block, and the two base-image surprises worth knowing before they cost an afternoon:
+It reads the bootstrap name from `secrets.bootstrap.key` and emits the environment fields, the `.claude/settings.json` hook block, and the base-image surprises worth knowing before they cost an afternoon:
 
 - **`gh` is not pre-installed.** If the project's flows shell out to it, add it to `remoteEnv.tools.install`, pinned and checksummed like anything else.
 - **A proxied credential reads as the literal string `proxy-injected`.** Tools that authenticate through the GitHub proxy work; a script that reads the variable directly gets the placeholder. The read-back asserts this rather than leaving it to be discovered against a live service.
-- **The setup field runs from `$HOME`, not from the checkout.** The emitted setup command starts with `cd <repo-name>` on purpose; without it the package install runs one directory above the clone and cannot find `package.json`.
+- **The setup field runs from `$HOME`, not from the checkout.** That is why the field is a `$HOME` glob rather than a plain relative path: it locates the clone one level down, and the script anchors itself from there. Nothing in the emitted line names this project, so it is the same line everywhere.
 - **Trusted network access is not enough for provider CLIs.** Use Custom and include package registries, GitHub, cloud SDK hosts, and the bootstrap credential manager API.
 
 ### One environment per project, pinned locally