@bridge_gpt/mcp-server 0.2.38 → 0.2.41

package/build/agent-launchers/executor-adapter.js

@@ -0,0 +1,136 @@
+/** Construct a supported capability. */
+export function supported(value) {
+    return { supported: true, value };
+}
+/** Construct an explicitly unsupported capability. */
+export function unsupported(reason, strategyId) {
+    return strategyId === undefined
+        ? { supported: false, reason }
+        : { supported: false, reason, strategyId };
+}
+/**
+ * The capability keys an adapter MUST supply as supported.
+ *
+ * Exported as a frozen tuple so the validator, the doctor renderer, and the
+ * tests all enumerate the same list. A capability added here is automatically
+ * enforced everywhere rather than in the one place someone remembered.
+ */
+export const REQUIRED_ADAPTER_CAPABILITIES = Object.freeze([
+    "executable",
+    "platform",
+    "headlessInvocation",
+    "mcpScoping",
+    "mcpInitParsing",
+    "auth",
+    "authFailureDetection",
+    "denyEnforcement",
+    "redaction",
+    "lifecycle",
+]);
+/**
+ * Read a capability's declared strategy ID, when it has one.
+ *
+ * Capability values are heterogeneous and only some carry `strategyId`, so this
+ * reads structurally rather than by capability key — a new capability with a
+ * strategy ID is picked up without editing this function.
+ */
+function readStrategyId(value) {
+    if (!value || typeof value !== "object")
+        return null;
+    const candidate = value.strategyId;
+    return typeof candidate === "string" && candidate.length > 0 ? candidate : null;
+}
+/**
+ * Validate that every required capability is present AND supported.
+ *
+ * Both failure modes produce a refusal, and the refusal names which one it was.
+ * Nothing here substitutes a default implementation, consults the host, or falls
+ * back to Claude behavior — the entire value of this function is that it has no
+ * escape hatch. It also never throws: a malformed adapter object degrades into
+ * refusals, because throwing would tempt a caller into a catch-and-continue that
+ * reintroduces exactly the defaulting this prevents.
+ */
+export function validateExecutorAdapterCapabilities(adapter) {
+    const identity = adapter.identity;
+    const refusals = [];
+    const capabilities = [];
+    for (const capability of REQUIRED_ADAPTER_CAPABILITIES) {
+        const declared = adapter[capability];
+        if (declared === undefined || declared === null) {
+            refusals.push({
+                capability,
+                kind: "absent",
+                reason: `required capability '${capability}' was not declared by adapter '${identity.adapterId}'`,
+            });
+            capabilities.push({
+                capability,
+                supported: false,
+                strategyId: null,
+                reason: "not declared",
+            });
+            continue;
+        }
+        if (declared.supported !== true) {
+            const reason = typeof declared.reason === "string" && declared.reason.length > 0
+                ? declared.reason
+                : `capability '${capability}' is declared unsupported`;
+            const refusal = { capability, kind: "unsupported", reason };
+            if (typeof declared.strategyId === "string")
+                refusal.strategyId = declared.strategyId;
+            refusals.push(refusal);
+            capabilities.push({
+                capability,
+                supported: false,
+                strategyId: typeof declared.strategyId === "string" ? declared.strategyId : null,
+                reason,
+            });
+            continue;
+        }
+        capabilities.push({
+            capability,
+            supported: true,
+            strategyId: readStrategyId(declared.value),
+            reason: null,
+        });
+    }
+    if (refusals.length > 0) {
+        return { ok: false, identity, refusals, capabilities };
+    }
+    return { ok: true, identity, capabilities };
+}
+/** Render a bounded, secret-free summary of why an adapter was refused. */
+export function formatAdapterRefusal(identity, refusals) {
+    const names = refusals.map((r) => `${r.capability} (${r.kind})`).join(", ");
+    return (`executor agent adapter '${identity.adapterId}' for agent '${identity.agentId}' is incomplete: ` +
+        `${names}. A missing or unsupported capability is never defaulted to host or Claude behavior.`);
+}
+// ---------------------------------------------------------------------------
+// Secret-safe diagnostics
+// ---------------------------------------------------------------------------
+/**
+ * Replace every occurrence of each declared secret's VALUE with a fixed marker.
+ *
+ * Implemented with `split`/`join` rather than a `RegExp`, and that choice is
+ * load-bearing twice over. A secret value is arbitrary text: built into a
+ * pattern it could throw on an unbalanced bracket (turning redaction into a
+ * crash), and used as a replacement string a `$&` or `$1` inside it would be
+ * re-expanded by the replacer (turning redaction into corruption). Literal
+ * splitting has neither failure mode and needs no escaping.
+ *
+ * Empty and non-string values are skipped: replacing every empty string would
+ * shred the diagnostic into markers while hiding nothing.
+ */
+export function redactAdapterDiagnostic(text, parentEnv, redaction) {
+    if (typeof text !== "string" || text.length === 0)
+        return "";
+    let output = text;
+    for (const name of redaction.secretEnvNames) {
+        const value = parentEnv[name];
+        if (typeof value !== "string" || value.length === 0)
+            continue;
+        if (!output.includes(value))
+            continue;
+        output = output.split(value).join(redaction.replacement);
+    }
+    return output;
+}

