@edgehero/pi-dispatch 2.0.0 → 2.1.0

package/.env.example

@@ -19,9 +19,10 @@
 # in two different places depending on which deployment reads it. Write the path out in full, not $HOME.
 
 # --- Provider credential ---
-# pi supports ~30 providers; set the key for the one you use, under the variable name pi expects.
+# pi supports ~40 providers; set the key for the one you use, under the variable name pi expects.
 # The worker forwards ONLY the configured provider's key into the job container -- nothing else.
-#   Anthropic: ANTHROPIC_API_KEY  (or ANTHROPIC_OAUTH_TOKEN, which takes precedence)
+#   Anthropic: ANTHROPIC_API_KEY  (pi reads ANTHROPIC_AUTH_TOKEN, a bearer token, and ANTHROPIC_OAUTH_TOKEN
+#              BEFORE it, so leave both unset: either one set silently wins over the API key)
 #   OpenAI:    OPENAI_API_KEY     Google: GEMINI_API_KEY     Groq: GROQ_API_KEY   ... etc.
 # You can LEAVE THIS BLANK if you are already logged into pi: when the env has no key, the worker reads the
 # API key from ~/.pi/agent/auth.json (host-side) and env-injects it -- on by default, nothing to set.

package/README.md

@@ -12,7 +12,9 @@ from cron triggers, or from forge events that the
 
 ## Start
 
