@integrity-labs/agt-cli 0.28.507 → 0.28.509

package/dist/mcp/direct-chat-channel.js

@@ -32955,29 +32955,44 @@ var INTEGRATION_REGISTRY = [
     id: "vercel",
     name: "Vercel",
     category: "infrastructure",
-    description: "Check on Vercel app deployments \u2014 status, build/runtime logs \u2014 and search Vercel documentation. Remote streamable-HTTP MCP at https://mcp.vercel.com.",
-    // Same OAuth pattern as Granola/Higgsfield: Claude Code brokers the
-    // browser sign-in at runtime; nothing for the manager API to provision.
-    supported_auth_types: ["none"],
+    description: "Check on Vercel app deployments \u2014 what's live, deployment status, and build logs \u2014 through Vercel's REST API with your own API token.",
+    // ENG-8421: api_key, NOT the host-brokered MCP this used to be.
+    //
+    // Vercel MCP (`https://mcp.vercel.com`) is not completable from the
+    // console, and that is a vendor constraint rather than a gap in our
+    // plumbing. Established empirically 2026-08-03: Dynamic Client
+    // Registration REJECTS an https redirect (`invalid_redirect_uri` — "not
+    // approved for use by this authorization server") and ACCEPTS only
+    // localhost; the device-code grant, the one flow needing no redirect, is
+    // refused to DCR clients (`unauthorized_client`). So the only client
+    // Vercel permits is a local one redirecting to its own ephemeral port —
+    // i.e. Claude Code on the agent's host, driven by an operator running
+    // `/mcp` in tmux. No console work can remove that step.
+    //
+    // The REST API has none of those constraints: plain bearer auth
+    // (unauthenticated → `{"code":"forbidden","missingToken":true}`, bogus
+    // bearer → `{"invalidToken":true}`), so a token the customer creates in
+    // their own Vercel dashboard works directly. That makes this an ordinary
+    // paste-a-key integration, and it means WE hold the credential — so it can
+    // be stored, rotated, revoked and audited, none of which was true when the
+    // grant lived in Claude Code's `~/.claude.json` on the host.
+    //
+    // Tools are declared as data on `integration_definitions.metadata.tools`
+    // and dispatch through the existing Direct HTTP broker (the v0 pattern) —
+    // there is deliberately no bespoke Vercel client and no bespoke broker.
+    supported_auth_types: ["api_key"],
     capabilities: [
-      { id: "vercel:read-deployments", name: "Read Deployments", description: "List teams/projects, check deployment status, and read build/runtime logs.", access: "read" },
-      { id: "vercel:search-docs", name: "Search Documentation", description: "Search Vercel platform documentation.", access: "read" }
+      { id: "vercel:read-deployments", name: "Read Deployments", description: "List teams/projects, check deployment status, and read build logs.", access: "read" }
     ],
-    docs_url: "https://vercel.com/docs/agent-resources/vercel-mcp",
-    // Beta until the headless OAuth flow (and Vercel's OAuth-client allowlist,
-    // which is vendor-side and outside our control) is verified end-to-end.
-    beta: true,
-    // No `auth`/`headers` — host-brokered OAuth (Claude Code authenticates
-    // directly with Vercel; nothing for us to inject). Declaring this here
-    // (rather than a hardcoded buildMcpJson/writeIntegrations branch, the
-    // pre-ENG-8035 Higgsfield-era pattern) lets the generic remote-MCP loop
-    // render the `.mcp.json` entry AND enrolls 'vercel' in the
-    // `registryRemoteMcpKeys` prune universe automatically, so an uninstall
-    // actually removes the entry instead of leaving it stale.
-    remoteMcp: {
-      type: "http",
-      url: "https://mcp.vercel.com"
-    }
+    docs_url: "https://vercel.com/docs/rest-api",
+    // Beta until the REST tool surface has been exercised against a real
+    // customer token. (The previous reason — "until the headless OAuth flow is
+    // verified end-to-end" — is void: there is no OAuth flow any more.)
+    beta: true
+    // NO `remoteMcp`. See the tombstone in the claudecode adapter's prune
+    // universe: dropping this field also drops `vercel` from
+    // `registryRemoteMcpKeys`, which would strand the `.mcp.json` entry on
+    // every host that installed the MCP variant.
   },
   {
     id: "qmd",
@@ -35502,6 +35517,54 @@ var FLAG_REGISTRY = [
     // Turning this on lets agents originate proposals that create customer
     // infrastructure once approved — same posture as augmented-support-writes.
     sensitive: true
+  },
+  {
+    key: "github-broker-credentials",
+    description: "Deliver GitHub App installation tokens to `git` and the `gh` CLI through the broker credential endpoint at USE time, instead of materializing them into the agent process environment at spawn (ENG-8344). A GitHub App installation token has a ~1h TTL, so the spawn-frozen GITHUB_ACCESS_TOKEN / GITHUB_TOKEN pair rotates hourly; the wrapper sources `.env.integrations` exactly once, so the only way a running agent sees the new value is a full session respawn (measured: 6 agents, ~144 kills/day). ENG-8343 stopped those kills landing mid-turn; this removes them. ON: `POST /host/agent-integrations` stops minting the installation token into the payload for auth_type=github_app rows (so computeIntegrationsHash stops seeing a rotating value) and marks the row credential_delivery=broker; the claudecode adapter then writes a git credential helper + a `gh` shim that fetch a fresh token per use from POST /host/agent-integrations/github/credential (ENG-8264 name addressing). OFF (default): byte-for-byte today's behaviour - the token is minted into the payload and materialized as GITHUB_ACCESS_TOKEN / GITHUB_TOKEN, no helper, no shim. NOTE the scope of the security claim: this removes the token from the agent's ENVIRONMENT, which is what stops the respawns. It does NOT make the token unreachable by a determined agent - the agent can invoke the helper itself. Strictly better than today, not a sandbox. Evaluated API-side only, per agent, in POST /host/agent-integrations; no host-side envVar. The host does not read this flag - it keys off the resulting credential_delivery marker on the row - so there is deliberately no host override that could put the token back on its own. Roll back from the flag.",
+    flagType: "boolean",
+    // Declared safe value is `false` = today's env delivery. Fail-safe direction:
+    // a flag-DB read error must never strip `git`/`gh` credentials off a live
+    // agent, which is what the ON path does when its host has no helper writer.
+    defaultValue: false,
+    // Flipping ON changes how every GitHub App agent on the scope authenticates
+    // `git push` / `gh`. A bad flip takes those away, so it is a deliberate,
+    // confirmed action (ADR-0022 §4).
+    sensitive: true,
+    // Set even though the flag is evaluated centrally, because `since` is a
+    // REACH threshold ("a host this old has no consumer code for the flag") and
+    // that is exactly the hazard here: the host does not read the flag, but it
+    // does need the claudecode adapter's helper/shim writer and the wrapper PATH
+    // prepend. On a host too old for those, the API would stop shipping the
+    // token and NOTHING would replace it. Without `since` the flip-reach modal
+    // reports FULL reach and hides that.
+    //
+    // DELIBERATE UNREACHABLE PLACEHOLDER - NOT A REAL THRESHOLD YET.
+    // The sibling entries in this registry (`slack-hot-thread-guard` 0.28.339,
+    // `slack-scheduled-channel-guard` 0.28.421) are BISECTED from published npm
+    // artifacts, which is only possible AFTER this merges and publishes. A
+    // pre-merge guess cannot be right, and the two directions are not
+    // symmetric:
+    //   - too HIGH  -> hosts classify `stale`, the modal over-warns. Annoying.
+    //   - too LOW   -> hosts classify `honors` while carrying NO helper writer,
+    //                  the modal promises full reach, and a flip strips `git`/
+    //                  `gh` credentials with nothing replacing them. Outage.
+    // So this is pinned ABOVE every published release on purpose: it classifies
+    // EVERY host as `stale`, so the modal reports no reach rather than reach it
+    // has no basis for. That is the intended pre-bisect state.
+    //
+    // BUT `since` IS ADVISORY, NOT A GUARD. It is read in exactly one place -
+    // `computeFlagReach` behind GET /admin/reach, which renders the flip-reach
+    // modal. `evaluate.ts` never reads it and neither does the override write
+    // path. The placeholder therefore changes what an operator is TOLD; it does
+    // not stop a flip on an under-`since` host. What actually holds the line
+    // here is `defaultValue: false` plus `sensitive: true` plus the runbook.
+    //
+    // BEFORE THIS FLAG IS FLIPPED ANYWHERE: bisect the published dist for the
+    // first agt-cli whose claudecode adapter writes agt-bin/ and whose wrapper
+    // prepends it, then replace this with that exact version. The rollout
+    // runbook gates on it. Leaving the placeholder in place is safe (nothing
+    // flips); shipping a guessed number is not.
+    since: "0.29.0"
   }
 ];
 var REGISTRY_BY_KEY = new Map(FLAG_REGISTRY.map((definition) => [definition.key, definition]));