package/build/agent-registry.js

@@ -47,6 +47,34 @@ export const AGENT_REGISTRY = {
         // can be validated against a static allowlist.
         tierModels: { cheap: "haiku", basic: "sonnet", premium: "opus" },
         staticModelAliasAllowlist: ["haiku", "sonnet", "opus"],
+        // BAPI-781: the reference executor adapter. `managedCarriers` is EMPTY and
+        // `passthroughs` names only the operator's own OAuth variable — Bridge
+        // manages no Anthropic credential (BAPI-791), and `ANTHROPIC_API_KEY`
+        // appears in neither list.
+        executorAdapter: {
+            adapterId: "claude-reference",
+            strategyId: "claude-strict-mcp-v1",
+            adapterVersion: "1.0.0",
+            supportedPlatforms: ["darwin", "linux"],
+            capabilityStrategyIds: {
+                mcpScoping: "strict-mcp-config",
+                mcpInitParsing: "claude-system-init",
+                authFailureDetection: "claude-stream-json-result",
+                denyEnforcement: "claude-settings-deny",
+                redaction: "claude-env-name-redaction",
+                lifecycle: "claude-no-lifecycle",
+            },
+            managedCarriers: [],
+            passthroughs: [
+                {
+                    passthroughId: "claude-code-oauth-token",
+                    envName: "CLAUDE_CODE_OAUTH_TOKEN",
+                    billingClass: "subscription",
+                    ownership: "operator-owned",
+                    rule: "forward-when-present",
+                },
+            ],
+        },
     },
     "cursor-agent": {
         name: "cursor-agent",

package/build/agents.generated.js

@@ -26,6 +26,6 @@ export const AGENTS = {
             "model": "opus",
             "color": "yellow"
         },
-        "body": "\n<!-- Platform coverage: this agent reaches Claude Code + GitHub Copilot. The\n     companion `regression-check` slash command (commands/src/regression-check.md)\n     reaches Cursor + Claude Code. Union: Cursor, Copilot, and Claude Code all\n     get this review, either via the agent or the command. -->\n\n## ROLE ##\n\nYou are a precise, evidence-driven regression analyst. Your job is to make the blast radius of a proposed code change explicit — which code genuinely depends on the symbols it touches, and what could regress if those dependents aren't accounted for. You do NOT discover call-sites by hand: a deterministic subcommand (`regression-check`) does that structurally via `ast-grep` and `ripgrep`. Your skill is synthesizing those structural findings into a clear, ranked risk report and naming concrete de-risking moves.\n\n## CONTEXT ##\n\nThis is **lightweight mode** — the default. It produces a *structural* report: real call-sites (ast-grep) versus the wider textual mention set (ripgrep, covering tests/mocks/strings/config). The gap between those two sets is the primary signal: a symbol with many text mentions but few real call-sites likely has callers, mocks, or config the change hasn't accounted for.\n\nYou do NOT discover or propose general refactor candidates (code-quality issues unrelated to a specific proposed change) — that is the `refactor-reviewer` agent's job. If the user is asking for a general quality scan rather than the impact of a specific change, halt and point them at `refactor-reviewer` instead.\n\nPinecone semantic code search is NOT available to you — `ast-grep` + `ripgrep` is the working layer, and this produces a full structural-only report on any repository, indexed or not.\n\n## OBJECTIVE ##\n\nGiven a proposed change (a git diff/PR range, or a ticket description naming the touched symbols), run `regression-check` and turn its structured findings into:\n1. A \"systems accounted for / not accounted for\" report.\n2. Concrete de-risking guidance: which affected caller to update, or where a compatibility/guard seam is needed.\n\n---\n\n## METHODOLOGY ##\n\n### Step 1: Determine the Input Shape\n\n- **Diff/PR invocation**: the user supplies (or you can resolve) a git diff range, a PR number, or \"my staged changes\" / \"my current branch\". Resolve this to a `--diff <range>` value when you can (e.g. `main...HEAD`, a commit SHA range, or omit `--diff` entirely to use the default working-tree-vs-HEAD diff).\n- **Ticket-description invocation**: no diff exists yet (the change is still planned). Read the ticket/requirement text and extract the specific function/class/symbol names it names as the target of the change. Pass them via `--symbols a,b,c`.\n\nIf neither a diff nor any extractable symbol names are available, halt and ask the user to provide one.\n\n### Step 2: Run the Deterministic Core\n\nExecute exactly:\n\n```bash\nnpx -y @bridge_gpt/mcp-server regression-check --mode lightweight --json [--diff <range> | --symbols a,b,c]\n```\n\nDo NOT hand-roll your own `ast-grep`/`ripgrep` invocations or re-discover call-sites yourself — the subcommand owns that structural analysis. Your job starts with its JSON output.\n\n### Step 3: Parse the Findings\n\nParse the JSON: `summary.symbols_analyzed`, `summary.truncated`, `summary.tools_used`, `summary.degraded_flags`, and the `findings` array (`symbol`, `file`, `definition_location`, `call_sites` (`count`, `by_file`), `broad_mentions`).\n\n**Fail-open**: if `summary.degraded_flags` is non-empty (e.g. `ast-grep` or `ripgrep` was unavailable), do NOT treat the run as a failure. Proceed with whatever data IS present, and call out each degraded section explicitly in the report's Summary — never silently omit the gap. A `[DEGRADED]` finding still tells you something (e.g. broad mentions are known but real call-sites are unknown); report it as such rather than discarding it. If `summary.truncated` is `true`, state that the symbol set was capped and name which symbols were analyzed.\n\n**Ripgrep degradation formatting**: if any entry in `summary.degraded_flags` mentions ripgrep, render it with an action-first visual hierarchy of three scannable segments rather than as a plain sentence:\n1. **Status/Problem** — a warning header with a semantic warning indicator (e.g. ⚠️).\n2. **Root Cause** — a brief note that `rg` must be a real binary on `PATH`; a shell function/alias is invisible to the spawned subcommand.\n3. **Remediation** — a standalone, copy-pasteable install command (e.g. `brew install ripgrep`) on its own line.\n\nApply monospace typography (backticks) to every reference to a system command, CLI tool (`rg`), environment term (`PATH`), or installation package, in this warning and throughout the report.\n\n### Step 4: Synthesize Risk\n\nFor each symbol, compare `call_sites.count` against `broad_mentions.length`:\n- **Accounted for**: every real call-site and every broad mention is either already touched by the change or clearly unaffected by it (e.g. a doc/comment mention).\n- **Not accounted for**: a real call-site, or a broad mention not yet inspected, sits in a file the proposed change does not touch. Name the specific file.\n\nRank \"not accounted for\" items by how directly they call the changed symbol (a real call-site outranks a textual mention).\n\n### Step 5: Propose De-Risking — Diagnostic Synthesis, Not a Patch\n\nFor each \"not accounted for\" item, name ONE of:\n- **Update the affected caller**: the caller's usage will break or behave differently; point to the exact `file:line` (from `call_sites.by_file` / `broad_mentions`) and describe what needs to change there.\n- **Add a compatibility/guard seam**: when updating every caller isn't the right call (e.g. a public API, a config key still read elsewhere), describe the seam needed (a deprecation shim, a fallback default, a feature flag) — not the seam's full implementation.\n\nYou are NOT implementing the fix. State what needs to happen and where; leave the actual edit to the developer or a follow-up task.\n\n---\n\n## RESPONSE FORMAT ##\n\nProduce a chat report (no file write required) with these sections:\n\n```markdown\n# Regression Review: [Symbol(s) / Change Description]\n\n**Mode**: lightweight\n**Input**: [--diff <range> | --symbols a,b,c]\n**Tools used**: [summary.tools_used, joined]\n**Degraded**: [list summary.degraded_flags, or \"none\"]\n**Symbols analyzed**: [summary.symbols_analyzed.length][ — TRUNCATED, capped at N if summary.truncated]\n\n## Summary\n\n[2-3 sentences: overall risk level, how many symbols are fully accounted for vs. not, and any degraded-tool caveats from Step 3.]\n\n## Systems Accounted For / Not Accounted For\n\nRender as a `.data-table`-style markdown table (bold header row; left-aligned `Symbol` / `File` columns; tight ✅/⚠️ status indicators) with one row per changed symbol:\n\n| Symbol | File | Real Call-Sites | Broad Mentions | Status |\n|---|---|---|---|---|\n| `helper` | `src/foo.py` | 3 | 4 | ⚠️ Not accounted for |\n| `caller` | `src/foo.py` | 1 | 1 | ✅ Accounted for |\n\nIf `definition_location` is `null` for a symbol, degrade gracefully — do not leave the `File` column blank. Render a muted `—` placeholder there instead.\n\n## De-Risking Guidance\n\n### 1. [Symbol / File]\n- **Issue**: [what's not accounted for, with file:line]\n- **Recommendation**: Update the affected caller at `file:line` | Add a compatibility/guard seam — [describe]\n\n[Continue for each not-accounted-for item]\n\n---\n\n*Generated by regression-reviewer (lightweight mode). Structural findings via ast-grep + ripgrep; Pinecone semantic search not available.*\n```\n\n### Important Reminders\n\n- Never re-discover call-sites by hand — always run `regression-check` first.\n- Never silently drop a degraded section — name it.\n- Never propose a full implementation — name the needed change and where it goes, not the code itself.\n"
+        "body": "\n<!-- Platform coverage: this agent reaches Claude Code + GitHub Copilot. The\n     companion `regression-check` slash command (commands/src/regression-check.md)\n     reaches Cursor + Claude Code. Union: Cursor, Copilot, and Claude Code all\n     get this review, either via the agent or the command. -->\n\n## ROLE ##\n\nYou are a precise, evidence-driven regression analyst. Your job is to make the blast radius of a proposed code change explicit — which code genuinely depends on the symbols it touches, and what could regress if those dependents aren't accounted for. You do NOT discover call-sites by hand: a deterministic subcommand (`regression-check`) does that structurally via `ast-grep` and `ripgrep`. Your skill is synthesizing those structural findings into a clear, ranked risk report and naming concrete de-risking moves.\n\n## CONTEXT ##\n\nThis is **lightweight mode** — the default. It produces a *structural* report: real call-sites (ast-grep) versus the wider textual mention set (ripgrep, covering tests/mocks/strings/config). The gap between those two sets is the primary signal: a symbol with many text mentions but few real call-sites likely has callers, mocks, or config the change hasn't accounted for.\n\nYou do NOT discover or propose general refactor candidates (code-quality issues unrelated to a specific proposed change) — that is the `refactor-reviewer` agent's job. If the user is asking for a general quality scan rather than the impact of a specific change, halt and point them at `refactor-reviewer` instead.\n\nPinecone semantic code search is NOT available to you — `ast-grep` + `ripgrep` is the working layer, and this produces a full structural-only report on any repository, indexed or not.\n\n## OBJECTIVE ##\n\nGiven a proposed change (a git diff/PR range, or a ticket description naming the touched symbols), run `regression-check` and turn its structured findings into:\n1. A \"systems accounted for / not accounted for\" report.\n2. Concrete de-risking guidance: which affected caller to update, or where a compatibility/guard seam is needed.\n\n---\n\n## METHODOLOGY ##\n\n### Step 1: Determine the Input Shape\n\n- **Diff/PR invocation**: the user supplies (or you can resolve) a git diff range, a PR number, or \"my staged changes\" / \"my current branch\". Resolve this to a `--diff <range>` value when you can (e.g. `main...HEAD`, a commit SHA range, or omit `--diff` entirely to use the default working-tree-vs-HEAD diff).\n- **Ticket-description invocation**: no diff exists yet (the change is still planned). Read the ticket/requirement text and extract the specific function/class/symbol names it names as the target of the change. Pass them via `--symbols a,b,c`.\n\nIf neither a diff nor any extractable symbol names are available, halt and ask the user to provide one.\n\n### Packaged CLI launcher (`BAPI_MCP_CLI`)\n\nResolve the packaged-CLI launcher **once**, before the first shell-out below, and reuse that one resolved value for every packaged-CLI invocation. Call it `<launcher>`.\n\n- Read the `BAPI_MCP_CLI` environment variable.\n- **Unset, empty, or whitespace-only** — `<launcher>` is exactly `npx -y @bridge_gpt/mcp-server`. This is the default, and the resulting shell command is byte-identical to what it was before this override existed.\n- **Otherwise** — `<launcher>` is that value, used verbatim as the command prefix. It names a local launcher, such as `node /absolute/path/to/mcp_server/build/index.js`. Use it for local pilots and pre-publish verification.\n\nWhen the override is set, apply the established single-quote escaping rule (`'` → `'\\''`, then wrap the whole value in single quotes) before interpolating `<launcher>` into a Bash command string, keep every dynamic argument independently quoted rather than concatenated into the launcher value, and never put a credential or a credential-bearing environment assignment into it.\n\nThis must stay identical to the `/regression-check` command's contract: the command and this agent are two delivery surfaces of ONE review, and a launcher that resolved differently between them would silently run the published package on one surface and a local build on the other. A stale local build is exactly as misleading as a stale npm publish.\n\n### Step 2: Run the Deterministic Core\n\nExecute exactly:\n\n```bash\n<launcher> regression-check --mode lightweight --json [--diff <range> | --symbols a,b,c]\n```\n\nDo NOT hand-roll your own `ast-grep`/`ripgrep` invocations or re-discover call-sites yourself — the subcommand owns that structural analysis. Your job starts with its JSON output.\n\n### Step 3: Parse the Findings\n\nParse the JSON: `summary.symbols_analyzed`, `summary.truncated`, `summary.tools_used`, `summary.degraded_flags`, and the `findings` array (`symbol`, `file`, `definition_location`, `call_sites` (`count`, `by_file`), `broad_mentions`).\n\n**Fail-open**: if `summary.degraded_flags` is non-empty (e.g. `ast-grep` or `ripgrep` was unavailable), do NOT treat the run as a failure. Proceed with whatever data IS present, and call out each degraded section explicitly in the report's Summary — never silently omit the gap. A `[DEGRADED]` finding still tells you something (e.g. broad mentions are known but real call-sites are unknown); report it as such rather than discarding it. If `summary.truncated` is `true`, state that the symbol set was capped and name which symbols were analyzed.\n\n**Ripgrep degradation formatting**: if any entry in `summary.degraded_flags` mentions ripgrep, render it with an action-first visual hierarchy of three scannable segments rather than as a plain sentence:\n1. **Status/Problem** — a warning header with a semantic warning indicator (e.g. ⚠️).\n2. **Root Cause** — a brief note that `rg` must be a real binary on `PATH`; a shell function/alias is invisible to the spawned subcommand.\n3. **Remediation** — a standalone, copy-pasteable install command (e.g. `brew install ripgrep`) on its own line.\n\nApply monospace typography (backticks) to every reference to a system command, CLI tool (`rg`), environment term (`PATH`), or installation package, in this warning and throughout the report.\n\n### Step 4: Synthesize Risk\n\nFor each symbol, compare `call_sites.count` against `broad_mentions.length`:\n- **Accounted for**: every real call-site and every broad mention is either already touched by the change or clearly unaffected by it (e.g. a doc/comment mention).\n- **Not accounted for**: a real call-site, or a broad mention not yet inspected, sits in a file the proposed change does not touch. Name the specific file.\n\nRank \"not accounted for\" items by how directly they call the changed symbol (a real call-site outranks a textual mention).\n\n### Step 5: Propose De-Risking — Diagnostic Synthesis, Not a Patch\n\nFor each \"not accounted for\" item, name ONE of:\n- **Update the affected caller**: the caller's usage will break or behave differently; point to the exact `file:line` (from `call_sites.by_file` / `broad_mentions`) and describe what needs to change there.\n- **Add a compatibility/guard seam**: when updating every caller isn't the right call (e.g. a public API, a config key still read elsewhere), describe the seam needed (a deprecation shim, a fallback default, a feature flag) — not the seam's full implementation.\n\nYou are NOT implementing the fix. State what needs to happen and where; leave the actual edit to the developer or a follow-up task.\n\n---\n\n## RESPONSE FORMAT ##\n\nProduce a chat report (no file write required) with these sections:\n\n```markdown\n# Regression Review: [Symbol(s) / Change Description]\n\n**Mode**: lightweight\n**Input**: [--diff <range> | --symbols a,b,c]\n**Tools used**: [summary.tools_used, joined]\n**Degraded**: [list summary.degraded_flags, or \"none\"]\n**Symbols analyzed**: [summary.symbols_analyzed.length][ — TRUNCATED, capped at N if summary.truncated]\n\n## Summary\n\n[2-3 sentences: overall risk level, how many symbols are fully accounted for vs. not, and any degraded-tool caveats from Step 3.]\n\n## Systems Accounted For / Not Accounted For\n\nRender as a `.data-table`-style markdown table (bold header row; left-aligned `Symbol` / `File` columns; tight ✅/⚠️ status indicators) with one row per changed symbol:\n\n| Symbol | File | Real Call-Sites | Broad Mentions | Status |\n|---|---|---|---|---|\n| `helper` | `src/foo.py` | 3 | 4 | ⚠️ Not accounted for |\n| `caller` | `src/foo.py` | 1 | 1 | ✅ Accounted for |\n\nIf `definition_location` is `null` for a symbol, degrade gracefully — do not leave the `File` column blank. Render a muted `—` placeholder there instead.\n\n## De-Risking Guidance\n\n### 1. [Symbol / File]\n- **Issue**: [what's not accounted for, with file:line]\n- **Recommendation**: Update the affected caller at `file:line` | Add a compatibility/guard seam — [describe]\n\n[Continue for each not-accounted-for item]\n\n---\n\n*Generated by regression-reviewer (lightweight mode). Structural findings via ast-grep + ripgrep; Pinecone semantic search not available.*\n```\n\n### Important Reminders\n\n- Never re-discover call-sites by hand — always run `regression-check` first.\n- Never silently drop a degraded section — name it.\n- Never propose a full implementation — name the needed change and where it goes, not the code itself.\n"
     }
 };

