TopoloCli

Public customer command-line interface for Topolo organizations, developers, and agents. Internal engineering and operations commands are deliberately absent.

Current scope

• API-key authentication (long-lived, service-scoped).
• OAuth device-flow sign-in with a built-in first-party client — topolo auth login needs no client id; any Topolo user can sign in.
• Stored access-token refresh; the @topolo/mcp server reads the same credential, so agents need no API-key plumbing.
• Production credentials by default, with isolated profiles for approved self-hosted environments.
• Per-context credentials — hold and switch between your personal space and multiple organizations with topolo context.
• One-command agent setup — topolo setup detects and wires the bundled skill + MCP into Claude Code, Claude Desktop, Codex, Cursor, Grok Build, Gemini CLI, GitHub Copilot/VS Code, Windsurf, Cline, Goose, and Amazon Q Developer.
• End-to-end diagnostics — topolo doctor proves authentication and the MCP protocol path.
• Commands: auth, whoami, context, setup, doctor, skills, apps, services, resources, workspaces, credential-scoped actions, oauth, integrations, and generic api passthrough.

Install

npm install -g @topolo/cli
# or run ad-hoc:
npx @topolo/cli whoami

Configure

Use it from your terminal

Every command starts with topolo. Running topolo prints help and returns to your shell; it does not open an interactive prompt. Copy a complete command:

topolo auth login       # sign in with your browser
topolo whoami           # see who you are signed in as
topolo apps --no-json   # list your apps as a readable table
topolo auth --help      # see sign-in commands
topolo help apps        # see app commands and options

In help output, [brackets] mean an argument is optional and <angle brackets> mark a value to replace. Do not type the brackets. For example, help [command] means you can run topolo help or topolo help apps.

Credentials come from (in priority order):

1. Environment-specific credential variables
2. Global vars TOPOLO_API_KEY or TOPOLO_ACCESS_TOKEN
3. The selected environment profile in the config file ($XDG_CONFIG_HOME/topolo/config.json, mode 0600)

Production is the default customer environment. Use another environment only when your Topolo administrator provides its complete service configuration.

For interactive use:

topolo auth login             # OAuth device flow — no client id needed; approve in the browser
topolo auth login --api-key topo_live_...  # or store an API key directly (headless/service)
topolo auth status            # shows which source is active
topolo auth logout            # clears the stored credential

topolo auth login uses a built-in first-party OAuth client per environment, so any Topolo user can sign in without registering a client — what they can do is decided by their permissions. --client-id doac_... (or TOPOLO_CLI_CLIENT_ID / TOPOLO_<ENV>_CLI_CLIENT_ID) is only for advanced / self-hosted setups. Headless installs use --api-key.

While approval is pending, the CLI retains the same device request across temporary transport failures and doubles the polling interval after each failure. It honors the server polling interval and slow_down responses, stops on denial or other OAuth errors, and never extends the original device-code expiry.

Contexts

A user can act in their personal space or any organization they belong to. Each context has its own credential. Name the one to act as with --context <key> or TOPOLO_CONTEXT; without a pin the CLI (and the MCP) use the stored context only while it is the only one signed in for the environment. These credentials are independent from the shared web preference: switching a CLI/MCP context never moves the browser session, and a web switch never changes an already-issued CLI/MCP token or its refresh chain.

topolo context ls                          # personal + your orgs, and which is the stored default
topolo context use <organization|personal> # set the stored default (validated + a fresh token minted server-side)
topolo --context org:org_acme whoami       # pin one command to one context

No implicit default context. Once several contexts are signed in for an environment, every account command without --context/TOPOLO_CONTEXT refuses with "the context is no longer safe to assume", exactly like the multi-environment --env guard. topolo context use stays available for anyone who wants a stored default, but nothing relies on it implicitly.

