@codyswann/lisa 2.317.2 → 2.317.4

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

@@ -44,6 +44,10 @@ export function readAutomation(name, cwd = process.cwd()) {
   return {
     ...loop,
     repository: cfg.remoteEnv?.surfaces?.[loop.executionEnv]?.repository,
+    // Where this project keeps its bootstrap. A workstation serving several
+    // tenants gives each its own name, so the generated workflow must template
+    // it rather than assume the default.
+    bootstrapKey: cfg.secrets?.bootstrap?.key ?? "BWS_ACCESS_TOKEN",
   };
 }
 
@@ -70,6 +74,11 @@ export function readAutomation(name, cwd = process.cwd()) {
  */
 export function renderWorkflow(name, loop) {
   if (!loop.schedule) throw new Error(`automations["${name}"] has no schedule`);
+  // The repository secret and the environment variable carry the same name, so
+  // the value the workflow exports is the one `bootstrap.key` tells the resolver
+  // to look for. Translating it to the provider CLI's own variable is
+  // providers.mjs's job, not this workflow's.
+  const bootstrap = loop.bootstrapKey ?? "BWS_ACCESS_TOKEN";
   if (!loop.repository) {
     throw new Error(
       `automations["${name}"] targets executionEnv "${loop.executionEnv}", ` +
@@ -118,22 +127,22 @@ jobs:
       # seconds rather than after a toolchain download.
       - name: Check the bootstrap credential is configured
         env:
-          BWS_ACCESS_TOKEN: \${{ secrets.BWS_ACCESS_TOKEN }}
+          ${bootstrap}: \${{ secrets.${bootstrap} }}
         run: |
           set -euo pipefail
-          test -n "\${BWS_ACCESS_TOKEN}" || {
-            echo "BWS_ACCESS_TOKEN is not configured for this repository" >&2
+          test -n "\${${bootstrap}}" || {
+            echo "${bootstrap} is not configured for this repository" >&2
             exit 1
           }
 
       - name: Prepare the toolchain and secrets
         env:
-          BWS_ACCESS_TOKEN: \${{ secrets.BWS_ACCESS_TOKEN }}
+          ${bootstrap}: \${{ secrets.${bootstrap} }}
         run: bash scripts/lisa-remote-env/setup.sh
 
       - name: Run one ${name} cycle
         env:
-          BWS_ACCESS_TOKEN: \${{ secrets.BWS_ACCESS_TOKEN }}
+          ${bootstrap}: \${{ secrets.${bootstrap} }}
         run: |
           set -euo pipefail
           node .claude/skills/lisa-remote-dispatch/scripts/dispatch.mjs \\
@@ -145,7 +154,7 @@ jobs:
       - name: Persist any credential rotation
         if: \${{ always() }}
         env:
-          BWS_ACCESS_TOKEN: \${{ secrets.BWS_ACCESS_TOKEN }}
+          ${bootstrap}: \${{ secrets.${bootstrap} }}
         run: |
           set -euo pipefail
           node .claude/skills/lisa-secrets-access/scripts/rotate-secret.mjs leases

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

@@ -30,16 +30,41 @@ Install the vendor-neutral AWS bootstrap into the current repository.
    `.github/workflows/copilot-setup-steps.yml`; and it always writes
    `docs/remote-agent-aws.md`.
 4. Run `bash -n scripts/remote-agent-aws-setup.sh`.
-5. Never write or request the actual bootstrap SecretString in repository
-   files. Tell the operator to retrieve the `remote-agent-credentials` secret
-   from the shared AWS account and paste its complete SecretString into the
-   platform secret named `LISA_AWS_BOOTSTRAP_JSON`. The default cdkstarter
-   secret name is `remote-agent-credentials`; downstream infrastructure may
-   configure a different name. Pass that name with `--secret-name` so the
-   generated runbook contains the exact retrieval command.
+5. Never write or request the actual bootstrap bundle in repository files. Tell
+   the operator where to obtain it and where to put it — see **Where the bundle
+   lives** below. Pass `--secret-name` when the source names it something other
+   than `remote-agent-credentials`, so the generated runbook contains the exact
+   retrieval command.
 6. Report the external step that remains: configure that one secret in the
    remote environment and launch a smoke session.
 
+## Where the bundle lives
+
+`LISA_AWS_BOOTSTRAP_JSON` is **just another secret**, and it belongs wherever
+the project keeps its secrets — resolved through `lisa-secrets-access` like
+everything else. It is not tied to any one store.
+
+Whoever provisions the IAM user emits the bundle somewhere. `cdkstarter` writes
+it to AWS Secrets Manager as `remote-agent-credentials`, but that is where it is
+*emitted*, not where it must *live*. Copy it once into the project's configured
+provider and read it from there.
+
+**Do not keep it in two stores.** A bundle sitting in Secrets Manager *and* in
+the platform's secret store is two live copies of one credential: rotate the
+IAM key and whichever copy you forget keeps authenticating until it doesn't,
+with nothing to say which is current. That is the drift the single-store rule in
+`lisa-secrets-access` exists to prevent, and this credential is not exempt.
+
+**One provider cannot serve this particular secret.** If `secrets.provider` is
+`aws`, reading the bundle requires AWS credentials — and the bundle *is* the AWS
+credential. Anything else works: Bitwarden, 1Password, Doppler, Vault, or a
+platform secret store. Pick the one that is not the thing being bootstrapped.
+
+On a surface that materializes (see `lisa-secrets-access`), the bundle arrives
+in `secrets.env` with everything else, so the project hook can run this setup
+script after materialization with no extra plumbing. On a surface that reads
+through live, resolve it at the point of use.
+
 ## Contract
 
 A future coding agent is supported without an AWS change when its remote

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

@@ -1,6 +1,6 @@
 {
   "name": "lisa-cdk",
-  "version": "2.317.2",
+  "version": "2.317.4",
   "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.317.2",
+  "version": "2.317.4",
   "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.317.2",
+  "version": "2.317.4",
   "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.317.2",
+  "version": "2.317.4",
   "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.317.2",
+  "version": "2.317.4",
   "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.317.2",
+  "version": "2.317.4",
   "description": "Universal governance — agents, skills, commands, hooks, and rules for all projects",
   "author": {
     "name": "Cody Swann"

package/plugins/lisa-copilot/scripts/remote-agent-aws-setup.sh

@@ -3,8 +3,14 @@
 # source copied into every generated Lisa agent plugin.
 #
 # Required secret:
-#   LISA_AWS_BOOTSTRAP_JSON  Complete SecretString emitted by cdkstarter's
-#                            remote-agent IAM kit.
+#   LISA_AWS_BOOTSTRAP_JSON  The complete remote-agent bootstrap bundle, as one
+#                            JSON value. cdkstarter's IAM kit emits it, but this
+#                            script neither knows nor cares which store it came
+#                            from — resolve it through lisa-secrets-access like
+#                            any other secret. Note that a project whose
+#                            provider is AWS Secrets Manager cannot keep it
+#                            there: reading it would need the very credential it
+#                            contains.
 # Optional plain variables:
 #   LISA_REMOTE_AGENT       claude | codex | cursor | copilot | agy | opencode
 #   LISA_AWS_DEFAULT_PROFILE  Defaults to dev, then the first available profile.

package/plugins/lisa-copilot/skills/lisa-secrets-access/SKILL.md

@@ -82,6 +82,18 @@ ${XDG_CONFIG_HOME:-$HOME/.config}/<secrets.namespace>/     # dir 0700
 
 **`bootstrap`** — how to obtain the one credential that unlocks the rest. `sources` is ordered, environment first. This is the **only** credential permitted in a keychain; it is a bootstrap, not a cache.
 
+`bootstrap.key` answers exactly one question: **where do we find it** — the environment variable name and keychain service to look under. It is *not* the name the provider CLI reads. That name is fixed by the vendor (`bws` reads `BWS_ACCESS_TOKEN` and nothing else) and lives in `PROVIDER_BOOTSTRAP_ENV` in `providers.mjs`, which translates one into the other before invoking the CLI.
+
+Keeping these separate is what makes **one workstation serve several tenants**. Give each its own name and each project points at its own:
+
+```json
+"bootstrap": { "sources": ["env", "keychain"], "key": "BWS_ACCESS_TOKEN_acme" }
+```
+
+Conflating them worked only while every project used the default, where the two coincide. The first project to slug its key handed the CLI a variable it had never heard of, and every read and rotation failed with `Missing access token`. If you add a provider, add its canonical variable to that table — do not reach for `bootstrap.key`.
+
+On the GitHub Actions surface the repository secret and the exported environment variable both carry the **configured** name, and the generated workflow templates it. Translating to the CLI's own variable stays in `providers.mjs`.
+
 **`require`** — optional. Omit it and every secret the provider grants is available, which is correct when the provider already scopes access per project. Present, it narrows to exactly those names **and asserts them**: a listed name that does not resolve is a startup error, not a late surprise.
 
 **`narrow`** — may only *narrow* the provider's own grant. There is deliberately no way to widen access from config; that boundary belongs to the provider.
@@ -186,6 +198,13 @@ Values never enter that process, so its output cannot leak one even if logged.
 | `aws` | `aws secretsmanager get-secret-value --secret-id <name>` | not implemented |
 | `vault` | `vault kv get -field=<name> <path>` | not implemented |
 
+**A provider cannot hold its own bootstrap.** With `provider: "aws"`, reading any
+secret needs AWS credentials — so the AWS bootstrap bundle
+(`LISA_AWS_BOOTSTRAP_JSON`, see `lisa-setup-remote-aws`) cannot live there:
+resolving it would require the very credential it contains. Keep that one in a
+different provider. The same applies to any provider whose own access key is a
+secret you would otherwise store inside it.
+
 Unimplemented providers fail with a message naming where to add them, rather than failing obscurely. Do not claim support that does not exist.
 
 Cache **in-process only**. Never write a resolved value to disk except through the materialization contract above.

package/plugins/lisa-copilot/skills/lisa-secrets-access/scripts/providers.mjs

@@ -28,6 +28,56 @@ export const ENV_KEY = /^[A-Za-z_][A-Za-z0-9_]*$/;
  */
 export const LEASE_KEY = "LISA_ROTATION_LEASES";
 
+/**
+ * The environment variable each provider's CLI reads its own bootstrap from.
+ *
+ * This is deliberately *not* configurable, and separating it from
+ * `bootstrap.key` is the whole point. Two different questions were previously
+ * answered by one value:
+ *
+ * - **Where do we find the bootstrap?** A keychain service or environment
+ *   variable name. That must be configurable, because one workstation serves
+ *   several tenants and each needs its own token stored under its own name.
+ * - **What does the provider CLI call it?** Fixed by the vendor. `bws` reads
+ *   `BWS_ACCESS_TOKEN` and nothing else.
+ *
+ * Conflating them worked only while every project used the default name, where
+ * the two happen to coincide. The moment a project set
+ * `bootstrap.key: "BWS_ACCESS_TOKEN_<tenant>"` the CLI was handed a variable it
+ * has never heard of and failed with "Missing access token".
+ */
+const PROVIDER_BOOTSTRAP_ENV = {
+  bitwarden: "BWS_ACCESS_TOKEN",
+  doppler: "DOPPLER_TOKEN",
+};
+
+/**
+ * Build the child environment for a provider CLI, injecting the bootstrap under
+ * the name that CLI actually reads.
+ *
+ * Both the read path and the rotation write path need this, and they previously
+ * carried separate copies of the same line — which is how they would eventually
+ * have drifted. One helper, one place to be wrong.
+ * @param {object} cfg Resolved configuration.
+ * @returns {NodeJS.ProcessEnv} Environment for the child process.
+ */
+export function providerEnv(cfg) {
+  const env = { ...process.env };
+  const canonical = PROVIDER_BOOTSTRAP_ENV[cfg.provider];
+  if (!canonical) return env;
+  const token = bootstrapToken(cfg.bootstrap);
+  if (token) env[canonical] = token;
+  // Drop the tenant-scoped name once its value has been placed under the one
+  // the CLI reads. Inheriting it would leave two variables holding the same
+  // bootstrap in the child, which is how a tool that probes for a
+  // similarly-named credential binds to the wrong tenant on a workstation
+  // serving several. The child needs exactly one.
+  if (cfg.bootstrap.key && cfg.bootstrap.key !== canonical) {
+    delete env[cfg.bootstrap.key];
+  }
+  return env;
+}
+
 /**
  * Obtain the one credential that unlocks the provider.
  *
@@ -83,9 +133,7 @@ function fromKeychain(key) {
  * @returns {Array<{key: string, value: string, note: string, projectId: string|null}>} Rows.
  */
 export function fetchRaw(cfg) {
-  const env = { ...process.env };
-  const token = bootstrapToken(cfg.bootstrap);
-  if (cfg.bootstrap.key && token) env[cfg.bootstrap.key] = token;
+  const env = providerEnv(cfg);
 
   if (cfg.provider === "env") {
     return Object.entries(process.env)
@@ -225,9 +273,7 @@ export function rawByKey(cfg, key) {
  * @param {string} value Replacement value.
  */
 export function writeSecret(cfg, id, value) {
-  const env = { ...process.env };
-  const token = bootstrapToken(cfg.bootstrap);
-  if (cfg.bootstrap.key && token) env[cfg.bootstrap.key] = token;
+  const env = providerEnv(cfg);
 
   if (cfg.provider === "bitwarden") {
     run("bws", ["secret", "edit", id, "--value", value], env);

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

@@ -44,6 +44,10 @@ export function readAutomation(name, cwd = process.cwd()) {
   return {
     ...loop,
     repository: cfg.remoteEnv?.surfaces?.[loop.executionEnv]?.repository,
+    // Where this project keeps its bootstrap. A workstation serving several
+    // tenants gives each its own name, so the generated workflow must template
+    // it rather than assume the default.
+    bootstrapKey: cfg.secrets?.bootstrap?.key ?? "BWS_ACCESS_TOKEN",
   };
 }
 
@@ -70,6 +74,11 @@ export function readAutomation(name, cwd = process.cwd()) {
  */
 export function renderWorkflow(name, loop) {
   if (!loop.schedule) throw new Error(`automations["${name}"] has no schedule`);
+  // The repository secret and the environment variable carry the same name, so
+  // the value the workflow exports is the one `bootstrap.key` tells the resolver
+  // to look for. Translating it to the provider CLI's own variable is
+  // providers.mjs's job, not this workflow's.
+  const bootstrap = loop.bootstrapKey ?? "BWS_ACCESS_TOKEN";
   if (!loop.repository) {
     throw new Error(
       `automations["${name}"] targets executionEnv "${loop.executionEnv}", ` +
@@ -118,22 +127,22 @@ jobs:
       # seconds rather than after a toolchain download.
       - name: Check the bootstrap credential is configured
         env:
-          BWS_ACCESS_TOKEN: \${{ secrets.BWS_ACCESS_TOKEN }}
+          ${bootstrap}: \${{ secrets.${bootstrap} }}
         run: |
           set -euo pipefail
-          test -n "\${BWS_ACCESS_TOKEN}" || {
-            echo "BWS_ACCESS_TOKEN is not configured for this repository" >&2
+          test -n "\${${bootstrap}}" || {
+            echo "${bootstrap} is not configured for this repository" >&2
             exit 1
           }
 
       - name: Prepare the toolchain and secrets
         env:
-          BWS_ACCESS_TOKEN: \${{ secrets.BWS_ACCESS_TOKEN }}
+          ${bootstrap}: \${{ secrets.${bootstrap} }}
         run: bash scripts/lisa-remote-env/setup.sh
 
       - name: Run one ${name} cycle
         env:
-          BWS_ACCESS_TOKEN: \${{ secrets.BWS_ACCESS_TOKEN }}
+          ${bootstrap}: \${{ secrets.${bootstrap} }}
         run: |
           set -euo pipefail
           node .claude/skills/lisa-remote-dispatch/scripts/dispatch.mjs \\
@@ -145,7 +154,7 @@ jobs:
       - name: Persist any credential rotation
         if: \${{ always() }}
         env:
-          BWS_ACCESS_TOKEN: \${{ secrets.BWS_ACCESS_TOKEN }}
+          ${bootstrap}: \${{ secrets.${bootstrap} }}
         run: |
           set -euo pipefail
           node .claude/skills/lisa-secrets-access/scripts/rotate-secret.mjs leases

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

@@ -30,16 +30,41 @@ Install the vendor-neutral AWS bootstrap into the current repository.
    `.github/workflows/copilot-setup-steps.yml`; and it always writes
    `docs/remote-agent-aws.md`.
 4. Run `bash -n scripts/remote-agent-aws-setup.sh`.
-5. Never write or request the actual bootstrap SecretString in repository
-   files. Tell the operator to retrieve the `remote-agent-credentials` secret
-   from the shared AWS account and paste its complete SecretString into the
-   platform secret named `LISA_AWS_BOOTSTRAP_JSON`. The default cdkstarter
-   secret name is `remote-agent-credentials`; downstream infrastructure may
-   configure a different name. Pass that name with `--secret-name` so the
-   generated runbook contains the exact retrieval command.
+5. Never write or request the actual bootstrap bundle in repository files. Tell
+   the operator where to obtain it and where to put it — see **Where the bundle
+   lives** below. Pass `--secret-name` when the source names it something other
+   than `remote-agent-credentials`, so the generated runbook contains the exact
+   retrieval command.
 6. Report the external step that remains: configure that one secret in the
    remote environment and launch a smoke session.
 
+## Where the bundle lives
+
+`LISA_AWS_BOOTSTRAP_JSON` is **just another secret**, and it belongs wherever
+the project keeps its secrets — resolved through `lisa-secrets-access` like
+everything else. It is not tied to any one store.
+
+Whoever provisions the IAM user emits the bundle somewhere. `cdkstarter` writes
+it to AWS Secrets Manager as `remote-agent-credentials`, but that is where it is
+*emitted*, not where it must *live*. Copy it once into the project's configured
+provider and read it from there.
+
+**Do not keep it in two stores.** A bundle sitting in Secrets Manager *and* in
+the platform's secret store is two live copies of one credential: rotate the
+IAM key and whichever copy you forget keeps authenticating until it doesn't,
+with nothing to say which is current. That is the drift the single-store rule in
+`lisa-secrets-access` exists to prevent, and this credential is not exempt.
+
+**One provider cannot serve this particular secret.** If `secrets.provider` is
+`aws`, reading the bundle requires AWS credentials — and the bundle *is* the AWS
+credential. Anything else works: Bitwarden, 1Password, Doppler, Vault, or a
+platform secret store. Pick the one that is not the thing being bootstrapped.
+
+On a surface that materializes (see `lisa-secrets-access`), the bundle arrives
+in `secrets.env` with everything else, so the project hook can run this setup
+script after materialization with no extra plumbing. On a surface that reads
+through live, resolve it at the point of use.
+
 ## Contract
 
 A future coding agent is supported without an AWS change when its remote

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

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

package/plugins/lisa-cursor/scripts/remote-agent-aws-setup.sh

@@ -3,8 +3,14 @@
 # source copied into every generated Lisa agent plugin.
 #
 # Required secret:
-#   LISA_AWS_BOOTSTRAP_JSON  Complete SecretString emitted by cdkstarter's
-#                            remote-agent IAM kit.
+#   LISA_AWS_BOOTSTRAP_JSON  The complete remote-agent bootstrap bundle, as one
+#                            JSON value. cdkstarter's IAM kit emits it, but this
+#                            script neither knows nor cares which store it came
+#                            from — resolve it through lisa-secrets-access like
+#                            any other secret. Note that a project whose
+#                            provider is AWS Secrets Manager cannot keep it
+#                            there: reading it would need the very credential it
+#                            contains.
 # Optional plain variables:
 #   LISA_REMOTE_AGENT       claude | codex | cursor | copilot | agy | opencode
 #   LISA_AWS_DEFAULT_PROFILE  Defaults to dev, then the first available profile.

package/plugins/lisa-cursor/skills/lisa-secrets-access/SKILL.md

@@ -82,6 +82,18 @@ ${XDG_CONFIG_HOME:-$HOME/.config}/<secrets.namespace>/     # dir 0700
 
 **`bootstrap`** — how to obtain the one credential that unlocks the rest. `sources` is ordered, environment first. This is the **only** credential permitted in a keychain; it is a bootstrap, not a cache.
 
+`bootstrap.key` answers exactly one question: **where do we find it** — the environment variable name and keychain service to look under. It is *not* the name the provider CLI reads. That name is fixed by the vendor (`bws` reads `BWS_ACCESS_TOKEN` and nothing else) and lives in `PROVIDER_BOOTSTRAP_ENV` in `providers.mjs`, which translates one into the other before invoking the CLI.
+
+Keeping these separate is what makes **one workstation serve several tenants**. Give each its own name and each project points at its own:
+
+```json
+"bootstrap": { "sources": ["env", "keychain"], "key": "BWS_ACCESS_TOKEN_acme" }
+```
+
+Conflating them worked only while every project used the default, where the two coincide. The first project to slug its key handed the CLI a variable it had never heard of, and every read and rotation failed with `Missing access token`. If you add a provider, add its canonical variable to that table — do not reach for `bootstrap.key`.
+
+On the GitHub Actions surface the repository secret and the exported environment variable both carry the **configured** name, and the generated workflow templates it. Translating to the CLI's own variable stays in `providers.mjs`.
+
 **`require`** — optional. Omit it and every secret the provider grants is available, which is correct when the provider already scopes access per project. Present, it narrows to exactly those names **and asserts them**: a listed name that does not resolve is a startup error, not a late surprise.
 
 **`narrow`** — may only *narrow* the provider's own grant. There is deliberately no way to widen access from config; that boundary belongs to the provider.
@@ -186,6 +198,13 @@ Values never enter that process, so its output cannot leak one even if logged.
 | `aws` | `aws secretsmanager get-secret-value --secret-id <name>` | not implemented |
 | `vault` | `vault kv get -field=<name> <path>` | not implemented |
 
+**A provider cannot hold its own bootstrap.** With `provider: "aws"`, reading any
+secret needs AWS credentials — so the AWS bootstrap bundle
+(`LISA_AWS_BOOTSTRAP_JSON`, see `lisa-setup-remote-aws`) cannot live there:
+resolving it would require the very credential it contains. Keep that one in a
+different provider. The same applies to any provider whose own access key is a
+secret you would otherwise store inside it.
+
 Unimplemented providers fail with a message naming where to add them, rather than failing obscurely. Do not claim support that does not exist.
 
 Cache **in-process only**. Never write a resolved value to disk except through the materialization contract above.

package/plugins/lisa-cursor/skills/lisa-secrets-access/scripts/providers.mjs

@@ -28,6 +28,56 @@ export const ENV_KEY = /^[A-Za-z_][A-Za-z0-9_]*$/;
  */
 export const LEASE_KEY = "LISA_ROTATION_LEASES";
 
+/**
+ * The environment variable each provider's CLI reads its own bootstrap from.
+ *
+ * This is deliberately *not* configurable, and separating it from
+ * `bootstrap.key` is the whole point. Two different questions were previously
+ * answered by one value:
+ *
+ * - **Where do we find the bootstrap?** A keychain service or environment
+ *   variable name. That must be configurable, because one workstation serves
+ *   several tenants and each needs its own token stored under its own name.
+ * - **What does the provider CLI call it?** Fixed by the vendor. `bws` reads
+ *   `BWS_ACCESS_TOKEN` and nothing else.
+ *
+ * Conflating them worked only while every project used the default name, where
+ * the two happen to coincide. The moment a project set
+ * `bootstrap.key: "BWS_ACCESS_TOKEN_<tenant>"` the CLI was handed a variable it
+ * has never heard of and failed with "Missing access token".
+ */
+const PROVIDER_BOOTSTRAP_ENV = {
+  bitwarden: "BWS_ACCESS_TOKEN",
+  doppler: "DOPPLER_TOKEN",
+};
+
+/**
+ * Build the child environment for a provider CLI, injecting the bootstrap under
+ * the name that CLI actually reads.
+ *
+ * Both the read path and the rotation write path need this, and they previously
+ * carried separate copies of the same line — which is how they would eventually
+ * have drifted. One helper, one place to be wrong.
+ * @param {object} cfg Resolved configuration.
+ * @returns {NodeJS.ProcessEnv} Environment for the child process.
+ */
+export function providerEnv(cfg) {
+  const env = { ...process.env };
+  const canonical = PROVIDER_BOOTSTRAP_ENV[cfg.provider];
+  if (!canonical) return env;
+  const token = bootstrapToken(cfg.bootstrap);
+  if (token) env[canonical] = token;
+  // Drop the tenant-scoped name once its value has been placed under the one
+  // the CLI reads. Inheriting it would leave two variables holding the same
+  // bootstrap in the child, which is how a tool that probes for a
+  // similarly-named credential binds to the wrong tenant on a workstation
+  // serving several. The child needs exactly one.
+  if (cfg.bootstrap.key && cfg.bootstrap.key !== canonical) {
+    delete env[cfg.bootstrap.key];
+  }
+  return env;
+}
+
 /**
  * Obtain the one credential that unlocks the provider.
  *
@@ -83,9 +133,7 @@ function fromKeychain(key) {
  * @returns {Array<{key: string, value: string, note: string, projectId: string|null}>} Rows.
  */
 export function fetchRaw(cfg) {
-  const env = { ...process.env };
-  const token = bootstrapToken(cfg.bootstrap);
-  if (cfg.bootstrap.key && token) env[cfg.bootstrap.key] = token;
+  const env = providerEnv(cfg);
 
   if (cfg.provider === "env") {
     return Object.entries(process.env)
@@ -225,9 +273,7 @@ export function rawByKey(cfg, key) {
  * @param {string} value Replacement value.
  */
 export function writeSecret(cfg, id, value) {
-  const env = { ...process.env };
-  const token = bootstrapToken(cfg.bootstrap);
-  if (cfg.bootstrap.key && token) env[cfg.bootstrap.key] = token;
+  const env = providerEnv(cfg);
 
   if (cfg.provider === "bitwarden") {
     run("bws", ["secret", "edit", id, "--value", value], env);

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

@@ -44,6 +44,10 @@ export function readAutomation(name, cwd = process.cwd()) {
   return {
     ...loop,
     repository: cfg.remoteEnv?.surfaces?.[loop.executionEnv]?.repository,
+    // Where this project keeps its bootstrap. A workstation serving several
+    // tenants gives each its own name, so the generated workflow must template
+    // it rather than assume the default.
+    bootstrapKey: cfg.secrets?.bootstrap?.key ?? "BWS_ACCESS_TOKEN",
   };
 }
 
@@ -70,6 +74,11 @@ export function readAutomation(name, cwd = process.cwd()) {
  */
 export function renderWorkflow(name, loop) {
   if (!loop.schedule) throw new Error(`automations["${name}"] has no schedule`);
+  // The repository secret and the environment variable carry the same name, so
+  // the value the workflow exports is the one `bootstrap.key` tells the resolver
+  // to look for. Translating it to the provider CLI's own variable is
+  // providers.mjs's job, not this workflow's.
+  const bootstrap = loop.bootstrapKey ?? "BWS_ACCESS_TOKEN";
   if (!loop.repository) {
     throw new Error(
       `automations["${name}"] targets executionEnv "${loop.executionEnv}", ` +
@@ -118,22 +127,22 @@ jobs:
       # seconds rather than after a toolchain download.
       - name: Check the bootstrap credential is configured
         env:
-          BWS_ACCESS_TOKEN: \${{ secrets.BWS_ACCESS_TOKEN }}
+          ${bootstrap}: \${{ secrets.${bootstrap} }}
         run: |
           set -euo pipefail
-          test -n "\${BWS_ACCESS_TOKEN}" || {
-            echo "BWS_ACCESS_TOKEN is not configured for this repository" >&2
+          test -n "\${${bootstrap}}" || {
+            echo "${bootstrap} is not configured for this repository" >&2
             exit 1
           }
 
       - name: Prepare the toolchain and secrets
         env:
-          BWS_ACCESS_TOKEN: \${{ secrets.BWS_ACCESS_TOKEN }}
+          ${bootstrap}: \${{ secrets.${bootstrap} }}
         run: bash scripts/lisa-remote-env/setup.sh
 
       - name: Run one ${name} cycle
         env:
-          BWS_ACCESS_TOKEN: \${{ secrets.BWS_ACCESS_TOKEN }}
+          ${bootstrap}: \${{ secrets.${bootstrap} }}
         run: |
           set -euo pipefail
           node .claude/skills/lisa-remote-dispatch/scripts/dispatch.mjs \\
@@ -145,7 +154,7 @@ jobs:
       - name: Persist any credential rotation
         if: \${{ always() }}
         env:
-          BWS_ACCESS_TOKEN: \${{ secrets.BWS_ACCESS_TOKEN }}
+          ${bootstrap}: \${{ secrets.${bootstrap} }}
         run: |
           set -euo pipefail
           node .claude/skills/lisa-secrets-access/scripts/rotate-secret.mjs leases