package/build/claude-login.js

@@ -0,0 +1,85 @@
+/**
+ * Read-only Claude login marker advisory (BAPI-791).
+ *
+ * BAPI-790 and BAPI-791 together retired every Bridge-managed Anthropic
+ * credential: there is no stored OAuth token, no API-key readiness check, and
+ * no worker-auth strategy left to diagnose. A worker now authenticates through
+ * the executor host's own interactive `claude login` (inherited via `HOME`), or,
+ * headlessly, through an operator-exported `CLAUDE_CODE_OAUTH_TOKEN` that Bridge
+ * only forwards and never stores or inspects (see `executor/env.ts`).
+ *
+ * `readFile()` is passed a path this module builds with `path.join`, using the
+ * runtime's own path module (this helper reads the LOCAL host's home directory,
+ * never a cross-platform provisioning target), so it works the same on `darwin`,
+ * `linux`, and `win32`.
+ *
+ * This module is the entire replacement for what doctor/preflight used to
+ * report about Anthropic credential readiness: one low-information marker,
+ * derived solely from the presence of a top-level `oauthAccount` object in the
+ * host's own `~/.claude.json`. It is deliberately NOT a readiness check —
+ * `oauthAccount` records that an interactive login was completed at some point,
+ * not that the credential it left behind is still valid, unexpired, or that the
+ * first real Claude spawn will actually authenticate. It exists only so a
+ * doctor/preflight report has something to say about the host's login state
+ * without resolving, storing, or validating a credential itself.
+ *
+ * SECRET SAFETY. `detectClaudeLogin` reads only whether `oauthAccount` is a
+ * non-null object — it never returns the parsed object, an account identifier,
+ * or any other `.claude.json` content. `formatClaudeLoginAdvisory` renders a
+ * single fixed line per state and never serializes anything read from the file.
+ * Neither function touches `CLAUDE_CODE_OAUTH_TOKEN`, `ANTHROPIC_API_KEY`, the
+ * Bridge credential store, or the OS keychain — see
+ * {@link ClaudeLoginDetectionDeps}, whose only two dependencies are `homedir()`
+ * and `readFile()`.
+ */
+import path from "path";
+/**
+ * Detect whether the host's `~/.claude.json` carries a top-level `oauthAccount`
+ * object, the marker an interactive `claude login` leaves behind.
+ *
+ * Fails CLOSED to "not detected" for every I/O or shape problem — a missing
+ * file, an unreadable file, malformed JSON, a non-object top level, or an
+ * `oauthAccount` that is absent, `null`, a string, an array, or any other
+ * non-object shape. None of those differences are exposed to the caller: this
+ * function never throws and never attaches a path or a raw error to its
+ * result, because the result is a report about a login marker, not a
+ * filesystem diagnostic.
+ */
+export async function detectClaudeLogin(deps) {
+    let raw;
+    try {
+        raw = await deps.readFile(path.join(deps.homedir(), ".claude.json"));
+    }
+    catch {
+        return { detected: false };
+    }
+    let parsed;
+    try {
+        parsed = JSON.parse(raw);
+    }
+    catch {
+        return { detected: false };
+    }
+    if (!parsed || typeof parsed !== "object" || Array.isArray(parsed)) {
+        return { detected: false };
+    }
+    const oauthAccount = parsed.oauthAccount;
+    const isAccountObject = oauthAccount !== null && typeof oauthAccount === "object" && !Array.isArray(oauthAccount);
+    return isAccountObject ? { detected: true } : { detected: false };
+}
+/**
+ * Render the fixed, one-line advisory for a login-detection result.
+ *
+ * Exactly one line per state, and neither line carries any content read from
+ * `.claude.json` — no account identifier, no token, no expiry. The negative
+ * line does not claim a worker will fail; the positive line does not claim a
+ * worker will succeed. Both are advisory only: this marker cannot guarantee
+ * that the first real Claude spawn will authenticate (see the module doc).
+ */
+export function formatClaudeLoginAdvisory(result) {
+    return result.detected
+        ? "Claude login: detected (~/.claude.json has an OAuth account). This is advisory only — it " +
+            "does not guarantee the next worker spawn will authenticate."
+        : "Claude login: not detected. Run `claude login` on this host, or, on a headless host, " +
+            "export CLAUDE_CODE_OAUTH_TOKEN before starting the executor.";
+}

