@codyswann/lisa 2.322.7 → 2.322.8

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

@@ -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": "f706b5c94267d128bf41ef1a5fa6b68ea184e22c7929bda126128f08e1728b86",
+    "plugins/src/base/skills/lisa-setup-remote-env/SKILL.md": "5627c45a4ce7d0f0d122791f699b6dd2841602adf873678c693ad08a48eab401",
     "plugins/src/base/skills/lisa-setup-remote-env/assets/session-start.sh": "6e3871ec2f8d56b8ebb85376ebdd3956f3ed8fa4f7b278c2ed90ca9b8845897c",
     "plugins/src/base/skills/lisa-setup-remote-env/assets/setup.sh": "c04afb1cf8e14a2713645228e679fa7772559488330a240ec0297cae6afd03e2",
-    "plugins/src/base/skills/lisa-setup-remote-env/scripts/setup-remote-env.mjs": "f468dcf72512ff0b7d0d0ff6a38e81e5b57d83361ffff45c5265147f67ca01df",
+    "plugins/src/base/skills/lisa-setup-remote-env/scripts/setup-remote-env.mjs": "68339117f7d2fe1fdb9f05c8039ffe719f24da7cf700bc3c940bfccbf82cded2",
     "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.7",
+  "version": "2.322.8",
   "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.7",
+  "version": "2.322.8",
   "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.7",
