bitfab-cli 0.2.444 → 0.2.445

package/dist/index.js

@@ -30010,10 +30010,10 @@ var semver3 = __toESM(require_semver2(), 1);
 
 // ../bitfab-plugin-lib/dist/bakedSdkVersions.js
 var BAKED_SDK_VERSIONS = {
-  typescript: "0.64.22",
-  python: "0.64.20",
-  ruby: "0.64.18",
-  go: "0.64.19"
+  typescript: "0.64.23",
+  python: "0.64.21",
+  ruby: "0.64.19",
+  go: "0.64.20"
 };
 
 // ../bitfab-plugin-lib/dist/installedSdk.js
@@ -36782,7 +36782,7 @@ State who can start a replay: once GitHub registers the workflow, anyone with wr
 
 Edit the workflow directly for anything detection missed, such as a build step, code generation, a monorepo install filter, or a service, and pin any added action to a commit SHA. When the user normally starts replay through a wrapper that sets environment variables, add them to the replay step's env. Every variable read from a secret stays in that env as a GitHub expression reading secrets.<name>, which is how --cloud-secrets and the runner's empty-secret check find them; a secret stored under another name is mapped directly, such as OPENAI_API_KEY reading secrets.EVAL_OPENAI_API_KEY, and a non-secret value reads vars.<name>. When a setup step needs a credential file, write it under $RUNNER_TEMP with umask 077 and export its path through $GITHUB_ENV; do not use google-github-actions/auth or similar actions that write the key into the checked-out workspace. Do not copy deployment steps or secret values into the workflow.
 
-For BITFAB_API_KEY, have the user create a dedicated key for the runner on the Bitfab dashboard's API keys page, in the organization that holds the registry's traces, named for what it is (such as "GitHub cloud replay"), and set it by hand. Each replay started with bitfab-replay --cloud normally runs with the Bitfab API key of whoever started it, which the SDK stores through the GitHub CLI as a secret for that replay alone and deletes once the replay starts, so this key is the fallback for runs that cannot pass one, such as a dispatch from another workflow or a machine without the GitHub CLI. Keep the key_id input and the BITFAB_REPLAY_BITFAB_API_KEY line --cloud-init writes. When a workflow already exists, run --cloud-update (the same command as --cloud-init) anyway: it adds whichever of those lines is missing without touching the rest, and lists anything it could not place for you to add by hand. For the other secrets, when local environment files define them, ask once whether to copy them, then run bitfab-replay --cloud-secrets --env-file <file> --dry-run, then without --dry-run. It pipes values to gh on standard input, creates a missing Environment, and without the GitHub CLI returns createByHand with the page to create them on; relay that list instead of treating it as a failure. Never hand-extract a value with grep, cut, or a shell variable. Warn before copying a value a runner cannot use, such as a localhost URL. Setting secrets needs the same explicit authorization as any other remote write.
+For BITFAB_API_KEY, have the user create a dedicated key for the runner on the Bitfab dashboard's API keys page, in the organization that holds the registry's traces, named for what it is (such as "GitHub cloud replay"), and set it by hand. Each replay started with bitfab-replay --cloud runs as whoever started it, through a one-time token in the key_id input that only a run of that workflow, on that replay's branch, in that repository can trade for a short-lived key, which it proves with GitHub's OIDC token for the run. This secret is the key a run falls back to when no token can be passed, such as a dispatch from another workflow. Keep the key_id input and the id-token: write permission --cloud-init writes. When a workflow already exists, run --cloud-update (the same command as --cloud-init) anyway: it adds a missing key_id input and id-token: write permission, removes the BITFAB_REPLAY_BITFAB_API_KEY line older SDKs wrote (it made GitHub hand the runner every secret in the repository), leaves the rest alone, and lists anything it could not place for you to add by hand. Its result also lists in oldKeySecrets any BITFAB_REPLAY_KEY_* secrets an older SDK left in the repository, each a copy of the Bitfab API key of whoever started that replay. Name them to the user and ask once whether to delete them; on yes, run --cloud-update --remove-old-key-secrets, which returns removedOldKeySecrets and lists any it could not delete with the page to delete them on. For the other secrets, when local environment files define them, ask once whether to copy them, then run bitfab-replay --cloud-secrets --env-file <file> --dry-run, then without --dry-run. It pipes values to gh on standard input, creates a missing Environment, and without the GitHub CLI returns createByHand with the page to create them on; relay that list instead of treating it as a failure. Never hand-extract a value with grep, cut, or a shell variable. Warn before copying a value a runner cannot use, such as a localhost URL. Setting secrets needs the same explicit authorization as any other remote write.
 
 Each replay pushes a temporary bitfab-replay/<UUID> branch. For each push-triggered workflow or deployment in reviewPushTriggers, offer to exclude those branches: branches-ignore: [bitfab-replay/**] on a push trigger (or a last !bitfab-replay/** entry when it already lists branches), and git.deploymentEnabled {"bitfab-replay/**": false} in vercel.json. Ask before changing existing CI or deployments.`,
           next: "cloud/verify"

package/package.json

@@ -1,6 +1,6 @@
 {
   "name": "bitfab-cli",
-  "version": "0.2.444",
+  "version": "0.2.445",
   "description": "Install and configure the Bitfab plugin in Claude Code, Codex, or Cursor, or the Bitfab skill pack in Amp (Alpha).",
   "type": "module",
   "main": "dist/index.js",