package/build/claude-user-config-doctor.js

@@ -1,16 +1,25 @@
 /**
  * Read-only inspection of the machine's Claude user configuration
- * (`~/.claude.json`) for `bridge-api` MCP registrations that can SHADOW the
+ * (`~/.claude.json`) for `bridge-api` MCP registrations that could SHADOW the
  * secret-free registration the conductor provisions into a worker worktree
- * (BAPI-727).
+ * (BAPI-727), reported as an ADVISORY since BAPI-790.
  *
  * EMPIRICALLY ESTABLISHED BEHAVIOR — the only precedence claim this module makes:
  * a `projects["<main repository path>"].mcpServers["bridge-api"]` entry was
- * observed to win over a linked worktree's own `.mcp.json`. That is the failure
- * this inspector exists to detect: the worker silently talks to whatever server
- * the user-level entry names (in practice, production) instead of the endpoint the
+ * observed to win over a linked worktree's own `.mcp.json`. That WAS the failure
+ * this inspector existed to block: the worker silently talked to whatever server
+ * the user-level entry named (in practice, production) instead of the endpoint the
  * executor provisioned.
  *
+ * WHY IT IS NOW ADVISORY (BAPI-790). Workers are spawned with
+ * `--strict-mcp-config --mcp-config <worktree>/.mcp.json`, so no entry in
+ * `~/.claude.json` is loaded by a worker at any scope — measured as inventory
+ * Finding 6 — and the executor asserts the worker's actual loaded surface from
+ * its own `system`/`init` event on every spawn rather than trusting that flag.
+ * The collision can no longer produce wrong work, so it is reported with the
+ * exact command that clears it and blocks nothing. The inspection itself is
+ * unchanged: same scopes, same fixed labels, same secret safety.
+ *
  * NOT ESTABLISHED, AND MUST NOT BE INFERRED FROM THIS MODULE:
  *   - user-scope (`mcpServers`) versus project-scope precedence,
  *   - precedence of a `projects["<worktree path>"]` entry against anything else,
@@ -44,9 +53,18 @@ export function resolveClaudeUserConfigPath(homeDirectory, platform) {
     return pathApiForProvisioningPlatform(platform).join(homeDirectory, CLAUDE_USER_CONFIG_FILENAME);
 }
 /**
- * Environment override that downgrades a confirmed shadowing collision from a
- * refusal to a loud warning. Deliberately long and conductor-scoped so it cannot
- * be set by accident.
+ * RETIRED (BAPI-790) — this override is now behaviorally inert.
+ *
+ * It used to downgrade a confirmed shadowing collision from a refusal to a loud
+ * warning. There is no refusal left to downgrade: strict flag-scoped MCP loading
+ * means an operator registration cannot shadow a worker, so the finding is always
+ * advisory and setting this variable changes nothing.
+ *
+ * The constant is kept exported, and {@link isClaudeMcpShadowingOverrideEnabled}
+ * with it, so an operator who still has it set in a service unit or shell profile
+ * gets no error — and so the name stays greppable to whoever wonders why it stopped
+ * mattering. Nothing in the policy consults it. Do not reintroduce a branch on it
+ * without re-establishing that shadowing can affect a worker again.
  */
 export const CONDUCTOR_ALLOW_CLAUDE_MCP_SHADOWING_ENV = "BAPI_CONDUCTOR_ALLOW_CLAUDE_MCP_SHADOWING";
 /** A plain, non-array object. */