-You need Docker or Podman, Node 22.19 or newer, and an API key for a model provider that pi supports.
+You need Docker or Podman and Node 22.19 or newer on one machine that stays on (a Linux server or VM, or
+your own Mac or Windows machine with Docker Desktop), and an API key for a model provider that pi supports.
+pi-dispatch itself needs no AI key: the key is for pi, inside each job.
 
 ```bash
 mkdir my-dispatch && cd my-dispatch

package/deploy/com.pi-dispatch.worker.plist

@@ -15,7 +15,7 @@
   (`pi-dispatch service render` composes exactly that argv with this host's real paths; the wrapper
   refuses an empty argv rather than guessing what to run). NO secrets are inlined here: there is
   deliberately no EnvironmentVariables dict, since that would commit credentials into this file. The
-  wrapper reads `.env` at runtime instead (note the ANTHROPIC_OAUTH_TOKEN over ANTHROPIC_API_KEY
+  wrapper reads `.env` at runtime instead (note the ANTHROPIC_AUTH_TOKEN/ANTHROPIC_OAUTH_TOKEN over ANTHROPIC_API_KEY
   precedence trap documented in the wrapper).
 
   Graceful shutdown needs NO macOS-specific code: `launchctl bootout` sends SIGTERM, which the wrapper

package/deploy/worker-env-wrapper.cmd

@@ -21,7 +21,7 @@ REM     `pi-dispatch service install` passes them via nssm AppParameters. This w
 REM     decides WHAT to run -- only the env it runs in and what its exit code means -- so an empty
 REM     argument list is a configuration error, refused below.
 REM
-REM TRAP: inside pi, ANTHROPIC_OAUTH_TOKEN silently takes precedence over ANTHROPIC_API_KEY. Set exactly
+REM TRAP: inside pi, ANTHROPIC_AUTH_TOKEN and ANTHROPIC_OAUTH_TOKEN silently take precedence over ANTHROPIC_API_KEY. Set exactly
 REM one in `.env`.
 REM
 REM `.env` FORMAT for this loader: KEY=VALUE, one per line. Values MUST be UNQUOTED -- cmd's `set` keeps

package/deploy/worker-env-wrapper.sh

@@ -24,9 +24,9 @@
 # profile happens to export. Nothing here contains a credential -- the secrets live in `.env`, which is
 # gitignored and read at runtime.
 #
-# TRAP: inside pi, `ANTHROPIC_OAUTH_TOKEN` silently takes precedence over `ANTHROPIC_API_KEY`. Set exactly
-# one in `.env`; this wrapper only ADDS the `.env` vars on top of the current environment, it does not
-# clear a stray pre-existing one, so a leaked host `ANTHROPIC_OAUTH_TOKEN` would still win.
+# TRAP: inside pi, `ANTHROPIC_AUTH_TOKEN` and `ANTHROPIC_OAUTH_TOKEN` silently take precedence over
+# `ANTHROPIC_API_KEY`. Set exactly one in `.env`; this wrapper only ADDS the `.env` vars on top of the
+# current environment, it does not clear a stray pre-existing one, so a leaked host token would still win.
 #
 # One worker per host (DES-CONCURRENCY-3): parallelism is PI_CONCURRENCY inside the single process, not
 # multiple daemons. Requires the AOF-enabled Valkey from deploy/docker-compose.yml.

package/package.json

@@ -1,6 +1,6 @@
 {
   "name": "@edgehero/pi-dispatch",
-  "version": "2.0.0",
+  "version": "2.1.0",
   "type": "module",
   "description": "The pi-dispatch worker and CLI: runs the pi coding agent as a self-hosted service, one locked down Docker or Podman container per job, with spend caps checked before anything is spent, plus init, up, doctor and service install.",
   "keywords": [
@@ -98,7 +98,7 @@
     "start": "node src/cli.mjs worker"
   },
   "dependencies": {
-    "@earendil-works/pi-ai": "0.80.7",
+    "@earendil-works/pi-ai": "0.99.1",
     "@octokit/auth-app": "8.2.0",
     "@octokit/rest": "22.0.1",
     "bullmq": "5.80.4",

package/src/doctor.mjs

@@ -93,7 +93,7 @@ import { BOOT_REFUSING_JOB_USER_CAUSES, DAEMON_FACTS_TIMEOUT_MS, JOB_USER_FIX, m
 import { parseSecretProfiles } from "./secret-profiles.mjs";
 // The OAuth-suffix rule and the variable it selects live in their own import-free module so the worker
 // can share them: doctor NAMES a variable and env-allowlist WRITES one, and they must never differ.
-import { OAUTH_KEY_RE, apiKeyVariable } from "./provider-key.mjs";
+import { apiKeyVariable, nonApiKeyKind } from "./provider-key.mjs";
 import { parseTriggers } from "./triggers.mjs";
 import { cronPlacement } from "./schedules.mjs";
 
@@ -3468,9 +3468,10 @@ function providerKeyCheck({ provider, env, agentDir, oracle, nodeOk }) {
 	// still refused -- one step further down, against the variable pi actually reads, where it is a fact
 	// about THAT credential rather than a reason to pretend the variable is unset.
 	const set = candidates.filter((name) => (env[name] ?? "") !== "");
-	// The variable to TELL an operator to set is never the OAuth token, and it is the SAME choice the
-	// worker makes when it writes an `auth.json` key into a container (issue #311). One function, one
-	// module, so a doctor line cannot name a variable the job path does not use.
+	// The variable to TELL an operator to set is never the OAuth token or the bearer token, and it is the
+	// SAME choice the worker makes when it writes an `auth.json` key into a container (issue #311; the
+	// bearer half is issue #509). One function, one module, so a doctor line cannot name a variable the job
+	// path does not use.
 	const apiKeyVar = apiKeyVariable(candidates);
 
 	if (set.length > 0) {
@@ -3489,19 +3490,57 @@ function providerKeyCheck({ provider, env, agentDir, oracle, nodeOk }) {
 				fix: `set a real value for ${using}, or unset it: pi reads it as present, so every job spends a container to fail auth`,
 			};
 		}
-		if (!OAUTH_KEY_RE.test(using)) return { ok: true, label: `Provider key set (${provider}: ${using})` };
+		const kind = nonApiKeyKind(using);
+		if (kind === null && isOAuthTokenValue(provider, env[using])) {
+			// The variable is the API key's, the VALUE is a subscription login: pi decides by the value
+			// (anthropic-messages.js `isOAuthToken`, a substring test for "sk-ant-oat"), not by the name, and
+			// sends it as `Authorization: Bearer` with Claude Code's identity headers. So it is the OAuth
+			// case under the API key's name, and it gets that warning rather than a green line.
+			return {
+				ok: false,
+				warn: true,
+				label: `Provider key set (${provider}: ${using}) -- but the value is an OAuth/subscription token, not an API key`,
+				fix: `put a real API key in ${using}: pi recognises the value as a subscription login whatever variable holds it and sends it as an Authorization: Bearer header; it expires, and the container cannot refresh it`,
+			};
+		}
+		if (kind === null) return { ok: true, label: `Provider key set (${provider}: ${using})` };
 		// Warn, not fail, and the choice is deliberate: the worker forwards this variable and the job WILL
 		// run, so failing here would put doctor in disagreement with the worker -- the exact disease this
 		// issue is about. What doctor must stop doing is what it did before: pass in silence, as though a
 		// subscription login were a service credential.
 		const shadowed = set[1] ?? null;
+		// The pi login this token silently displaces. The worker takes the ENVIRONMENT first and reads
+		// auth.json only when the environment holds no candidate, while pi on this host takes a stored
+		// api_key credential FIRST (pi-ai/dist/auth/helpers.js: "a stored credential key wins"). So with both
+		// present the job spends the token and pi on the host spends the stored key, and without this line
+		// nothing says so. Appended only to the fix lines for a token with no other env candidate beside it:
+		// with one, that env key is the ignored credential and the line already names it.
+		const ignoredLogin = env.PI_AUTH_FROM_PI !== "0" && usablePiLoginKey(agentDir, provider) !== null
+			? `; the API key in pi auth.json is NOT used while ${using} is set (the worker reads the environment first, although pi on this host would use the stored key): unset ${using} to spend the pi login, or keep it only if this token is the credential you mean jobs to spend`
+			: "";
+		if (kind === "bearer") {
+			// The bearer token (ANTHROPIC_AUTH_TOKEN at the pi 0.99.1 pin, issue #509) gets the OAuth token's
+			// treatment, a forwarded variable and a warning, and a line of its own because the hazard is a
+			// different one: it is often a real gateway credential rather than a login that expires, but pi
+			// reads it BEFORE the API key and sends it as `Authorization: Bearer`, so while it is set the API
+			// key is ignored. The API-key variable is named whether or not it is set, because an operator who
+			// sets it later without unsetting this one gets no change at all.
+			return {
+				ok: false,
+				warn: true,
+				label: `Provider key set (${provider}: ${using}) -- a bearer token, not an API key`,
+				fix: shadowed
+					? `unset ${using}: pi reads it BEFORE ${shadowed} and sends it as an Authorization: Bearer header, so every job spends it and ${shadowed} is ignored`
+					: `set ${apiKeyVar} and unset ${using}: pi reads ${using} BEFORE ${apiKeyVar} and sends it as an Authorization: Bearer header, so while it is set ${apiKeyVar} is ignored${ignoredLogin}`,
+			};
+		}
 		return {
 			ok: false,
 			warn: true,
 			label: `Provider key set (${provider}: ${using}) -- an OAuth/subscription login, not an API key`,
 			fix: shadowed
 				? `unset ${using}: pi reads it BEFORE ${shadowed}, so every job spends the subscription login and your API key is ignored`
-				: `set ${apiKeyVar} instead -- an OAuth/subscription token expires, the container cannot refresh it, and it is not the credential for an unattended service`,
+				: `set ${apiKeyVar} instead -- an OAuth/subscription token expires, the container cannot refresh it, and it is not the credential for an unattended service${ignoredLogin}`,
 		};
 	}
 
@@ -3525,6 +3564,16 @@ function providerKeyCheck({ provider, env, agentDir, oracle, nodeOk }) {
 		// itself when IT reads auth.json, but this service forwards the value into a container where it is
 		// read raw, so a login stored that way is not a key this deployment can spend.
 		if (cred?.type === "api_key" && key && !key.startsWith("!") && !key.includes("$") && key.trim()) {
+			if (isOAuthTokenValue(provider, key)) {
+				// The env arm's value rule, for the same reason: the worker writes this under the API key's
+				// name and pi sends it as a subscription login anyway.
+				return {
+					ok: false,
+					warn: true,
+					label: `Provider key set (${provider}) -- from pi auth.json, but the stored key is an OAuth/subscription token, not an API key`,
+					fix: `run \`pi login\` with a real API key for ${provider}: pi recognises the stored value as a subscription login and sends it as an Authorization: Bearer header; it expires, and the container cannot refresh it`,
+				};
+			}
 			return { ok: true, label: `Provider key set (${provider}) -- from pi auth.json` };
 		}
 		if (cred?.type === "api_key" && key && (key.startsWith("!") || key.includes("$")))