topolo auth login stores the approved sign-in under its own context key and never moves the stored default (--use opts in; the environment's first sign-in becomes the default). It prints which user and organization were approved. To re-authorise one context, name it:

topolo --env production --context org:org_acme auth login

If the browser approves a different user or organization, the CLI warns that org:org_acme was not renewed and exits 1.

Wire into agent hosts

topolo setup             # registers the exact bundled MCP, pinned to the only signed-in context
topolo setup --all       # configure every supported local host
topolo doctor            # verifies auth, handshake, tool discovery, and identity

The MCP reads the same credential topolo auth login writes — no API key to paste. Every registration setup writes pins TOPOLO_ENV and TOPOLO_CONTEXT. Without --context, setup pins the only signed-in context, and refuses when there are none or several. For each additional organization, use an exact context key returned by topolo context ls --json:

topolo setup --name topolo-acme --context org:org_acme --env production
topolo doctor --name topolo-acme

This creates native registrations for each detected host using the same exact bundled MCP executable. Use --agent <host> to target one host explicitly, or --project <dir> when a host should receive project-scoped MCP and skill files. Reserved operator registrations cannot be created or removed by the public CLI.

Host ids accepted by --agent are claude, claude-desktop, codex, cursor, grok, gemini, copilot, windsurf, cline, goose, and amazon-q.

The local installer does not edit JetBrains AI Assistant settings or web-only connectors because those are managed through their own UI or remote connector configuration. Use the generated native MCP entry as the import source there.

Shared local MCP hub (opt-in)

Every stdio registration starts its own Node process in every agent thread, so N threads x M pinned identities means N x M MCP processes. The shared hub runs one loopback process that serves every identity at http://127.0.0.1:<port>/mcp/<name>; Claude Code and Codex connect to it by URL. Plain topolo setup keeps the stdio path; --shared is opt-in.

topolo --env production setup --shared --name topolo-acme --context org:org_acme
topolo --env staging    setup --shared --name topolo-acme-stg --context org:org_acme
topolo setup --shared --import-stdio   # move every existing stdio topolo/topolo-* entry onto the hub
topolo doctor --shared                 # hub, token, unit, registrations, then MCP whoami per identity
topolo mcp serve [--port 7337]         # what the keep-alive unit runs; foreground for debugging

setup --shared:

1. Adds the identity ({name, env, context}, exactly what a stdio entry pins with TOPOLO_ENV + TOPOLO_CONTEXT; both are always pinned, and without --context the only signed-in context is pinned) to mcp-hub.json next to the credential store (~/.config/topolo/mcp-hub.json, or the directory of TOPOLO_CONFIG_PATH). --import-stdio converts existing stdio entries and skips ones the hub cannot serve (entries with no TOPOLO_CONTEXT pin, private TOPOLO_CONFIG_PATH profiles, agent installations, invalid or conflicting definitions). Add a skipped unpinned entry back with --name <name> --context <context>.
2. Creates mcp-hub.token (256-bit, mode 0600) once and reuses it.
3. Registers every hub identity with Claude Code and Codex at user scope, replacing same-name stdio entries. --project is refused so the token can never land in a repository file. Other hosts stay on stdio.
4. Installs a keep-alive unit running the exact Node binary and CLI entry that ran setup (--no-service to skip): ~/Library/LaunchAgents/io.topolo.mcp-hub.plist (launchd, KeepAlive, logs to ~/Library/Logs/topolo-mcp-hub.log) or ~/.config/systemd/user/topolo-mcp-hub.service (Restart=always). Only TOPOLO_CONFIG_PATH/XDG_CONFIG_HOME are passed through; PATH and secrets are not. With --agent-home the unit is written there but not loaded.

Exact entries written (token shown as <token>):

// ~/.claude.json (written 0600)
"mcpServers": {
  "topolo-acme": {
    "type": "http",
    "url": "http://127.0.0.1:7337/mcp/topolo-acme",
    "headers": { "Authorization": "Bearer <token>", "X-Topolo-Agent": "claude-code" }
  }
}

# ~/.codex/config.toml (written 0600)
[mcp_servers.topolo-acme]
url = "http://127.0.0.1:7337/mcp/topolo-acme"
http_headers = { "Authorization" = "Bearer <token>", "X-Topolo-Agent" = "codex" }

Codex streamable-HTTP servers accept url, bearer_token_env_var, http_headers and env_http_headers; an inline bearer_token is rejected. http_headers is used so the hub works when Codex is launched from a GUI with no shell environment. To keep the token out of config.toml, replace the Authorization header with bearer_token_env_var = "TOPOLO_MCP_HUB_TOKEN" and export that variable (contents of mcp-hub.token) into Codex's environment.

Hub behaviour and security:

• Binds 127.0.0.1 only; there is no host option.
• Refuses any request whose Host is not 127.0.0.1, localhost or [::1] on the hub port, or that carries a non-loopback Origin (DNS rebinding and browser cross-origin calls), before checking the bearer token (constant-time). Only then is /mcp/<name> routed; GET /health lists identity names.
• Each identity has its own handler (@topolo/mcp/local) that resolves and refreshes its credential from the local store exactly as a pinned stdio MCP does. Process-wide TOPOLO_API_KEY/TOPOLO_ACCESS_TOKEN/TOPOLO_CONTEXT, request headers and other identities are never consulted; the hub token is stripped before the request reaches an identity.
• Stateless Streamable HTTP (no session ids), so restarts never strand a client.
• mcp-hub.json is re-read when it changes; adding an identity needs no restart.
• Logs carry method, path, status and duration only.
• Rotating the token: delete mcp-hub.token, rerun topolo setup --shared, then restart the agents.

Cross-org isolation

The CLI never accepts an orgId argument. Every command is scoped to the context embedded in the credential (personal or a specific org); to act in a different organization you pin that context's own stored credential (--context), or create one with topolo context use, which mints a new context-scoped credential — you can never target another org by passing an id. The context remains bound through refresh rotation and is not re-hydrated from the user's current web selection. This is enforced in two places:

1. The SDK does not expose any orgId parameter on any public method.
2. Each Topolo backend app re-derives orgId from the credential on every request and binds it to SQL query filters.

There is no code path in the CLI that could ever let you read or mutate another organization's data.

Audit headers

Every outbound request carries:

• X-Topolo-Client: topolo-cli/<version>
• X-Topolo-Agent: <label> (if TOPOLO_AGENT_NAME is set)
• X-Topolo-Request-Id: <uuid>

The platform logs these for traceability.

Write-action gating

The SDK defaults to requiring an explicit --confirm flag on any mutating request. Dynamic action calls and the generic topolo api passthrough enforce this too:

topolo actions call app_topolo_mail.messages.send --data '{"mailboxId":"primary","subject":"Hello"}' --confirm
topolo actions upload app_topolo_brand.brand_assets.upload --file ./logo.png --data '{"assetId":"asset_1"}' --confirm
topolo actions upload app_topolo_chat.uploads.request --file ./launch.mp4 --data '{}' --complete-data '{"conversationKind":"channel","conversationId":"channel_1"}' --confirm
topolo api mail POST /api/mail/mailboxes/primary/messages --data '{"subject":"Hello"}' --confirm
topolo api developers POST /api/internal/action-definitions/import --data @./request.json --confirm

--data on actions validate|plan|call and on api takes inline JSON or @<path> to read the JSON from a UTF-8 file, which keeps large payloads off the command line.

actions upload requires the resolved action to publish an upload contract. It reads the file, infers common MIME types or accepts --content-type, then follows either the declared inline-base64 mapping or the complete initiate/upload/finish URL-session flow. --complete-data supplies only fields required by a declared completion action; the upload/session id is mapped from the initiation response by contract.

Commands

topolo whoami

Prints the user, organization, and granted scopes.

topolo whoami           # pretty
topolo whoami --json    # machine-readable

topolo services

Lists the services the current credential can use in its organization, with the effective URL and granted permissions. This command requires a credential and does not expose the global platform catalog. In staging, environmentSafe: false means that service still resolves to a production URL and will be refused by topolo api until a staging URL override is configured.

topolo services --json
topolo services --env staging --json

topolo api accepts the IDs/slugs returned by this credential-scoped live catalog. New services become usable without a CLI release once Auth grants the organization and credential the relevant permissions.

topolo actions

Searches one application's callable actions for the current credential. Applications publish actions through Topolo Developers, Auth filters them by the same service permissions already used by API keys, launchers, and backend services, and the CLI calls them through the shared SDK.

topolo actions --service mail --json
topolo actions --service mail --detail --json
topolo actions get app_topolo_mail.messages.send --json
topolo actions call app_topolo_mail.messages.send \
  --data '{"mailboxId":"primary","subject":"Hello","text":"..."}' \
  --confirm --json

Use topolo actions before topolo api when an app has published a machine contract for the operation. topolo api remains the escape hatch for endpoints that are not yet in the action catalog.

Action search, capability discovery, validation, and planning return compact agent guidance by default. Use --detail only when the full schemas and agent contract are required. topolo resources --service <app> is accepted alongside the positional application selector.

Workspace-scoped actions carry resource context independently from the active personal/organization credential and independently from the browser session:

topolo actions call app_topolo_inventory.dashboard.get \
  --resource-type workspace \
  --resource-id <workspace_id> \
  --data '{}' --json

Both resource flags are required together. This supports concurrent agent operations across many app-local workspaces without changing the CLI/MCP org context or the user's web switcher.

topolo credentials write-custody

Local CLI and stdio MCP replace credentials in action results with opaque topolo-secret:<uuid> references held in the OS protected store (macOS Keychain, Linux Secret Service, Windows DPAPI). Both use the same store service and the same binding (environment, verified principal, organization and API key identity), so a reference returned by a stdio MCP call can be used by the CLI pinned to the same identity and environment. References expire after 30 minutes.

When a service such as the release controller needs a scoped API key in a custody file, write it straight from the reference so no person or agent sees the plaintext:

export TOPOLO_CONTEXT=org:<organizationId>
created=$(topolo --env production actions call app_topolo_auth.api_keys.create \
  --data '{"appId":"<appId>","name":"<label>","scopes":["<scope>"],"expiresInDays":90}' \
  --confirm --detail --json)   # data.key.secret is a topolo-secret reference
topolo --env production credentials write-custody "$(jq -r .data.key.secret <<<"$created")" \
  --api-key-id "$(jq -r .data.key.id <<<"$created")" --app <appId> \
  --out /absolute/custody/dir/production --confirm --json

The command:

1. Requires --confirm, an absolute --out, --app and --api-key-id. Keep one key per environment in its own subdirectory (for example .../catalog-publication-credentials/<environment>/). When the last path component is an environment name it must equal the credential's environment (custody_environment_mismatch otherwise), and custody.json.environment is always the environment the credential, protected store and Auth calls are bound to.
2. Creates --out (and any missing parents) with mode 0700, or accepts an existing 0700 directory owned by the current user. Every path component must be a real directory (no symbolic links); parents must be owned by root or the current user and must not be group- or world-writable (root-owned sticky directories such as /tmp are allowed).
3. Refuses to overwrite api-key.json or custody.json without --replace, and refuses symbolic-link or non-regular destinations even with it.
4. Reads the key's metadata from Auth app_topolo_auth.api_keys.list with the pinned credential and requires the same organization, the --app application, status active and an unexpired key.
5. Resolves the reference through the SDK protected store with its binding checks, then verifies the key against Auth introspection: it must be that API key id, application, organization and scope set.
6. Writes, each 0600 through a temporary file and rename in the same directory:
   • api-key.json: {"schemaVersion":1,"apiKey":"<secret>"}
   • custody.json: {schemaVersion, appId, scopes, organizationId, environment, apiKeyId, expiresAt, keyDigest, createdAt}. expiresAt and createdAt are Auth's values unchanged (epoch seconds, expiresAt null for no expiry); keyDigest is sha256:<hex> of the secret.
7. Deletes the local protected reference, like actions release-secret. This does not revoke the upstream key; use app_topolo_auth.api_keys.revoke.

Output (JSON or text) carries only paths, metadata and the digest. Refusals use stable error.code values: custody_confirmation_required, custody_invalid_input, custody_path_not_absolute, custody_environment_mismatch, custody_platform_unsupported, custody_path_symlink, custody_path_not_directory, custody_path_not_regular, custody_parent_insecure, custody_dir_insecure, custody_file_exists, custody_organization_required, custody_metadata_unavailable, custody_key_not_found, custody_app_mismatch, custody_organization_mismatch, custody_key_inactive, custody_key_expired, custody_secret_unsupported_type, custody_key_verification_failed, custody_key_mismatch, custody_metadata_mismatch, custody_reference_release_failed and custody_error_withheld, plus the protected store's invalid_action_secret_reference, action_secret_unavailable (unknown, or bound to another principal, organization, API key or environment), action_secret_expired, action_secret_invalid and action_secret_identity_required. A refusal before step 6 writes no custody file and keeps the reference (step 2 may already have created the empty 0700 directory).

topolo workspaces

Discovers canonical workspaces and the caller-specific creation policy for a target application. Auth owns workspace identity, while its runtime policy decides access separately for each app and caller.

topolo workspaces list design --json
topolo workspaces create design --name "Campaigns" --confirm --json
topolo workspaces rename design <workspace-id> --name "Social campaigns" --confirm --json
topolo workspaces default design <workspace-id> --confirm --json

Always read data.policy.canCreate and data.policy.reason from list before creation. Organization ownership is not treated as permission for every app.

topolo apps

Lists launchable Topolo applications available to the current credential. This uses the same live Auth catalog as topolo services; it is not the global generated application list.

topolo apps --json
topolo apps get mail --json

Only live, credential-scoped applications are returned. The public CLI contains no first-party repository metadata or compiled fallback catalog. Internal application lifecycle workflows are outside this customer CLI.

topolo oauth clients

Manage OAuth clients for Login with Topolo.

topolo oauth clients list --json
topolo oauth clients create \
  --name "Acme App" \
  --developer-id dev_... \
  --redirect-uri https://acme.example.com/auth/topolo/callback \
  --scope openid profile email organization:read entitlements:read \
  --json
topolo oauth clients rotate-secret oac_... --json
topolo oauth clients revoke oac_... --json

Client revoke disables the developer OAuth client for everyone. User disconnect is separate and uses DELETE /api/developer-oauth/connected-apps/:clientId.

topolo integrations

Generate and validate agent handoffs for third-party integrations.

topolo integrations prompt login-with-topolo --framework auto
topolo integrations check login-with-topolo --repo-root . --json

The Login with Topolo check looks for @topolo/login, callback handling, required env vars, account-linking fields, and refresh handling.

topolo api <service> <method> <path>

Escape hatch for endpoints without typed modules yet.

topolo api auth GET /api/me
topolo api mail POST /api/mail/mailboxes/primary/messages --data '{"subject":"Hello"}' --confirm

Use topolo services --json to discover app ids permitted for the current credential before calling a service that does not have a typed command yet.

Output modes

• Pretty when stdout is a TTY.
• JSON when piped or redirected.
• Force either with --json / --no-json.

Exit codes

| Code | Meaning | | ---- | ----------------------- | | 0 | Success | | 1 | Generic error | | 2 | Auth error | | 3 | Permission denied |

Development

cd TopoloCli
npm install
npm run build
node dist/index.js whoami

Agent skills

Installable guides for agents that drive the CLI on behalf of a user.

• Claude Code — copy skills/topolo/ into ~/.claude/skills/ (per-user) or <your-project>/.claude/skills/ (per-project). Claude picks it up automatically when the description matches the user's request.
• Codex — topolo setup installs skills/topolo/SKILL.md into the user skill directory and writes the deterministic MCP registration.

The one bundled skill covers credential handling, runtime discovery, write confirmation, and cross-org isolation. The CLI owns and registers its compatible MCP; do not install or synchronize @topolo/mcp separately.

Debug output

Set TOPOLO_DEBUG=1 to trace every SDK request to stderr (stdout stays clean so --json piping still works):

TOPOLO_DEBUG=1 topolo whoami
# [topolo] → GET auth /api/auth/me (req=8f3...)
# [topolo] ← 200 GET auth /api/auth/me (142ms, req=8f3...)

Request IDs match the X-Topolo-Request-Id header, so you can correlate a failing CLI call with the backend access log. Accepted truthy values: anything except 0 or false.

Token auto-refresh

If the stored access token is within 60 s of expiry, the CLI transparently exchanges the stored refresh token for a new pair before making the request and rewrites the config — no user action required. The OAuth client_id used at login is persisted alongside the credential so refresh can re-authenticate.

If refresh fails (network, rotated/revoked refresh token), the CLI proceeds with the stale credential and the request returns auth_error — run topolo auth login to re-authenticate. The stored config is not cleared on transient refresh failures.

Topolo Agent Packs

topolo agent-packs is the public entry point for portable business agent packs. The CLI bundles the Codex adapter and the qualified Claude Desktop Code preview. Python 3.11+ and a supported native host are required for local operations. No separate pack CLI installation is needed. The adapter README describes each host's current qualification and live-operation requirements. Cursor pack operations remain unsupported. MCP setup and pack adoption have separate proof.

topolo agent-packs add founder --harness codex
topolo agent-packs add founder --group specialists
topolo agent-packs add founder --agent strategy
topolo agent-packs switch founder
topolo agent-packs status
topolo agent-packs open --adapter-help

A first add builds the bundled template into a fresh installed instance. Later adds and switches resume that instance. --group selects the template's set; --agent selects an unambiguous logical agent. Use list to inspect installed names. Pack templates retain operating rules, rather than earlier work history. The underlying topolo-agent-pack adapter contains native switching and recovery. topolo agent-packs open exposes that adapter's existing managed Codex desktop route, including --app and --codex-bin. It uses the library's selected runtime and stable desktop profile; it does not select a new native home.

Cloud continuity uses explicit environment and authenticated context pins:

topolo --env production agent-packs connect founder \
  --environment production --context-key org:customer \
  --agent-workspace DISCOVERED_AGENT_WORKSPACE \
  --bytes-workspace DISCOVERED_BYTES_WORKSPACE \
  --ownership user --bytes-scope private --roles roles.json --confirm

roles.json maps every set/agent to an existing, exactly published agentId and agentVersionId. The hosted Agent and Bytes contracts must be released in the selected environment first. The CLI does not create grants, choose another customer, invoke model work or silently publish agent versions. See the bundled adapter README for memory, artifact and recovery commands.

Native child helpers require an explicitly selected private profile reference on the existing connection. Use connect --private-profile with a nonempty TOPOLO_CONFIG_PATH pointing to the already authenticated protected profile. The producer checks file ownership and modes, authenticates the selected environment/context, and verifies the connection before recording public profile metadata. Helpers build a child-only environment from that binding. Credential contents and inherited token overrides are excluded from the pack. Profile metadata does not establish native MCP configuration or runtime health.

Task-specific lane model intent is available through lane models-template and lane models-install; lane status reads durable state. Native settings, context, original-intake approval, operation outcome and retirement each require their own current acknowledgement. See the adapter guide for the closed inputs and lifecycle boundaries.

The source quality gate covers the CLI dispatcher and the Python continuity adapter separately. pnpm coverage creates a local test environment under node_modules/.cache, installs the pinned test-only coverage tool and requires 100% line and branch coverage for the cloud connection/recovery adapter. These tests use scoped fixtures and do not invoke models or mutate cloud data.

Claude dynamic private startup currently refuses with native_private_query_prestart_contract_unqualified. The installed desktop contract has not qualified private query MCP configuration, exclusion of other Topolo connections, and the owned shutdown lifecycle. Create, configure, context start, fixture start, retirement, and positive permission forwarding remain closed before native access. A valid private profile reference does not lift this boundary. Source fixtures and descriptor reads do not establish private MCP adoption or actual task completion.

Dynamic lane plans can explicitly select the native-cli continuity transport. Its closed remote-context --continuity-input operation produces a bounded public identity/context receipt with real response request IDs. The native thread's own command or Bash result and charter reads must independently match that receipt; an external shell result does not establish native context.

Current native startup, credential refresh authority and Bash result producers remain unqualified. Native CLI effects therefore refuse with native_cli_startup_unqualified before client/helper/native access. Private MCP startup retains its existing refusal. Version 1 plans stay readable and do not silently become version 2 CLI plans.

Preserving private pack runtime configuration

topolo agent-packs --store /owned/AgentPacks runtime-adoption plan --manifest /review/adoption.json produces a nonwriting configuration plan. Review its physical targets and digest, then use runtime-adoption apply --manifest /review/adoption.json --plan-digest <sha256> --confirm for one configuration-only attempt.

The closed owner manifest binds the actual consumer set and effective local Topolo transport origins, physical file preimages, shared aliases, private profile metadata, one of the two reviewed immutable consumer tuples (CLI 0.13.11/MCP 0.14.26/SDK 0.23.21 or CLI 0.13.12/MCP 0.14.27/SDK 0.23.22) and the separately pinned successor Python adapter. Consumer tuple versions are independent of the driver package version; mixed tuples and other versions refuse. It must include every server in each physical config as either a targeted transport or an explicitly untouched server. Empty or incomplete manifests refuse. The command never installs skills, rebinds a home, changes existing instructions/permissions, starts a consumer or probes Auth.

A successful apply means configuration is prepared. It does not mean existing processes reloaded it, the private account is healthy, permissions were granted or either native harness completed a task. Starting or refreshing consumers is a separate owner-authorized step and can contact private Auth and renew the selected private profile. Public credential-store repair is not a blanket prerequisite for independent private profiles. See the manifest and effect boundaries.

The protocol SDK pin addresses GHSA-6qxp-vccf-f47h. The CLI doctor's protocol transport is stdio. Separate HTTP OAuth consumers still need appropriate issuer binding for legacy credentials and bundled providers; this source update neither inspects nor migrates credentials.