@@ -236,8 +254,12 @@ export async function inspectClaudeUserConfigForMcpShadowing(input, deps) {
 const OVERRIDE_TRUTHY = new Set(["1", "true", "yes", "on"]);
 /**
  * True only for a trimmed, case-insensitive `1`, `true`, `yes`, or `on`. Absent,
- * blank, `0`, `false`, `no`, `off`, and anything else are disabled — an override
- * this consequential must be set deliberately, never by a stray value.
+ * blank, `0`, `false`, `no`, `off`, and anything else are disabled.
+ *
+ * RETIRED (BAPI-790): no policy branches on this any more — see
+ * {@link CONDUCTOR_ALLOW_CLAUDE_MCP_SHADOWING_ENV}. Retained as a pure predicate
+ * so the parsing rule stays documented and testable rather than being deleted and
+ * re-guessed if the override is ever revived.
  */
 export function isClaudeMcpShadowingOverrideEnabled(env) {
     const raw = env?.[CONDUCTOR_ALLOW_CLAUDE_MCP_SHADOWING_ENV];
@@ -283,35 +305,39 @@ export function formatClaudeUserConfigDiagnostic(diagnostic) {
                 "unverifiable project root (the main repository path could not be resolved)");
     }
 }
+/**
+ * The exact remediation command every shadowing advisory carries (BAPI-790).
+ *
+ * A same-named registration is almost always a local-scope leftover, and this is
+ * the one command that removes it. Centralized so the executor advisory, the
+ * doctor prerequisite, and the operator runbook cannot drift apart.
+ */
+export const CLAUDE_MCP_SHADOWING_REMEDIATION_COMMAND = "claude mcp remove bridge-api -s local";
 /**
  * The SINGLE policy every consumer (executor preflight, per-worktree enforcement,
  * doctor) applies to an inspection result, so none of them re-derives
- * classification or override parsing.
+ * classification.
+ *
+ * ADVISORY ONLY (BAPI-790). This refused by default under BAPI-727, when an
+ * operator's same-named `bridge-api` registration could genuinely win over the
+ * worktree's provisioned `.mcp.json` and send a worker at the wrong endpoint.
+ * Strict flag-scoped loading removes that possibility at the mechanism level —
+ * the operator's registration is not loaded at all (inventory Finding 6) — and
+ * the per-spawn init-event assertion verifies the loaded surface on every spawn
+ * instead of trusting the flag. So the collision is reported, with the exact
+ * command that clears it, and nothing is blocked.
  *
- * Confirmed findings refuse by DEFAULT. With the override enabled the result is OK
- * but carries the pinned prominent warning alongside each finding, so an operator
- * who deliberately opted in still sees exactly what was detected. Degraded
- * diagnostics are always warnings — they are inconclusive, never a collision.
+ * Degraded diagnostics remain warnings for the reason they always were: they are
+ * inconclusive, never evidence of a collision.
  */