@@ -3542,6 +3591,32 @@ function providerKeyCheck({ provider, env, agentDir, oracle, nodeOk }) {
 	};
 }
 
+/**
+ * pi's own test for a subscription token in an API-key slot, restated: `isOAuthToken` in
+ * pi-ai/dist/api/anthropic-messages.js is `apiKey.includes("sk-ant-oat")`, applied to the value whatever
+ * variable carried it. Restricted to `anthropic`, the provider whose credential this is; the value itself is
+ * never printed.
+ */
+function isOAuthTokenValue(provider, value) {
+	return provider === "anthropic" && typeof value === "string" && value.includes("sk-ant-oat");
+}
+
+/**
+ * The API key a pi login holds for `provider`, when it is one the worker would forward (a non-blank string
+ * that is not pi's command or variable-reference form), else null. The same acceptance the auth.json arm of
+ * providerKeyCheck applies; never throws, never printed.
+ */
+function usablePiLoginKey(agentDir, provider) {
+	let cred;
+	try {
+		cred = JSON.parse(readFileSync(join(agentDir, "auth.json"), "utf8"))?.[provider];
+	} catch {
+		return null;
+	}
+	const key = cred?.type === "api_key" && typeof cred.key === "string" ? cred.key : null;
+	return key && key.trim() && !key.startsWith("!") && !key.includes("$") ? key : null;
+}
+
 /**
  * pi reads no API-key variable for this id, and the two reasons need different fixes -- which is exactly
  * the distinction `findEnvKeys`'s single `undefined` cannot make, and the reason issue #286 needed a

package/src/egress.mjs

@@ -40,9 +40,10 @@ import { makeDetachGate } from "./netns-keeper.mjs";
  *     Hence a hostname allowlist and no address rule that allows anything, which is the mechanism OQ-004's
  *     close condition actually names (the proxy's one address rule only denies this host's loopback and
  *     link-local addresses, issue #428).
- *     BUT THAT WAS MEASURED WITHOUT PI LOADED (issue #427). The pinned pi 0.80.7 depends on npm `undici`
- *     8.5.0, whose load replaces the global dispatcher the flag installs with one that ignores the proxy
- *     variables, so in the runner the provider call went direct and every egress-armed job died at its first
+ *     BUT THAT WAS MEASURED WITHOUT PI LOADED (issue #427). pi depends on npm `undici` (8.5.0 at the 0.80.7
+ *     pin where this was measured, 8.10.2 at the 0.99.1 pin, where loading pi was re-measured to drop the
+ *     env proxy the same way), whose load replaces the global dispatcher the flag installs with one that
+ *     ignores the proxy variables, so in the runner the provider call went direct and every egress-armed job died at its first
  *     turn. The runner now re-installs an env-proxy dispatcher after loading pi
  *     (image/runner/src/env-proxy.mjs), and doctor's canary takes that same path instead of a plain fetch.
  */

package/src/env-allowlist.mjs