package/dist/mcp/origami.js

@@ -39282,29 +39282,44 @@ var INTEGRATION_REGISTRY = [
     id: "vercel",
     name: "Vercel",
     category: "infrastructure",
-    description: "Check on Vercel app deployments \u2014 status, build/runtime logs \u2014 and search Vercel documentation. Remote streamable-HTTP MCP at https://mcp.vercel.com.",
-    // Same OAuth pattern as Granola/Higgsfield: Claude Code brokers the
-    // browser sign-in at runtime; nothing for the manager API to provision.
-    supported_auth_types: ["none"],
+    description: "Check on Vercel app deployments \u2014 what's live, deployment status, and build logs \u2014 through Vercel's REST API with your own API token.",
+    // ENG-8421: api_key, NOT the host-brokered MCP this used to be.
+    //
+    // Vercel MCP (`https://mcp.vercel.com`) is not completable from the
+    // console, and that is a vendor constraint rather than a gap in our
+    // plumbing. Established empirically 2026-08-03: Dynamic Client
+    // Registration REJECTS an https redirect (`invalid_redirect_uri` — "not
+    // approved for use by this authorization server") and ACCEPTS only
+    // localhost; the device-code grant, the one flow needing no redirect, is
+    // refused to DCR clients (`unauthorized_client`). So the only client
+    // Vercel permits is a local one redirecting to its own ephemeral port —
+    // i.e. Claude Code on the agent's host, driven by an operator running
+    // `/mcp` in tmux. No console work can remove that step.
+    //
+    // The REST API has none of those constraints: plain bearer auth
+    // (unauthenticated → `{"code":"forbidden","missingToken":true}`, bogus
+    // bearer → `{"invalidToken":true}`), so a token the customer creates in
+    // their own Vercel dashboard works directly. That makes this an ordinary
+    // paste-a-key integration, and it means WE hold the credential — so it can
+    // be stored, rotated, revoked and audited, none of which was true when the
+    // grant lived in Claude Code's `~/.claude.json` on the host.
+    //
+    // Tools are declared as data on `integration_definitions.metadata.tools`
+    // and dispatch through the existing Direct HTTP broker (the v0 pattern) —
+    // there is deliberately no bespoke Vercel client and no bespoke broker.
+    supported_auth_types: ["api_key"],
     capabilities: [
-      { id: "vercel:read-deployments", name: "Read Deployments", description: "List teams/projects, check deployment status, and read build/runtime logs.", access: "read" },
-      { id: "vercel:search-docs", name: "Search Documentation", description: "Search Vercel platform documentation.", access: "read" }
+      { id: "vercel:read-deployments", name: "Read Deployments", description: "List teams/projects, check deployment status, and read build logs.", access: "read" }
     ],
-    docs_url: "https://vercel.com/docs/agent-resources/vercel-mcp",
-    // Beta until the headless OAuth flow (and Vercel's OAuth-client allowlist,
-    // which is vendor-side and outside our control) is verified end-to-end.
-    beta: true,
-    // No `auth`/`headers` — host-brokered OAuth (Claude Code authenticates
-    // directly with Vercel; nothing for us to inject). Declaring this here
-    // (rather than a hardcoded buildMcpJson/writeIntegrations branch, the
-    // pre-ENG-8035 Higgsfield-era pattern) lets the generic remote-MCP loop
-    // render the `.mcp.json` entry AND enrolls 'vercel' in the
-    // `registryRemoteMcpKeys` prune universe automatically, so an uninstall
-    // actually removes the entry instead of leaving it stale.
-    remoteMcp: {
-      type: "http",
-      url: "https://mcp.vercel.com"
-    }
+    docs_url: "https://vercel.com/docs/rest-api",
+    // Beta until the REST tool surface has been exercised against a real
+    // customer token. (The previous reason — "until the headless OAuth flow is
+    // verified end-to-end" — is void: there is no OAuth flow any more.)
+    beta: true
+    // NO `remoteMcp`. See the tombstone in the claudecode adapter's prune
+    // universe: dropping this field also drops `vercel` from
+    // `registryRemoteMcpKeys`, which would strand the `.mcp.json` entry on
+    // every host that installed the MCP variant.
   },
   {
     id: "qmd",
@@ -41393,6 +41408,54 @@ var FLAG_REGISTRY = [
     // Turning this on lets agents originate proposals that create customer
     // infrastructure once approved — same posture as augmented-support-writes.
     sensitive: true
+  },
+  {
+    key: "github-broker-credentials",
+    description: "Deliver GitHub App installation tokens to `git` and the `gh` CLI through the broker credential endpoint at USE time, instead of materializing them into the agent process environment at spawn (ENG-8344). A GitHub App installation token has a ~1h TTL, so the spawn-frozen GITHUB_ACCESS_TOKEN / GITHUB_TOKEN pair rotates hourly; the wrapper sources `.env.integrations` exactly once, so the only way a running agent sees the new value is a full session respawn (measured: 6 agents, ~144 kills/day). ENG-8343 stopped those kills landing mid-turn; this removes them. ON: `POST /host/agent-integrations` stops minting the installation token into the payload for auth_type=github_app rows (so computeIntegrationsHash stops seeing a rotating value) and marks the row credential_delivery=broker; the claudecode adapter then writes a git credential helper + a `gh` shim that fetch a fresh token per use from POST /host/agent-integrations/github/credential (ENG-8264 name addressing). OFF (default): byte-for-byte today's behaviour - the token is minted into the payload and materialized as GITHUB_ACCESS_TOKEN / GITHUB_TOKEN, no helper, no shim. NOTE the scope of the security claim: this removes the token from the agent's ENVIRONMENT, which is what stops the respawns. It does NOT make the token unreachable by a determined agent - the agent can invoke the helper itself. Strictly better than today, not a sandbox. Evaluated API-side only, per agent, in POST /host/agent-integrations; no host-side envVar. The host does not read this flag - it keys off the resulting credential_delivery marker on the row - so there is deliberately no host override that could put the token back on its own. Roll back from the flag.",
+    flagType: "boolean",
+    // Declared safe value is `false` = today's env delivery. Fail-safe direction:
+    // a flag-DB read error must never strip `git`/`gh` credentials off a live
+    // agent, which is what the ON path does when its host has no helper writer.
+    defaultValue: false,
+    // Flipping ON changes how every GitHub App agent on the scope authenticates
+    // `git push` / `gh`. A bad flip takes those away, so it is a deliberate,
+    // confirmed action (ADR-0022 §4).
+    sensitive: true,
+    // Set even though the flag is evaluated centrally, because `since` is a
+    // REACH threshold ("a host this old has no consumer code for the flag") and
+    // that is exactly the hazard here: the host does not read the flag, but it
+    // does need the claudecode adapter's helper/shim writer and the wrapper PATH
+    // prepend. On a host too old for those, the API would stop shipping the
+    // token and NOTHING would replace it. Without `since` the flip-reach modal
+    // reports FULL reach and hides that.
+    //
+    // DELIBERATE UNREACHABLE PLACEHOLDER - NOT A REAL THRESHOLD YET.
+    // The sibling entries in this registry (`slack-hot-thread-guard` 0.28.339,
+    // `slack-scheduled-channel-guard` 0.28.421) are BISECTED from published npm
+    // artifacts, which is only possible AFTER this merges and publishes. A
+    // pre-merge guess cannot be right, and the two directions are not
+    // symmetric:
+    //   - too HIGH  -> hosts classify `stale`, the modal over-warns. Annoying.
+    //   - too LOW   -> hosts classify `honors` while carrying NO helper writer,
+    //                  the modal promises full reach, and a flip strips `git`/
+    //                  `gh` credentials with nothing replacing them. Outage.
+    // So this is pinned ABOVE every published release on purpose: it classifies
+    // EVERY host as `stale`, so the modal reports no reach rather than reach it
+    // has no basis for. That is the intended pre-bisect state.
+    //
+    // BUT `since` IS ADVISORY, NOT A GUARD. It is read in exactly one place -
+    // `computeFlagReach` behind GET /admin/reach, which renders the flip-reach
+    // modal. `evaluate.ts` never reads it and neither does the override write
+    // path. The placeholder therefore changes what an operator is TOLD; it does
+    // not stop a flip on an under-`since` host. What actually holds the line
+    // here is `defaultValue: false` plus `sensitive: true` plus the runbook.
+    //
+    // BEFORE THIS FLAG IS FLIPPED ANYWHERE: bisect the published dist for the
+    // first agt-cli whose claudecode adapter writes agt-bin/ and whose wrapper
+    // prepends it, then replace this with that exact version. The rollout
+    // runbook gates on it. Leaving the placeholder in place is safe (nothing
+    // flips); shipping a guessed number is not.
+    since: "0.29.0"
   }
 ];
 var REGISTRY_BY_KEY = new Map(FLAG_REGISTRY.map((definition) => [definition.key, definition]));