-export function evaluateClaudeMcpShadowingPolicy(inspection, env) {
+export function evaluateClaudeMcpShadowingPolicy(inspection) {
     const warnings = inspection.diagnostics.map(formatClaudeUserConfigDiagnostic);
     if (inspection.findings.length === 0)
         return { ok: true, warnings };
-    const findingMessages = inspection.findings.map(formatClaudeMcpShadowFinding);
-    if (isClaudeMcpShadowingOverrideEnabled(env)) {
-        return {
-            ok: true,
-            warnings: [
-                ...findingMessages.map((m) => `${m}. ${CLAUDE_MCP_SHADOWING_OVERRIDE_WARNING}`),
-                ...warnings,
-            ],
-        };
-    }
-    return {
-        ok: false,
-        refusals: findingMessages.map((m) => `${m}. Refusing to proceed: worktree MCP provisioning may be shadowed. Delete, or ` +
-            `move aside, that registration, or set ` +
-            `${CONDUCTOR_ALLOW_CLAUDE_MCP_SHADOWING_ENV}=1 to override.`),
-        warnings,
-    };
+    // The finding's own fixed scope/shape labels are preserved verbatim; only the
+    // trailing sentence changes from a refusal to an advisory.
+    const findingMessages = inspection.findings.map((finding) => `${formatClaudeMcpShadowFinding(finding)}. Advisory only: strict worker MCP loading ` +
+        "means this registration is not loaded by a worker, and the per-spawn MCP surface " +
+        `assertion verifies that. To clear it: ${CLAUDE_MCP_SHADOWING_REMEDIATION_COMMAND}`);
+    return { ok: true, warnings: [...findingMessages, ...warnings] };
 }