@@ -1,12 +1,13 @@
 /**
  * Build the EXACT environment a job container receives. Never a pass-through.
  *
- * `no-broad-env-into-container` is a BLOCKER, and for good reason: `ANTHROPIC_OAUTH_TOKEN`
- * silently outranks `ANTHROPIC_API_KEY`, so one stray host variable would redirect which
- * credential every job spends, with no error and no log line. So we forward a closed set.
+ * `no-broad-env-into-container` is a BLOCKER, and for good reason: `ANTHROPIC_OAUTH_TOKEN` (and, from
+ * the pi 0.99.1 pin on, `ANTHROPIC_AUTH_TOKEN` ahead of it) silently outranks `ANTHROPIC_API_KEY`, so one
+ * stray host variable would redirect which credential every job spends, with no error and no log line.
+ * So we forward a closed set.
  *
  * The provider key variable is DERIVED from pi's own table, not hardcoded. Deriving it means any of
- * pi's ~30 providers works with no code change here, and the list cannot drift when pi adds one, as a
+ * pi's ~40 providers works with no code change here, and the list cannot drift when pi adds one, as a
  * hand-copied table would. `getApiKeyEnvVars` (that table) is intentionally NOT exported by pi, which
  * is why `providerKeyCandidates` below has to recover it a different way.
  *
@@ -89,10 +90,12 @@ export function providerKeyCandidates(provider) {
  * `getProviders` from "/compat", which is a @deprecated alias for this exact function and reaching it
  * means loading compat's module-scope provider registration.
  *
- * Only ever consulted AFTER `providerKeyCandidates` comes back empty, and the order is load-bearing:
- * the catalog is NOT a superset of the ids `findEnvKeys` answers for. `radius` is a purely dynamic
- * provider with a real key variable (PI_GATEWAY_API_KEY) and no catalog entry, so asking this first
- * would call a working configuration unknown.
+ * Only ever consulted AFTER `providerKeyCandidates` comes back empty. At the 0.80.7 pin that order was
+ * load-bearing: `radius` was a purely dynamic provider with a real key variable and no catalog entry, so
+ * asking this first would have called a working configuration unknown. At the 0.99.1 pin (issue #509)
+ * radius is a builtin provider (key variable RADIUS_API_KEY) and the catalog covers every id pi reads a key
+ * for; env-allowlist.test.mjs pins that, and the order stays because it costs nothing and is the safe one
+ * the day the two diverge again.
  */
 export function piProviders() {
 	return getBuiltinProviders();
@@ -129,6 +132,24 @@ export function resolveProviderCredential({ provider, hostEnv, authFromPi = fals
 	const held = providerKeyCandidates(provider)
 		.map((name) => [name, hostEnv[name]])
 		.filter(([, value]) => value);
+	// EVERY held candidate is forwarded, in pi's order, including the two that are not API keys: a host
+	// ANTHROPIC_OAUTH_TOKEN and (from the 0.99.1 pin, issue #509) a host ANTHROPIC_AUTH_TOKEN, which pi reads
+	// FIRST among the variables and sends as `Authorization: Bearer`. Forwarded rather than refused, and the
+	// choice is the same one for both: the operator put the variable in the worker's environment, a gateway
+	// bearer token is a legitimate service credential, and the job env should carry what the worker's own
+	// environment says rather than a filtered version of it.
+	//
+	// That does NOT make the job agree with pi on this host in every case, and the case where it does not
+	// is stated rather than implied: the ENVIRONMENT is this function's first source and auth.json only its
+	// fallback, while pi itself takes a stored api_key credential FIRST (pi-ai/dist/auth/helpers.js, "a
+	// stored credential key wins") and the environment only without one. So with an api_key login in
+	// auth.json AND a host token set, the job spends the token while `pi` on the host would spend the stored
+	// key. Kept that way because the env-first order is this function's documented contract (its header)
+	// and the token is the operator's explicit setting; `doctor` is where it is said out loud, a warning
+	// that names the API key the token shadows and, in this case, that the auth.json key is not used while
+	// the token is set.
+	// What is NEVER done is WRITING an auth.json key under either token name: that choice is
+	// `apiKeyVariable`'s, below.
 	if (held.length > 0) {
 		return Object.fromEntries(held);
 	}
@@ -215,8 +236,8 @@ function credentialFromPiAuth(provider, agentDir, readFile, { hostEnv = {}, forw
 	const name = resolveEnvName(provider);
 	if (!name) {
 		// Two different facts, and they need different fixes -- the same split `doctor` makes, in the same
-		// order (candidates first, catalog second: `radius` has a key variable and no catalog entry, so
-		// asking membership first would call a working configuration unknown). The old message said "set it
+		// order (candidates first, catalog second: at 0.80.7 `radius` had a key variable and no catalog entry,
+		// so asking membership first would have called a working configuration unknown). The old message said "set it
 		// in the worker environment manually" for BOTH, which for the first is advice `doctor` correctly
 		// calls impossible: there is no variable to set.
 		if (piProviders().includes(provider)) {
@@ -239,7 +260,7 @@ function credentialFromPiAuth(provider, agentDir, readFile, { hostEnv = {}, forw
  * plus a conventional `<PROVIDER>_API_KEY`/`_KEY`. That convention is the part that drifts, and it was
  * wrong for 13 of the 34 provider ids that have a key variable at the pin -- `google` is
  * `GEMINI_API_KEY`, `huggingface` is `HF_TOKEN`, `moonshotai` is `MOONSHOT_API_KEY`, `github-copilot` is
- * `COPILOT_GITHUB_TOKEN`, `radius` is `PI_GATEWAY_API_KEY` -- so for those pi recognized nothing and a
+ * `COPILOT_GITHUB_TOKEN`, `radius` was `PI_GATEWAY_API_KEY` (RADIUS_API_KEY at 0.99.1) -- so for those pi recognized nothing and a
  * valid `pi login` refused every job. The convention happening to be right for the other 21 is what let
  * this survive: `anthropic` and `openai` are both in that set.
  *
@@ -251,7 +272,9 @@ function credentialFromPiAuth(provider, agentDir, readFile, { hostEnv = {}, forw
  * environment where every name is present -- which also closes a hermeticity hole the synthetic object
  * had: pi's `getProviderEnvValue` falls back to the real `process.env`, so on a host that exported
  * `ANTHROPIC_OAUTH_TOKEN` the old code resolved to THAT name. `apiKeyVariable` then picks the same
- * variable `doctor` names, from the same module, so the two cannot diverge again.
+ * variable `doctor` names, from the same module, so the two cannot diverge again. It skips both
+ * non-API-key kinds: the OAuth token, and (from the 0.99.1 pin, issue #509) the bearer token
+ * ANTHROPIC_AUTH_TOKEN, which pi lists first and sends as `Authorization: Bearer`.
  */
 function resolveEnvName(provider) {
 	return apiKeyVariable(providerKeyCandidates(provider));

package/src/host-pi.mjs

@@ -15,7 +15,7 @@
  * What it must never become. Nothing on the worker's BOOT path may import this file. It reads host paths and
  * may spawn a package manager, and neither belongs anywhere near `start.mjs`.
  *
- * Everything here MIRRORS a private detail of the pinned pi (0.80.7) rather than calling it: pi exports no
+ * Everything here MIRRORS a private detail of the pinned pi (0.99.1) rather than calling it: pi exports no
  * public answer to "where is this package installed" or "is this resource enabled", and importing the whole
  * coding-agent SDK to read two well-known paths is not worth the weight. That mirroring is a real risk --
  * pi could change the grammar and we would silently start staging something the operator turned off -- so it
@@ -66,7 +66,12 @@ export const PINNED_PI_NEEDLES = {
 		"function isEnabledByOverrides(filePath, patterns, baseDir) {",
 		// The npm spec split that yields a name from `@scope/name@version`.
 		"const match = spec.match(/^(@?[^@]+(?:\\/[^@]+)?)(?:@(.+))?$/);",
+		// Built-in extensions (0.99.1, issue #509) are addressed in the SAME `extensions` list as files, as
+		// `builtin:<name>` paths, and resolved in a loop of their own. The mirror ignores those entries
+		// (see isOverridePattern); these two pin that they are still a separate namespace resolved apart.
+		"const path = `${BUILTIN_PATH_PREFIX}${name}`;",
 	],
+	"dist/core/source-info.js": ['export const BUILTIN_PATH_PREFIX = "builtin:";'],
 	"dist/core/settings-manager.d.ts": [
 		"export type PackageSource = string | {",
 		"    autoload?: boolean;",
@@ -148,9 +153,20 @@ export function parsePackageSource(source) {
 	return { kind: "git", name, spec: null, requested: null, raw };
 }
 
-/** The prefixes pi treats as overrides; a plain pattern is not one (getOverridePatterns). */
+/** pi's BUILTIN_PATH_PREFIX (source-info.js): a path naming a built-in extension, never a file. */
+const BUILTIN_PATH_PREFIX = "builtin:";
+
+/**
+ * The override patterns that can address a FILE: pi's prefixes (getOverridePatterns), minus the ones whose
+ * body is a `builtin:<name>` path. From the 0.99.1 pin on (issue #509) the same `extensions` list holds
+ * `-builtin:mcp` and friends, which pi resolves against its built-in extensions only, never against a file
+ * on disk. Kept, they would change no verdict pi reaches, but they would still make a settings file with
+ * only a builtin entry look like one with overrides, and a `!builtin:*` glob would mark every extension
+ * "could not be evaluated", which is a note about nothing. Dropped here, before any verdict is computed.
+ */
 function isOverridePattern(pattern) {
-	return typeof pattern === "string" && (pattern.startsWith("!") || pattern.startsWith("+") || pattern.startsWith("-"));
+	if (typeof pattern !== "string" || !(pattern.startsWith("!") || pattern.startsWith("+") || pattern.startsWith("-"))) return false;
+	return !normalizeExact(pattern.slice(1)).startsWith(BUILTIN_PATH_PREFIX);
 }
 
 /** Any minimatch magic we decline to interpret. Deliberately over-broad: a false "unknown" only costs a note. */

package/src/packages.mjs

@@ -61,7 +61,7 @@ export const NPM_NAME_RE = /^(?:@[a-z0-9][a-z0-9._-]*\/)?[a-z0-9][a-z0-9._-]*$/;
  * would add an edge to the import-pi <-> packages cycle that only survives because both sides use their
  * bindings at call time.
  *
- * This list is pi's, not ours: at the 0.80.7 pin `collectPackageResources` falls through to exactly these
+ * This list is pi's, not ours: at the 0.99.1 pin (as at 0.80.7) `collectPackageResources` falls through to exactly these
  * four directory names when `readPiManifest` returns null, so a package with no `pi` key and a `skills/`
  * dir IS a pi package. See host-pi.mjs's PINNED_PI_NEEDLES for the assertion that keeps that true.
  */
@@ -281,7 +281,7 @@ export function readStageManifest({ globalPiDir, readFile = readFileSync, fileEx
  * readStageManifest's policy, because the consumers are advisory (doctor's per-trigger flow lines,
  * and issue #188's topology) and a half-staged tree must degrade to "nothing visible", not a crash.
  *
- * The semantics mirror pi's collectPackageResources at the 0.80.7 pin EXACTLY, because an enumerator
+ * The semantics mirror pi's collectPackageResources at the 0.99.1 pin EXACTLY (unchanged since 0.80.7), because an enumerator
  * that agrees with pi by hand is how doctor comes to report a tier pi then ignores:
  *   - a `pi` manifest object means its `skills` entries are the ONLY sources -- a manifest WITHOUT a
  *     `skills` key contributes NO skills and gets NO convention fallback (readPiManifest short-circuits

package/src/pricing.mjs

@@ -29,8 +29,10 @@ import { getBuiltinModel, getBuiltinModels, getBuiltinProviders } from "@earendi
 /**
  * Every builtin pi-ai model, flattened to `{ provider, id, cost }`. `cost` is pi-ai's ModelCost
  * object passed BY REFERENCE -- it is pi-ai's data, callers treat it read-only. Rates are USD per
- * 1M tokens; an all-zero table is CORRECT data for subscription-backed providers (kimi-coding,
- * zai-coding-cn), not missing data -- `isZeroRated` is how callers tell the two apart.
+ * 1M tokens. An all-zero table is pi-ai's data, not missing data: at the 0.99.1 pin the all-zero
+ * providers include the qwen-token-plan family. It is NOT a subscription signal any more (issue #509):
+ * kimi-coding and zai-coding-cn, all-zero at 0.80.7, now carry implied API-equivalent rates on most
+ * models although their plans are prepaid, and plenty of pay-per-token providers list a free model.
  */
 export function listPricedModels() {
 	const out = [];
@@ -58,9 +60,11 @@ export function getPricedModel(provider, id) {
 }
 
 /**
- * True when all four base rates are zero -- the signature of a subscription-backed provider, whose
- * runs meter at $0 because the plan is prepaid (see subscriptions.mjs for where the real price
- * lives). Tiers are deliberately ignored: a zero-rate provider ships no tiers, and a priced provider
+ * True when all four base rates are zero: pi-ai rated the model at $0, which is a fact about the table
+ * and nothing more. It USED to be read as the signature of a subscription-backed provider; at the 0.99.1
+ * pin it is not (issue #509: kimi-coding and zai-coding-cn carry implied prices, and free models of
+ * metered providers are zero too), so a subscription is known only from subscriptions.json. Tiers are
+ * deliberately ignored: a zero-rate provider ships no tiers, and a priced provider
  * with a zero base rate somewhere does not become "free" by it. Null/malformed input is false --
  * "not zero-rated" is the safe answer for a thing that is not a model.
  */

package/src/processor.mjs

@@ -766,9 +766,10 @@ export async function runJob(job, deps) {
 			//   - the worker WRITES the name: buildContainerEnv assigns the provider credential and
 			//     PI_FORWARD_ENV before this feature's values, so the trigger's value replaces the operator's
 			//     and every job of that trigger spends the trigger author's key;
-			//   - the worker does NOT write the name but pi READS it first: the OAuth token variable is
-			//     deliberately never written (apiKeyVariable skips it), so a trigger binding it lands beside
-			//     the operator's key and outranks it in pi's own precedence.
+			//   - the worker does NOT write the name but pi READS it first: the OAuth token variable, and from
+			//     the 0.99.1 pin the bearer ANTHROPIC_AUTH_TOKEN (issue #509), are deliberately never written
+			//     (apiKeyVariable skips both), so a trigger binding one lands beside the operator's key and
+			//     outranks it in pi's own precedence.
 			// The old message asserted the first for both, which is exactly backwards for the second.
 			await comment(job, `Refused: this trigger's \`run.secrets\` binds \`${resolved.reserved}\`, which is a variable this deployment already uses for the job's own credentials. Whichever of the two values reached the container, one of them would be silently ignored. Rename it in the triggers file. Not run.`);
 			// The variable NAME only. It is the operator's own choice of name, not payload, and naming it is what

package/src/provider-key.mjs

@@ -27,15 +27,40 @@
 // worker/test/provider-key.test.mjs -- never against a second copy of a table.
 export const OAUTH_KEY_RE = /_OAUTH_TOKEN$/;
 
+// The second fact of the same kind, added with the pi 0.99.1 bump (issue #509): a variable pi reads for a
+// provider that is NOT an API key, because pi sends it as a different header. At 0.99.1 pi lists
+// ANTHROPIC_AUTH_TOKEN FIRST for `anthropic` (pi-ai/dist/env-api-keys.js getApiKeyEnvVars), and its
+// resolver (pi-ai/dist/providers/anthropic.js) sends it as `Authorization: Bearer <value>` AHEAD of both
+// ANTHROPIC_OAUTH_TOKEN and ANTHROPIC_API_KEY. Without this rule `apiKeyVariable` picked it: an auth.json
+// API key would have been written into the container under the bearer name, so pi would send it as
+// `Authorization: Bearer` rather than as the `x-api-key` an API key travels in, and doctor would have told
+// an operator to set the bearer variable.
+// pi's own `getEnvApiKey` skips it for the same reason, which is the evidence that the distinction is real
+// rather than ours. A suffix rule, for OAUTH_KEY_RE's reason: a set naming one variable would silently
+// bless the next provider's bearer variable. Pinned against pi in worker/test/provider-key.test.mjs.
+export const BEARER_KEY_RE = /_AUTH_TOKEN$/;
+
+/**
+ * Why a variable pi reads is not an API key, or null when it is one. The two answers need different
+ * advice, so the caller is told which: an OAuth token is a subscription login that expires, a bearer token
+ * is a credential pi sends in another header and reads BEFORE the API key.
+ */
+export function nonApiKeyKind(name) {
+	if (OAUTH_KEY_RE.test(name)) return "oauth";
+	if (BEARER_KEY_RE.test(name)) return "bearer";
+	return null;
+}
+
 /**
  * The api-key variable to write and to name, given pi's candidate list for a provider in pi's own
- * precedence order. Never the OAuth token, whatever that precedence says: pi returns
- * ANTHROPIC_OAUTH_TOKEN first, "set your subscription login" is wrong advice for an unattended service,
- * and an api-key credential written under that name would be a value whose variable lies about what it
- * is. Falls back to the first candidate only for a provider with no non-OAuth variable at all, which is
- * no provider pi has today; `null` for a provider pi reads no key variable for, which is the caller's
- * cue to refuse rather than to guess.
+ * precedence order. Never the OAuth token and never the bearer token, whatever that precedence says: pi
+ * returns ANTHROPIC_AUTH_TOKEN then ANTHROPIC_OAUTH_TOKEN before ANTHROPIC_API_KEY, "set your subscription
+ * login" is wrong advice for an unattended service, and an api-key credential written under either name
+ * would be a value whose variable lies about what it is (under the bearer name pi would also send it in
+ * the wrong header). Falls back to the first candidate only for a provider with no API-key variable at
+ * all, which is no provider pi has today; `null` for a provider pi reads no key variable for, which is the
+ * caller's cue to refuse rather than to guess.
  */
 export function apiKeyVariable(candidates) {
-	return candidates.find((name) => !OAUTH_KEY_RE.test(name)) ?? candidates[0] ?? null;
+	return candidates.find((name) => nonApiKeyKind(name) === null) ?? candidates[0] ?? null;
 }

package/src/provider-steering.mjs

@@ -7,7 +7,8 @@
  * nothing that says where the request goes, and that is the worse of the two: substitution spends the
  * trigger author's money, redirection sends the OPERATOR'S credential to a host the trigger chose.
  *
- * Measured against the 0.80.7 pin with a stubbed fetch and no real key, three providers, three routes:
+ * Measured against the 0.80.7 pin with a stubbed fetch and no real key, three providers, three routes (the
+ * derivation below was re-run at the 0.99.1 pin, issue #509):
  *   AZURE_OPENAI_BASE_URL   -> the request goes to the named host carrying `api-key`
  *   GOOGLE_GEMINI_BASE_URL  -> ... carrying `x-goog-api-key`
  *   AWS_ENDPOINT_URL        -> ... carrying a SigV4 signature over the operator's Bedrock credential
@@ -20,10 +21,11 @@
  * resolved provider, and the bound that gate keeps is deliberate and documented -- an `anthropic` job may
  * bind `OPENAI_API_KEY` for a flow that talks to OpenAI itself, because refusing it would be this project
  * claiming a namespace it does not own. Including them here would have broken that bound ARBITRARILY: only
- * four of pi's thirty-one key variables happen to appear as literals in a scanned artifact, so
- * `OPENAI_API_KEY` would refuse while `GROQ_API_KEY` and `HF_TOKEN` stayed bindable, and the documented
- * rule would be false for reasons no operator could predict. They are subtracted, and the bolt subtracts
- * them the same way rather than by hand.
+ * five of pi's thirty-eight key variables (at the 0.99.1 pin) happen to appear as literals in a scanned
+ * artifact, so `OPENAI_API_KEY` would refuse while `GROQ_API_KEY` and `HF_TOKEN` stayed bindable, and the
+ * documented rule would be false for reasons no operator could predict. They are subtracted, and the bolt
+ * subtracts them the same way rather than by hand. ONE is kept, by name and for a stated reason, in
+ * `RETAINED_KEY_VARIABLES` below.
  * The AWS credential variables STAY, and they are not an exception: pi's key table has no entry for
  * `amazon-bedrock` at all (`providerKeyCandidates("amazon-bedrock")` is empty), so nothing else reserves
  * them and they are read by the SDK as provider configuration, which is exactly what this set is.
@@ -54,6 +56,13 @@
  * They subvert any provider call, but they are properties of the RUNTIME rather than of a provider, they
  * predate this gate, and `NODE_OPTIONS` additionally needs a file the attacker can place. They belong to
  * whatever closes the runtime-hijack question, not to a set derived from what pi reads about providers.
+ * The same holds for `HOME`, `PATH`, `APPDATA`, `USERPROFILE` and `XDG_CONFIG_HOME`, which the scan DOES
+ * reach from the 0.99.1 pin on (issue #509): the Anthropic SDK reads the four directory variables only to
+ * locate its default config directory (`core/credentials`), and `PATH` inside its agent toolset, which pi
+ * does not use. The bolt subtracts them by name, with that reason, and asserts the scan still finds each,
+ * so a subtraction that stopped being needed is removed rather than carried. `HOME` is reserved anyway,
+ * by `reserved-env.mjs`, because the worker writes it (issue #341). The Anthropic-specific switch for the
+ * same directory, `ANTHROPIC_CONFIG_DIR`, IS in the set: it names a credential location outright.
  *
  * And a bound on the whole family, which no document here stated before: a trigger author picks the
  * variable NAME and a vault REFERENCE, never a value. Exploiting any of these needs the operator's own
@@ -86,6 +95,20 @@
  * `https_proxy` outranks the egress policy's own variable in pi's reader. Only the schemes a provider call
  * can use are listed: `ws_proxy` and the rest are reachable in `getProxyEnv` but not from an HTTPS request.
  */
+/**
+ * Provider KEY variables that stay reserved here although the bolt subtracts key variables in general.
+ *
+ * `ANTHROPIC_AUTH_TOKEN` was in this set from issue #314 on, because at 0.80.7 it was read only by the
+ * Anthropic SDK and was no key variable of pi's. At the 0.99.1 pin pi lists it FIRST among anthropic's key
+ * variables and sends it as `Authorization: Bearer` ahead of the API key (issue #509), which would move it
+ * to the per-provider pre-spend gate and make it bindable again for every non-anthropic job. Kept instead,
+ * because a version bump must not widen what a trigger may bind without an operator deciding it, and no
+ * deployment can be relying on binding a name that has been refused at load since #314. The bolt asserts it
+ * is still both a key variable pi reads and a name the scan finds, so the day either stops holding this
+ * list is revisited rather than carried.
+ */
+const RETAINED_KEY_VARIABLES = ["ANTHROPIC_AUTH_TOKEN"];
+
 const UNREACHABLE_BY_SCAN = [
 	"AWS_CONFIG_FILE",
 	"AWS_ENDPOINT_URL",
@@ -99,11 +122,27 @@ const UNREACHABLE_BY_SCAN = [
 ];
 
 export const PROVIDER_STEERING_VARS = new Set([
-	"ANTHROPIC_AUTH_TOKEN",
 	"ANTHROPIC_BASE_URL",
+	"ANTHROPIC_CONFIG_DIR",
+	"ANTHROPIC_CUSTOM_HEADERS",
+	"ANTHROPIC_ENVIRONMENT_ID",
+	"ANTHROPIC_ENVIRONMENT_KEY",
+	"ANTHROPIC_FEDERATION_RULE_ID",
+	"ANTHROPIC_IDENTITY_TOKEN",
+	"ANTHROPIC_IDENTITY_TOKEN_FILE",
 	"ANTHROPIC_LOG",
+	"ANTHROPIC_ORGANIZATION_ID",
+	"ANTHROPIC_PROFILE",
+	"ANTHROPIC_SCOPE",
+	"ANTHROPIC_SERVICE_ACCOUNT_ID",
+	"ANTHROPIC_SESSION_ID",
+	"ANTHROPIC_WEBHOOK_SIGNING_KEY",
+	"ANTHROPIC_WORKSPACE_ID",
+	"ANTHROPIC_WORK_ID",
+	"ANTHROPIC_WORK_SECRET",
 	"AWS_ACCESS_KEY_ID",
 	"AWS_BEARER_TOKEN_BEDROCK",
+	"AWS_BEDROCK_BASE_URL",
 	"AWS_BEDROCK_FORCE_CACHE",
 	"AWS_BEDROCK_FORCE_HTTP1",
 	"AWS_BEDROCK_SKIP_AUTH",
@@ -121,8 +160,6 @@ export const PROVIDER_STEERING_VARS = new Set([
 	"AZURE_OPENAI_ENDPOINT",
 	"AZURE_OPENAI_RESOURCE_NAME",
 	"GCLOUD_PROJECT",
-	"GEMINI_NEXT_GEN_API_BASE_URL",
-	"GEMINI_NEXT_GEN_API_LOG",
 	"GOOGLE_API_KEY",
 	"GOOGLE_APPLICATION_CREDENTIALS",
 	"GOOGLE_CLOUD_LOCATION",
@@ -131,14 +168,18 @@ export const PROVIDER_STEERING_VARS = new Set([
 	"GOOGLE_GENAI_USE_ENTERPRISE",
 	"GOOGLE_GENAI_USE_VERTEXAI",
 	"GOOGLE_VERTEX_BASE_URL",
+	"KIMI_CODE_OAUTH_HOST",
+	"KIMI_OAUTH_HOST",
+	"OPENAI_ADMIN_KEY",
 	"OPENAI_API_VERSION",
 	"OPENAI_BASE_URL",
+	"OPENAI_CUSTOM_HEADERS",
 	"OPENAI_LOG",
 	"OPENAI_ORG_ID",
 	"OPENAI_PROJECT_ID",
 	"OPENAI_WEBHOOK_SECRET",
 	"PI_CACHE_RETENTION",
-	"PI_GATEWAY",
 	"PI_OAUTH_CALLBACK_HOST",
+	...RETAINED_KEY_VARIABLES,
 	...UNREACHABLE_BY_SCAN,
 ]);

package/src/secrets.mjs

@@ -298,7 +298,8 @@ export function makeSecretsResolver({
 		// prevent. Same conflated `undefined` as issue #286, one module over.
 		//
 		// It also closes a second hole that never needed auth.json. The worker never WRITES the OAuth variable
-		// (`apiKeyVariable` skips it deliberately) and pi reads it BEFORE `ANTHROPIC_API_KEY`, so a presence
+		// or (from the 0.99.1 pin, issue #509) the bearer ANTHROPIC_AUTH_TOKEN (`apiKeyVariable` skips both
+		// deliberately) and pi reads both BEFORE `ANTHROPIC_API_KEY`, so a presence
 		// filter held it only on hosts that happened to export it, and a trigger binding it outranked the
 		// operator's own key on the pure-env path too.
 		//

package/src/subscriptions.mjs

@@ -1,8 +1,12 @@
 /**
  * Operator-declared subscription plans (issue #53): the one place a flat-rate plan's real price can be
- * stated. Subscription-backed providers ship all-zero rate tables (pi-ai's kimi-coding and zai-coding-cn
- * both do), so their runs record cost 0 and read as FREE when they are PREPAID -- and the env boundary
- * REFUSES OAuth/subscription logins on purpose (env-allowlist.mjs: an expiring token cannot power an
+ * stated. pi-ai's rate table for a subscription-backed provider does not state the plan's price: at 0.80.7
+ * kimi-coding and zai-coding-cn shipped all-zero tables, so their runs recorded cost 0 and read as FREE
+ * when they were PREPAID; at the 0.99.1 pin most of their models carry an implied API-equivalent rate
+ * instead (issue #509), so the same prepaid runs now record a POSITIVE cost and read as METERED spend.
+ * Either way the table is the wrong price, and a zero rate is no longer even a hint that a plan exists
+ * (the qwen-token-plan family is all-zero, and so are free models of metered providers). And the env
+ * boundary REFUSES OAuth/subscription logins on purpose (env-allowlist.mjs: an expiring token cannot power an
  * unattended service), so no credential ever reaches the worker that could name the plan. An operator-side
  * declaration is therefore the only honest price source, and `subscriptions.json` is that declaration.
  *

package/src/triggers.mjs

@@ -167,7 +167,10 @@ export const REVIEW_STATES = new Set(["approved", "changes_requested", "commente
 const REVIEW_ACTION = "review_submitted";
 
 /**
- * The pi tool names a trigger may exclude (issue #291) -- the built-in set of the PINNED pi, 0.80.7.
+ * The pi tool names a trigger may exclude (issue #291) -- the built-in set of the PINNED pi, 0.99.1, in pi's
+ * own `allToolNames` order. `powershell` joined it at the 0.99.1 bump (issue #509): pi registers it as a
+ * built-in but does not activate it by default (`DEFAULT_TOOL_NAMES` is read, bash, edit, write), so a
+ * trigger that means "no shell" names it beside `bash`.
  * Hand-written because this validator is pure and pi-free (the worker does not depend on the agent
  * package), and therefore BOLTED twice to the artifact it restates: `worker/test/exclude-tools.pinned.test.mjs`
  * and `image/runner/test/pinned-api.test.mjs` both derive the set from the pinned package and fail with a
@@ -177,7 +180,7 @@ const REVIEW_ACTION = "review_submitted";
  * validation exists to close -- pi ignores unknown names in `excludeTools` without a diagnostic.
  */
 // EXPORTED for the two pinned-set bolts and for the admin, which states the vocabulary to an operator.
-export const EXCLUDABLE_TOOL_NAMES = new Set(["read", "bash", "edit", "write", "grep", "find", "ls"]);
+export const EXCLUDABLE_TOOL_NAMES = new Set(["read", "bash", "powershell", "edit", "write", "grep", "find", "ls"]);
 
 // A cron id flows into BullMQ's deterministic `repeat:<id>:<nextMillis>` jobId, so a `:` corrupts that
 // parse; the charset also excludes `:` and the dedicated check names the reason.