package/dist/mcp/slack-channel.js

@@ -33177,29 +33177,44 @@ var INTEGRATION_REGISTRY = [
     id: "vercel",
     name: "Vercel",
     category: "infrastructure",
-    description: "Check on Vercel app deployments \u2014 status, build/runtime logs \u2014 and search Vercel documentation. Remote streamable-HTTP MCP at https://mcp.vercel.com.",
-    // Same OAuth pattern as Granola/Higgsfield: Claude Code brokers the
-    // browser sign-in at runtime; nothing for the manager API to provision.
-    supported_auth_types: ["none"],
+    description: "Check on Vercel app deployments \u2014 what's live, deployment status, and build logs \u2014 through Vercel's REST API with your own API token.",
+    // ENG-8421: api_key, NOT the host-brokered MCP this used to be.
+    //
+    // Vercel MCP (`https://mcp.vercel.com`) is not completable from the
+    // console, and that is a vendor constraint rather than a gap in our
+    // plumbing. Established empirically 2026-08-03: Dynamic Client
+    // Registration REJECTS an https redirect (`invalid_redirect_uri` — "not
+    // approved for use by this authorization server") and ACCEPTS only
+    // localhost; the device-code grant, the one flow needing no redirect, is
+    // refused to DCR clients (`unauthorized_client`). So the only client
+    // Vercel permits is a local one redirecting to its own ephemeral port —
+    // i.e. Claude Code on the agent's host, driven by an operator running
+    // `/mcp` in tmux. No console work can remove that step.
+    //
+    // The REST API has none of those constraints: plain bearer auth
+    // (unauthenticated → `{"code":"forbidden","missingToken":true}`, bogus
+    // bearer → `{"invalidToken":true}`), so a token the customer creates in
+    // their own Vercel dashboard works directly. That makes this an ordinary
+    // paste-a-key integration, and it means WE hold the credential — so it can
+    // be stored, rotated, revoked and audited, none of which was true when the
+    // grant lived in Claude Code's `~/.claude.json` on the host.
+    //
+    // Tools are declared as data on `integration_definitions.metadata.tools`
+    // and dispatch through the existing Direct HTTP broker (the v0 pattern) —
+    // there is deliberately no bespoke Vercel client and no bespoke broker.
+    supported_auth_types: ["api_key"],
     capabilities: [
-      { id: "vercel:read-deployments", name: "Read Deployments", description: "List teams/projects, check deployment status, and read build/runtime logs.", access: "read" },
-      { id: "vercel:search-docs", name: "Search Documentation", description: "Search Vercel platform documentation.", access: "read" }
+      { id: "vercel:read-deployments", name: "Read Deployments", description: "List teams/projects, check deployment status, and read build logs.", access: "read" }
     ],
-    docs_url: "https://vercel.com/docs/agent-resources/vercel-mcp",
-    // Beta until the headless OAuth flow (and Vercel's OAuth-client allowlist,
-    // which is vendor-side and outside our control) is verified end-to-end.
-    beta: true,
-    // No `auth`/`headers` — host-brokered OAuth (Claude Code authenticates
-    // directly with Vercel; nothing for us to inject). Declaring this here
-    // (rather than a hardcoded buildMcpJson/writeIntegrations branch, the
-    // pre-ENG-8035 Higgsfield-era pattern) lets the generic remote-MCP loop
-    // render the `.mcp.json` entry AND enrolls 'vercel' in the
-    // `registryRemoteMcpKeys` prune universe automatically, so an uninstall
-    // actually removes the entry instead of leaving it stale.
-    remoteMcp: {
-      type: "http",
-      url: "https://mcp.vercel.com"
-    }
+    docs_url: "https://vercel.com/docs/rest-api",
+    // Beta until the REST tool surface has been exercised against a real
+    // customer token. (The previous reason — "until the headless OAuth flow is
+    // verified end-to-end" — is void: there is no OAuth flow any more.)
+    beta: true
+    // NO `remoteMcp`. See the tombstone in the claudecode adapter's prune
+    // universe: dropping this field also drops `vercel` from
+    // `registryRemoteMcpKeys`, which would strand the `.mcp.json` entry on
+    // every host that installed the MCP variant.
   },
   {
     id: "qmd",
@@ -35671,6 +35686,54 @@ var FLAG_REGISTRY = [
     // Turning this on lets agents originate proposals that create customer
     // infrastructure once approved — same posture as augmented-support-writes.
     sensitive: true
+  },
+  {
+    key: "github-broker-credentials",
+    description: "Deliver GitHub App installation tokens to `git` and the `gh` CLI through the broker credential endpoint at USE time, instead of materializing them into the agent process environment at spawn (ENG-8344). A GitHub App installation token has a ~1h TTL, so the spawn-frozen GITHUB_ACCESS_TOKEN / GITHUB_TOKEN pair rotates hourly; the wrapper sources `.env.integrations` exactly once, so the only way a running agent sees the new value is a full session respawn (measured: 6 agents, ~144 kills/day). ENG-8343 stopped those kills landing mid-turn; this removes them. ON: `POST /host/agent-integrations` stops minting the installation token into the payload for auth_type=github_app rows (so computeIntegrationsHash stops seeing a rotating value) and marks the row credential_delivery=broker; the claudecode adapter then writes a git credential helper + a `gh` shim that fetch a fresh token per use from POST /host/agent-integrations/github/credential (ENG-8264 name addressing). OFF (default): byte-for-byte today's behaviour - the token is minted into the payload and materialized as GITHUB_ACCESS_TOKEN / GITHUB_TOKEN, no helper, no shim. NOTE the scope of the security claim: this removes the token from the agent's ENVIRONMENT, which is what stops the respawns. It does NOT make the token unreachable by a determined agent - the agent can invoke the helper itself. Strictly better than today, not a sandbox. Evaluated API-side only, per agent, in POST /host/agent-integrations; no host-side envVar. The host does not read this flag - it keys off the resulting credential_delivery marker on the row - so there is deliberately no host override that could put the token back on its own. Roll back from the flag.",
+    flagType: "boolean",
+    // Declared safe value is `false` = today's env delivery. Fail-safe direction:
+    // a flag-DB read error must never strip `git`/`gh` credentials off a live
+    // agent, which is what the ON path does when its host has no helper writer.
+    defaultValue: false,
+    // Flipping ON changes how every GitHub App agent on the scope authenticates
+    // `git push` / `gh`. A bad flip takes those away, so it is a deliberate,
+    // confirmed action (ADR-0022 §4).
+    sensitive: true,
+    // Set even though the flag is evaluated centrally, because `since` is a
+    // REACH threshold ("a host this old has no consumer code for the flag") and
+    // that is exactly the hazard here: the host does not read the flag, but it
+    // does need the claudecode adapter's helper/shim writer and the wrapper PATH
+    // prepend. On a host too old for those, the API would stop shipping the
+    // token and NOTHING would replace it. Without `since` the flip-reach modal
+    // reports FULL reach and hides that.
+    //
+    // DELIBERATE UNREACHABLE PLACEHOLDER - NOT A REAL THRESHOLD YET.
+    // The sibling entries in this registry (`slack-hot-thread-guard` 0.28.339,
+    // `slack-scheduled-channel-guard` 0.28.421) are BISECTED from published npm
+    // artifacts, which is only possible AFTER this merges and publishes. A
+    // pre-merge guess cannot be right, and the two directions are not
+    // symmetric:
+    //   - too HIGH  -> hosts classify `stale`, the modal over-warns. Annoying.
+    //   - too LOW   -> hosts classify `honors` while carrying NO helper writer,
+    //                  the modal promises full reach, and a flip strips `git`/
+    //                  `gh` credentials with nothing replacing them. Outage.
+    // So this is pinned ABOVE every published release on purpose: it classifies
+    // EVERY host as `stale`, so the modal reports no reach rather than reach it
+    // has no basis for. That is the intended pre-bisect state.
+    //
+    // BUT `since` IS ADVISORY, NOT A GUARD. It is read in exactly one place -
+    // `computeFlagReach` behind GET /admin/reach, which renders the flip-reach
+    // modal. `evaluate.ts` never reads it and neither does the override write
+    // path. The placeholder therefore changes what an operator is TOLD; it does
+    // not stop a flip on an under-`since` host. What actually holds the line
+    // here is `defaultValue: false` plus `sensitive: true` plus the runbook.
+    //
+    // BEFORE THIS FLAG IS FLIPPED ANYWHERE: bisect the published dist for the
+    // first agt-cli whose claudecode adapter writes agt-bin/ and whose wrapper
+    // prepends it, then replace this with that exact version. The rollout
+    // runbook gates on it. Leaving the placeholder in place is safe (nothing
+    // flips); shipping a guessed number is not.
+    since: "0.29.0"
   }
 ];
 var REGISTRY_BY_KEY = new Map(FLAG_REGISTRY.map((definition) => [definition.key, definition]));