+  "version": "2.322.8",
   "description": "Universal governance: agents, skills, commands, hooks, and rules for all projects.",
   "author": {
     "name": "Cody Swann"

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

@@ -18,7 +18,7 @@ maintenance: n=0; rc=0; seen=""; for f in scripts/lisa-remote-env/setup.sh */scr
 ```
 
 **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.
+repository or the package manager, so it can be pasted unchanged anywhere.
 
 Locating the checkout is the only hard part, because the surfaces disagree about where the
 field runs:
@@ -26,13 +26,17 @@ field runs:
 | Surface | cwd when the field runs | Checkout |
 | --- | --- | --- |
 | Codex Cloud | **is** the checkout | `/workspace/<repo>` |
-| Claude Code web | `$HOME` | `$HOME/<repo>` |
+| Claude Code web | `$HOME`, but not reliably | `$HOME/<repo>`, or another root |
 
-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 `*`.
+So the checkout itself and one level down are tried **relative to cwd first**, then the same
+pair under `$HOME` and `/workspace` — the roots the two surfaces actually use — because cwd is
+not reliably either of them: a live Claude environment reported `$HOME` as `/root` with the
+checkout at `/home/user/lisa`, which a cwd-only search cannot reach.
+
+The cwd-relative candidates coming **first** is the invariant, and a test pins it. An earlier
+version of this field used `bash "$HOME"/*/scripts/...` alone, 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 `*`.
 
 **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
@@ -190,7 +194,7 @@ It reads the bootstrap name from `secrets.bootstrap.key` and emits the environme
 
 - **`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.** 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.
+- **The surfaces disagree about where the setup field runs.** Codex Cloud runs it inside the checkout; Claude Code web runs it from `$HOME` with the checkout one level down. That is why the field tries the checkout itself and then one level down relative to cwd, and only then the same pair under `$HOME` and `/workspace` — the script anchors itself on whichever matched. 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

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

@@ -444,11 +444,15 @@ export function emitClaudeWeb({ bootstrapKey }) {
     "  Setup script:",
     `    ${SETUP_FIELD}`,
     "",
-    "    This line is identical for every project — nothing in it names this",
-    "    repository or its package manager. Claude runs the field from $HOME",
-    "    while the checkout lives one level down, so the glob is what locates",
-    "    it; the script then anchors itself and installs dependencies using",
-    "    whichever lockfile the project actually commits.",
+    "    This line is identical for every project and every surface — nothing",
+    "    in it names this repository or its package manager. The surfaces",
+    "    disagree about where the field runs: Codex Cloud runs it inside the",
+    "    checkout, Claude Code web runs it from $HOME with the checkout one",
+    "    level down. So it tries the checkout itself and then one level down,",
+    "    relative to cwd, and only then the same pair under $HOME and",
+    "    /workspace, for the case where cwd is neither. The script anchors",
+    "    itself on whichever matched and installs dependencies using whichever",
+    "    lockfile the project actually commits.",
     "",
     "    Keeping it generic is the point. A field that named the repository and",
     "    the package manager was a string a human had to get right, in a box",

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

@@ -18,7 +18,7 @@ maintenance: n=0; rc=0; seen=""; for f in scripts/lisa-remote-env/setup.sh */scr
 ```
 
 **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.
+repository or the package manager, so it can be pasted unchanged anywhere.
 
 Locating the checkout is the only hard part, because the surfaces disagree about where the
 field runs:
@@ -26,13 +26,17 @@ field runs:
 | Surface | cwd when the field runs | Checkout |
 | --- | --- | --- |
 | Codex Cloud | **is** the checkout | `/workspace/<repo>` |
-| Claude Code web | `$HOME` | `$HOME/<repo>` |
+| Claude Code web | `$HOME`, but not reliably | `$HOME/<repo>`, or another root |
 
-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 `*`.
+So the checkout itself and one level down are tried **relative to cwd first**, then the same
+pair under `$HOME` and `/workspace` — the roots the two surfaces actually use — because cwd is
+not reliably either of them: a live Claude environment reported `$HOME` as `/root` with the
+checkout at `/home/user/lisa`, which a cwd-only search cannot reach.
+
+The cwd-relative candidates coming **first** is the invariant, and a test pins it. An earlier
+version of this field used `bash "$HOME"/*/scripts/...` alone, 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 `*`.
 
 **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
@@ -190,7 +194,7 @@ It reads the bootstrap name from `secrets.bootstrap.key` and emits the environme
 
 - **`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.** 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.
+- **The surfaces disagree about where the setup field runs.** Codex Cloud runs it inside the checkout; Claude Code web runs it from `$HOME` with the checkout one level down. That is why the field tries the checkout itself and then one level down relative to cwd, and only then the same pair under `$HOME` and `/workspace` — the script anchors itself on whichever matched. 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

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

@@ -444,11 +444,15 @@ export function emitClaudeWeb({ bootstrapKey }) {
     "  Setup script:",
     `    ${SETUP_FIELD}`,
     "",
-    "    This line is identical for every project — nothing in it names this",
-    "    repository or its package manager. Claude runs the field from $HOME",
-    "    while the checkout lives one level down, so the glob is what locates",
-    "    it; the script then anchors itself and installs dependencies using",
-    "    whichever lockfile the project actually commits.",
+    "    This line is identical for every project and every surface — nothing",
+    "    in it names this repository or its package manager. The surfaces",
+    "    disagree about where the field runs: Codex Cloud runs it inside the",
+    "    checkout, Claude Code web runs it from $HOME with the checkout one",
+    "    level down. So it tries the checkout itself and then one level down,",
+    "    relative to cwd, and only then the same pair under $HOME and",
+    "    /workspace, for the case where cwd is neither. The script anchors",
+    "    itself on whichever matched and installs dependencies using whichever",
+    "    lockfile the project actually commits.",
     "",
     "    Keeping it generic is the point. A field that named the repository and",
     "    the package manager was a string a human had to get right, in a box",

package/plugins/lisa-agy/plugin.json

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

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

@@ -18,7 +18,7 @@ maintenance: n=0; rc=0; seen=""; for f in scripts/lisa-remote-env/setup.sh */scr
 ```
 
 **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.
+repository or the package manager, so it can be pasted unchanged anywhere.
 
 Locating the checkout is the only hard part, because the surfaces disagree about where the
 field runs:
@@ -26,13 +26,17 @@ field runs:
 | Surface | cwd when the field runs | Checkout |
 | --- | --- | --- |
 | Codex Cloud | **is** the checkout | `/workspace/<repo>` |
-| Claude Code web | `$HOME` | `$HOME/<repo>` |
+| Claude Code web | `$HOME`, but not reliably | `$HOME/<repo>`, or another root |
 
-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 `*`.
+So the checkout itself and one level down are tried **relative to cwd first**, then the same
+pair under `$HOME` and `/workspace` — the roots the two surfaces actually use — because cwd is
+not reliably either of them: a live Claude environment reported `$HOME` as `/root` with the
+checkout at `/home/user/lisa`, which a cwd-only search cannot reach.
+
+The cwd-relative candidates coming **first** is the invariant, and a test pins it. An earlier
+version of this field used `bash "$HOME"/*/scripts/...` alone, 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 `*`.
 
 **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
@@ -190,7 +194,7 @@ It reads the bootstrap name from `secrets.bootstrap.key` and emits the environme
 
 - **`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.** 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.
+- **The surfaces disagree about where the setup field runs.** Codex Cloud runs it inside the checkout; Claude Code web runs it from `$HOME` with the checkout one level down. That is why the field tries the checkout itself and then one level down relative to cwd, and only then the same pair under `$HOME` and `/workspace` — the script anchors itself on whichever matched. 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

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

@@ -444,11 +444,15 @@ export function emitClaudeWeb({ bootstrapKey }) {
     "  Setup script:",
     `    ${SETUP_FIELD}`,
     "",
-    "    This line is identical for every project — nothing in it names this",
-    "    repository or its package manager. Claude runs the field from $HOME",
-    "    while the checkout lives one level down, so the glob is what locates",
-    "    it; the script then anchors itself and installs dependencies using",
-    "    whichever lockfile the project actually commits.",
+    "    This line is identical for every project and every surface — nothing",
+    "    in it names this repository or its package manager. The surfaces",
+    "    disagree about where the field runs: Codex Cloud runs it inside the",
+    "    checkout, Claude Code web runs it from $HOME with the checkout one",
+    "    level down. So it tries the checkout itself and then one level down,",
+    "    relative to cwd, and only then the same pair under $HOME and",
+    "    /workspace, for the case where cwd is neither. The script anchors",
+    "    itself on whichever matched and installs dependencies using whichever",
+    "    lockfile the project actually commits.",
     "",
     "    Keeping it generic is the point. A field that named the repository and",
     "    the package manager was a string a human had to get right, in a box",

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

@@ -1,6 +1,6 @@
 {
   "name": "lisa-cdk",
-  "version": "2.322.7",
+  "version": "2.322.8",
   "description": "AWS CDK-specific plugin",
   "author": {
     "name": "Cody Swann"

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

@@ -1,6 +1,6 @@
 {
   "name": "lisa-cdk",
-  "version": "2.322.7",
+  "version": "2.322.8",
   "description": "AWS CDK-specific Lisa plugin.",
   "author": {
     "name": "Cody Swann"

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

@@ -1,6 +1,6 @@
 {
   "name": "lisa-cdk",
-  "version": "2.322.7",
+  "version": "2.322.8",
   "description": "AWS CDK-specific plugin",
   "author": {
     "name": "Cody Swann"

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

@@ -1,6 +1,6 @@
 {
   "name": "lisa-cdk",
-  "version": "2.322.7",
+  "version": "2.322.8",
   "description": "AWS CDK-specific plugin",
   "author": {
     "name": "Cody Swann"

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

@@ -1,6 +1,6 @@
 {
   "name": "lisa-cdk",
-  "version": "2.322.7",
+  "version": "2.322.8",
   "description": "AWS CDK-specific plugin",
   "author": {
     "name": "Cody Swann"

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

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

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

@@ -18,7 +18,7 @@ maintenance: n=0; rc=0; seen=""; for f in scripts/lisa-remote-env/setup.sh */scr
 ```
 
 **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.
+repository or the package manager, so it can be pasted unchanged anywhere.
 
 Locating the checkout is the only hard part, because the surfaces disagree about where the
 field runs:
@@ -26,13 +26,17 @@ field runs:
 | Surface | cwd when the field runs | Checkout |
 | --- | --- | --- |
 | Codex Cloud | **is** the checkout | `/workspace/<repo>` |
-| Claude Code web | `$HOME` | `$HOME/<repo>` |
+| Claude Code web | `$HOME`, but not reliably | `$HOME/<repo>`, or another root |
 
-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 `*`.
+So the checkout itself and one level down are tried **relative to cwd first**, then the same
+pair under `$HOME` and `/workspace` — the roots the two surfaces actually use — because cwd is
+not reliably either of them: a live Claude environment reported `$HOME` as `/root` with the
+checkout at `/home/user/lisa`, which a cwd-only search cannot reach.
+
+The cwd-relative candidates coming **first** is the invariant, and a test pins it. An earlier
+version of this field used `bash "$HOME"/*/scripts/...` alone, 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 `*`.
 
 **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
@@ -190,7 +194,7 @@ It reads the bootstrap name from `secrets.bootstrap.key` and emits the environme
 
 - **`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.** 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.
+- **The surfaces disagree about where the setup field runs.** Codex Cloud runs it inside the checkout; Claude Code web runs it from `$HOME` with the checkout one level down. That is why the field tries the checkout itself and then one level down relative to cwd, and only then the same pair under `$HOME` and `/workspace` — the script anchors itself on whichever matched. 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

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

@@ -444,11 +444,15 @@ export function emitClaudeWeb({ bootstrapKey }) {
     "  Setup script:",
     `    ${SETUP_FIELD}`,
     "",
-    "    This line is identical for every project — nothing in it names this",
-    "    repository or its package manager. Claude runs the field from $HOME",
-    "    while the checkout lives one level down, so the glob is what locates",
-    "    it; the script then anchors itself and installs dependencies using",
-    "    whichever lockfile the project actually commits.",
+    "    This line is identical for every project and every surface — nothing",
+    "    in it names this repository or its package manager. The surfaces",
+    "    disagree about where the field runs: Codex Cloud runs it inside the",
+    "    checkout, Claude Code web runs it from $HOME with the checkout one",
+    "    level down. So it tries the checkout itself and then one level down,",
+    "    relative to cwd, and only then the same pair under $HOME and",
+    "    /workspace, for the case where cwd is neither. The script anchors",
+    "    itself on whichever matched and installs dependencies using whichever",
+    "    lockfile the project actually commits.",
     "",
     "    Keeping it generic is the point. A field that named the repository and",
     "    the package manager was a string a human had to get right, in a box",

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

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

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

@@ -18,7 +18,7 @@ maintenance: n=0; rc=0; seen=""; for f in scripts/lisa-remote-env/setup.sh */scr
 ```
 
 **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.
+repository or the package manager, so it can be pasted unchanged anywhere.
 
 Locating the checkout is the only hard part, because the surfaces disagree about where the
 field runs:
@@ -26,13 +26,17 @@ field runs:
 | Surface | cwd when the field runs | Checkout |
 | --- | --- | --- |
 | Codex Cloud | **is** the checkout | `/workspace/<repo>` |
-| Claude Code web | `$HOME` | `$HOME/<repo>` |
+| Claude Code web | `$HOME`, but not reliably | `$HOME/<repo>`, or another root |
 
-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 `*`.
+So the checkout itself and one level down are tried **relative to cwd first**, then the same
+pair under `$HOME` and `/workspace` — the roots the two surfaces actually use — because cwd is
+not reliably either of them: a live Claude environment reported `$HOME` as `/root` with the
+checkout at `/home/user/lisa`, which a cwd-only search cannot reach.
+
+The cwd-relative candidates coming **first** is the invariant, and a test pins it. An earlier
+version of this field used `bash "$HOME"/*/scripts/...` alone, 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 `*`.
 
 **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
@@ -190,7 +194,7 @@ It reads the bootstrap name from `secrets.bootstrap.key` and emits the environme
 
 - **`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.** 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.
+- **The surfaces disagree about where the setup field runs.** Codex Cloud runs it inside the checkout; Claude Code web runs it from `$HOME` with the checkout one level down. That is why the field tries the checkout itself and then one level down relative to cwd, and only then the same pair under `$HOME` and `/workspace` — the script anchors itself on whichever matched. 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

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

@@ -444,11 +444,15 @@ export function emitClaudeWeb({ bootstrapKey }) {
     "  Setup script:",
     `    ${SETUP_FIELD}`,
     "",
-    "    This line is identical for every project — nothing in it names this",
-    "    repository or its package manager. Claude runs the field from $HOME",
-    "    while the checkout lives one level down, so the glob is what locates",
-    "    it; the script then anchors itself and installs dependencies using",
-    "    whichever lockfile the project actually commits.",
+    "    This line is identical for every project and every surface — nothing",
+    "    in it names this repository or its package manager. The surfaces",
+    "    disagree about where the field runs: Codex Cloud runs it inside the",
+    "    checkout, Claude Code web runs it from $HOME with the checkout one",
+    "    level down. So it tries the checkout itself and then one level down,",
+    "    relative to cwd, and only then the same pair under $HOME and",
+    "    /workspace, for the case where cwd is neither. The script anchors",
+    "    itself on whichever matched and installs dependencies using whichever",
+    "    lockfile the project actually commits.",
     "",
     "    Keeping it generic is the point. A field that named the repository and",
     "    the package manager was a string a human had to get right, in a box",

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

@@ -1,6 +1,6 @@
 {
   "name": "lisa-expo",
-  "version": "2.322.7",
+  "version": "2.322.8",
   "description": "Expo/React Native-specific skills, agents, rules, and MCP servers",
   "author": {
     "name": "Cody Swann"

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

@@ -1,6 +1,6 @@
 {
   "name": "lisa-expo",
-  "version": "2.322.7",
+  "version": "2.322.8",
   "description": "Expo and React Native-specific skills, agents, rules, and MCP servers.",
   "author": {
     "name": "Cody Swann"

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

@@ -1,6 +1,6 @@
 {
   "name": "lisa-expo",
-  "version": "2.322.7",
+  "version": "2.322.8",
   "description": "Expo/React Native-specific skills, agents, rules, and MCP servers",
   "author": {
     "name": "Cody Swann"

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

@@ -1,6 +1,6 @@
 {
   "name": "lisa-expo",
-  "version": "2.322.7",
+  "version": "2.322.8",
   "description": "Expo/React Native-specific skills, agents, rules, and MCP servers",
   "author": {
     "name": "Cody Swann"

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

@@ -1,6 +1,6 @@
 {
   "name": "lisa-expo",
-  "version": "2.322.7",
+  "version": "2.322.8",
   "description": "Expo/React Native-specific skills, agents, rules, and MCP servers",
   "author": {
     "name": "Cody Swann"

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

@@ -1,6 +1,6 @@
 {
   "name": "lisa-harper-fabric",
-  "version": "2.322.7",
+  "version": "2.322.8",
   "description": "Harper/Fabric-specific rules for TypeScript component apps",
   "author": {
     "name": "Cody Swann"

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

@@ -1,6 +1,6 @@
 {
   "name": "lisa-harper-fabric",
-  "version": "2.322.7",
+  "version": "2.322.8",
   "description": "Harper/Fabric-specific Lisa rules for TypeScript component apps.",
   "author": {
     "name": "Cody Swann"

package/plugins/lisa-harper-fabric-agy/plugin.json

@@ -1,6 +1,6 @@
 {
   "name": "lisa-harper-fabric",
-  "version": "2.322.7",
+  "version": "2.322.8",
   "description": "Harper/Fabric-specific rules for TypeScript component apps",
   "author": {
     "name": "Cody Swann"

package/plugins/lisa-harper-fabric-copilot/.claude-plugin/plugin.json

@@ -1,6 +1,6 @@
 {
   "name": "lisa-harper-fabric",
-  "version": "2.322.7",
+  "version": "2.322.8",
   "description": "Harper/Fabric-specific rules for TypeScript component apps",
   "author": {
     "name": "Cody Swann"

package/plugins/lisa-harper-fabric-cursor/.claude-plugin/plugin.json

@@ -1,6 +1,6 @@
 {
   "name": "lisa-harper-fabric",
-  "version": "2.322.7",
+  "version": "2.322.8",
   "description": "Harper/Fabric-specific rules for TypeScript component apps",
   "author": {
     "name": "Cody Swann"

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

@@ -1,6 +1,6 @@
 {
   "name": "lisa-nestjs",
-  "version": "2.322.7",
+  "version": "2.322.8",
   "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.322.7",
+  "version": "2.322.8",
   "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.322.7",
+  "version": "2.322.8",
   "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.322.7",
+  "version": "2.322.8",
   "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.322.7",
+  "version": "2.322.8",
   "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.322.7",
+  "version": "2.322.8",
   "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.322.7",
+  "version": "2.322.8",
   "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.322.7",
+  "version": "2.322.8",
   "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.322.7",
+  "version": "2.322.8",
   "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.322.7",
+  "version": "2.322.8",
   "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.322.7",
+  "version": "2.322.8",
   "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.322.7",
+  "version": "2.322.8",
   "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.322.7",
+  "version": "2.322.8",
   "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.322.7",
+  "version": "2.322.8",
   "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.322.7",
+  "version": "2.322.8",
   "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.322.7",
+  "version": "2.322.8",
   "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.322.7",
+  "version": "2.322.8",
   "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.322.7",
+  "version": "2.322.8",
   "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.322.7",
+  "version": "2.322.8",
   "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.322.7",
+  "version": "2.322.8",
   "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.322.7",
+  "version": "2.322.8",
   "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.322.7",
+  "version": "2.322.8",
   "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.322.7",
+  "version": "2.322.8",
   "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.322.7",
+  "version": "2.322.8",
   "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.322.7",
+  "version": "2.322.8",
   "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.322.7",
+  "version": "2.322.8",
   "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.322.7",
+  "version": "2.322.8",
   "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.322.7",
+  "version": "2.322.8",
   "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.322.7",
+  "version": "2.322.8",
   "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.322.7",
+  "version": "2.322.8",
   "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-setup-remote-env/SKILL.md

@@ -18,7 +18,7 @@ maintenance: n=0; rc=0; seen=""; for f in scripts/lisa-remote-env/setup.sh */scr
 ```
 
 **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.
+repository or the package manager, so it can be pasted unchanged anywhere.
 
 Locating the checkout is the only hard part, because the surfaces disagree about where the
 field runs:
@@ -26,13 +26,17 @@ field runs:
 | Surface | cwd when the field runs | Checkout |
 | --- | --- | --- |
 | Codex Cloud | **is** the checkout | `/workspace/<repo>` |
-| Claude Code web | `$HOME` | `$HOME/<repo>` |
+| Claude Code web | `$HOME`, but not reliably | `$HOME/<repo>`, or another root |
 
-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 `*`.
+So the checkout itself and one level down are tried **relative to cwd first**, then the same
+pair under `$HOME` and `/workspace` — the roots the two surfaces actually use — because cwd is
+not reliably either of them: a live Claude environment reported `$HOME` as `/root` with the
+checkout at `/home/user/lisa`, which a cwd-only search cannot reach.
+
+The cwd-relative candidates coming **first** is the invariant, and a test pins it. An earlier
+version of this field used `bash "$HOME"/*/scripts/...` alone, 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 `*`.
 
 **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
@@ -190,7 +194,7 @@ It reads the bootstrap name from `secrets.bootstrap.key` and emits the environme
 
 - **`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.** 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.
+- **The surfaces disagree about where the setup field runs.** Codex Cloud runs it inside the checkout; Claude Code web runs it from `$HOME` with the checkout one level down. That is why the field tries the checkout itself and then one level down relative to cwd, and only then the same pair under `$HOME` and `/workspace` — the script anchors itself on whichever matched. 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

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

@@ -444,11 +444,15 @@ export function emitClaudeWeb({ bootstrapKey }) {
     "  Setup script:",
     `    ${SETUP_FIELD}`,
     "",
-    "    This line is identical for every project — nothing in it names this",
-    "    repository or its package manager. Claude runs the field from $HOME",
-    "    while the checkout lives one level down, so the glob is what locates",
-    "    it; the script then anchors itself and installs dependencies using",
-    "    whichever lockfile the project actually commits.",
+    "    This line is identical for every project and every surface — nothing",
+    "    in it names this repository or its package manager. The surfaces",
+    "    disagree about where the field runs: Codex Cloud runs it inside the",
+    "    checkout, Claude Code web runs it from $HOME with the checkout one",
+    "    level down. So it tries the checkout itself and then one level down,",
+    "    relative to cwd, and only then the same pair under $HOME and",
+    "    /workspace, for the case where cwd is neither. The script anchors",
+    "    itself on whichever matched and installs dependencies using whichever",
+    "    lockfile the project actually commits.",
     "",
     "    Keeping it generic is the point. A field that named the repository and",
     "    the package manager was a string a human had to get right, in a box",