package/dist/mcp/telegram-channel.js

@@ -33503,29 +33503,44 @@ var INTEGRATION_REGISTRY = [
     id: "vercel",
     name: "Vercel",
     category: "infrastructure",
-    description: "Check on Vercel app deployments \u2014 status, build/runtime logs \u2014 and search Vercel documentation. Remote streamable-HTTP MCP at https://mcp.vercel.com.",
-    // Same OAuth pattern as Granola/Higgsfield: Claude Code brokers the
-    // browser sign-in at runtime; nothing for the manager API to provision.
-    supported_auth_types: ["none"],
+    description: "Check on Vercel app deployments \u2014 what's live, deployment status, and build logs \u2014 through Vercel's REST API with your own API token.",
+    // ENG-8421: api_key, NOT the host-brokered MCP this used to be.
+    //
+    // Vercel MCP (`https://mcp.vercel.com`) is not completable from the
+    // console, and that is a vendor constraint rather than a gap in our
+    // plumbing. Established empirically 2026-08-03: Dynamic Client
+    // Registration REJECTS an https redirect (`invalid_redirect_uri` — "not
+    // approved for use by this authorization server") and ACCEPTS only
+    // localhost; the device-code grant, the one flow needing no redirect, is
+    // refused to DCR clients (`unauthorized_client`). So the only client
+    // Vercel permits is a local one redirecting to its own ephemeral port —
+    // i.e. Claude Code on the agent's host, driven by an operator running
+    // `/mcp` in tmux. No console work can remove that step.
+    //
+    // The REST API has none of those constraints: plain bearer auth
+    // (unauthenticated → `{"code":"forbidden","missingToken":true}`, bogus
+    // bearer → `{"invalidToken":true}`), so a token the customer creates in
+    // their own Vercel dashboard works directly. That makes this an ordinary
+    // paste-a-key integration, and it means WE hold the credential — so it can
+    // be stored, rotated, revoked and audited, none of which was true when the
+    // grant lived in Claude Code's `~/.claude.json` on the host.
+    //
+    // Tools are declared as data on `integration_definitions.metadata.tools`
+    // and dispatch through the existing Direct HTTP broker (the v0 pattern) —
+    // there is deliberately no bespoke Vercel client and no bespoke broker.
+    supported_auth_types: ["api_key"],
     capabilities: [
-      { id: "vercel:read-deployments", name: "Read Deployments", description: "List teams/projects, check deployment status, and read build/runtime logs.", access: "read" },
-      { id: "vercel:search-docs", name: "Search Documentation", description: "Search Vercel platform documentation.", access: "read" }
+      { id: "vercel:read-deployments", name: "Read Deployments", description: "List teams/projects, check deployment status, and read build logs.", access: "read" }
     ],
-    docs_url: "https://vercel.com/docs/agent-resources/vercel-mcp",
-    // Beta until the headless OAuth flow (and Vercel's OAuth-client allowlist,
-    // which is vendor-side and outside our control) is verified end-to-end.
-    beta: true,
-    // No `auth`/`headers` — host-brokered OAuth (Claude Code authenticates
-    // directly with Vercel; nothing for us to inject). Declaring this here
-    // (rather than a hardcoded buildMcpJson/writeIntegrations branch, the
-    // pre-ENG-8035 Higgsfield-era pattern) lets the generic remote-MCP loop
-    // render the `.mcp.json` entry AND enrolls 'vercel' in the
-    // `registryRemoteMcpKeys` prune universe automatically, so an uninstall
-    // actually removes the entry instead of leaving it stale.
-    remoteMcp: {
-      type: "http",
-      url: "https://mcp.vercel.com"
-    }
+    docs_url: "https://vercel.com/docs/rest-api",
+    // Beta until the REST tool surface has been exercised against a real
+    // customer token. (The previous reason — "until the headless OAuth flow is
+    // verified end-to-end" — is void: there is no OAuth flow any more.)
+    beta: true
+    // NO `remoteMcp`. See the tombstone in the claudecode adapter's prune
+    // universe: dropping this field also drops `vercel` from
+    // `registryRemoteMcpKeys`, which would strand the `.mcp.json` entry on
+    // every host that installed the MCP variant.
   },
   {
     id: "qmd",
@@ -35997,6 +36012,54 @@ var FLAG_REGISTRY = [
     // Turning this on lets agents originate proposals that create customer
     // infrastructure once approved — same posture as augmented-support-writes.
     sensitive: true
+  },
+  {
+    key: "github-broker-credentials",
+    description: "Deliver GitHub App installation tokens to `git` and the `gh` CLI through the broker credential endpoint at USE time, instead of materializing them into the agent process environment at spawn (ENG-8344). A GitHub App installation token has a ~1h TTL, so the spawn-frozen GITHUB_ACCESS_TOKEN / GITHUB_TOKEN pair rotates hourly; the wrapper sources `.env.integrations` exactly once, so the only way a running agent sees the new value is a full session respawn (measured: 6 agents, ~144 kills/day). ENG-8343 stopped those kills landing mid-turn; this removes them. ON: `POST /host/agent-integrations` stops minting the installation token into the payload for auth_type=github_app rows (so computeIntegrationsHash stops seeing a rotating value) and marks the row credential_delivery=broker; the claudecode adapter then writes a git credential helper + a `gh` shim that fetch a fresh token per use from POST /host/agent-integrations/github/credential (ENG-8264 name addressing). OFF (default): byte-for-byte today's behaviour - the token is minted into the payload and materialized as GITHUB_ACCESS_TOKEN / GITHUB_TOKEN, no helper, no shim. NOTE the scope of the security claim: this removes the token from the agent's ENVIRONMENT, which is what stops the respawns. It does NOT make the token unreachable by a determined agent - the agent can invoke the helper itself. Strictly better than today, not a sandbox. Evaluated API-side only, per agent, in POST /host/agent-integrations; no host-side envVar. The host does not read this flag - it keys off the resulting credential_delivery marker on the row - so there is deliberately no host override that could put the token back on its own. Roll back from the flag.",
+    flagType: "boolean",
+    // Declared safe value is `false` = today's env delivery. Fail-safe direction:
+    // a flag-DB read error must never strip `git`/`gh` credentials off a live
+    // agent, which is what the ON path does when its host has no helper writer.
+    defaultValue: false,
+    // Flipping ON changes how every GitHub App agent on the scope authenticates
+    // `git push` / `gh`. A bad flip takes those away, so it is a deliberate,
+    // confirmed action (ADR-0022 §4).
+    sensitive: true,
+    // Set even though the flag is evaluated centrally, because `since` is a
+    // REACH threshold ("a host this old has no consumer code for the flag") and
+    // that is exactly the hazard here: the host does not read the flag, but it
+    // does need the claudecode adapter's helper/shim writer and the wrapper PATH
+    // prepend. On a host too old for those, the API would stop shipping the
+    // token and NOTHING would replace it. Without `since` the flip-reach modal
+    // reports FULL reach and hides that.
+    //
+    // DELIBERATE UNREACHABLE PLACEHOLDER - NOT A REAL THRESHOLD YET.
+    // The sibling entries in this registry (`slack-hot-thread-guard` 0.28.339,
+    // `slack-scheduled-channel-guard` 0.28.421) are BISECTED from published npm
+    // artifacts, which is only possible AFTER this merges and publishes. A
+    // pre-merge guess cannot be right, and the two directions are not
+    // symmetric:
+    //   - too HIGH  -> hosts classify `stale`, the modal over-warns. Annoying.
+    //   - too LOW   -> hosts classify `honors` while carrying NO helper writer,
+    //                  the modal promises full reach, and a flip strips `git`/
+    //                  `gh` credentials with nothing replacing them. Outage.
+    // So this is pinned ABOVE every published release on purpose: it classifies
+    // EVERY host as `stale`, so the modal reports no reach rather than reach it
+    // has no basis for. That is the intended pre-bisect state.
+    //
+    // BUT `since` IS ADVISORY, NOT A GUARD. It is read in exactly one place -
+    // `computeFlagReach` behind GET /admin/reach, which renders the flip-reach
+    // modal. `evaluate.ts` never reads it and neither does the override write
+    // path. The placeholder therefore changes what an operator is TOLD; it does
+    // not stop a flip on an under-`since` host. What actually holds the line
+    // here is `defaultValue: false` plus `sensitive: true` plus the runbook.
+    //
+    // BEFORE THIS FLAG IS FLIPPED ANYWHERE: bisect the published dist for the
+    // first agt-cli whose claudecode adapter writes agt-bin/ and whose wrapper
+    // prepends it, then replace this with that exact version. The rollout
+    // runbook gates on it. Leaving the placeholder in place is safe (nothing
+    // flips); shipping a guessed number is not.
+    since: "0.29.0"
   }
 ];
 var REGISTRY_BY_KEY = new Map(FLAG_REGISTRY.map((definition) => [definition.key, definition]));

package/dist/{persistent-session-OMAAP4OU.js → persistent-session-BDNW4K6M.js}

@@ -37,7 +37,7 @@ import {
   writeDirectChatSessionState,
   writeEgressAllowlist,
   writePersistentClaudeWrapper
-} from "./chunk-4PRR22KH.js";
+} from "./chunk-7U63M5R6.js";
 import "./chunk-XWVM4KPK.js";
 export {
   EGRESS_BASELINE_DOMAINS,
@@ -79,4 +79,4 @@ export {
   writeEgressAllowlist,
   writePersistentClaudeWrapper
 };
-//# sourceMappingURL=persistent-session-OMAAP4OU.js.map
+//# sourceMappingURL=persistent-session-BDNW4K6M.js.map

package/dist/{responsiveness-probe-NRH2AQW6.js → responsiveness-probe-KR73VA2S.js}

@@ -1,6 +1,6 @@
 import {
   paneLogPath
-} from "./chunk-4PRR22KH.js";
+} from "./chunk-7U63M5R6.js";
 import "./chunk-XWVM4KPK.js";
 
 // src/lib/responsiveness-probe.ts
@@ -662,4 +662,4 @@ export {
   readAndResetSlackReplyBindingClassifications,
   readAndResetSlackReplyTargetClassifications
 };
-//# sourceMappingURL=responsiveness-probe-NRH2AQW6.js.map
+//# sourceMappingURL=responsiveness-probe-KR73VA2S.js.map

package/package.json

@@ -1,6 +1,6 @@
 {
   "name": "@integrity-labs/agt-cli",
-  "version": "0.28.507",
+  "version": "0.28.509",
   "description": "Augmented Team CLI — agent provisioning and management",
   "type": "module",
   "engines": {