Allow a credential command in providers.json and managed settings so BYOK providers work without a per-invocation launcher

[peterj]

Describe the feature or problem you'd like to solve

Since 1.0.84, COPILOT_PROVIDER_API_KEY_COMMAND lets the CLI obtain a BYOK credential by running a command, so short-lived per-user tokens (OIDC/JWT from a gateway, Entra, STS, …) can rotate during a session. Thanks for that; it is the right primitive. (It isn't in changelog.md, and #3682, which requested it, is still open.)

The gap is that it only exists as an environment variable. The file-based surfaces have no equivalent:

• providers.json entries accept only a static apiKey / bearerToken.
• Enterprise managed settings (MDM / managed-settings.json) have no BYOK provider keys at all.

So anything that wants a rotating credential must set the environment before Copilot starts: a wrapper script, a shell alias, or a launcher process. Consequences:

• Plain copilot (and anything else that spawns copilot, e.g. IDE integrations, scripts, --acp) is not routed; only the wrapped invocation is.
• Organizations cannot enforce "route through our gateway with your identity" via policy; the user has to remember to use the wrapper.
• Writing the rotating token into providers.json as apiKey would put a bearer credential on disk and defeat rotation.

Other coding agents already support this in their config files, which is why the same gateway integration is a static config drop for them but a launcher for Copilot CLI:

• Codex: model_providers.<id>.auth = { command = "...", args = [...] } in config.toml / managed config.
• Claude Code: apiKeyHelper in settings.json / managed settings.
• Prior art elsewhere: Git/Docker credential helpers, AWS credential_process, kubectl exec credential plugins.

Proposed solution

Provider registry: accept a command-based credential in providers.json provider entries, with the same semantics as COPILOT_PROVIDER_API_KEY_COMMAND (run to obtain the credential; cache; re-run near expiry and on 401, then retry once):

{
  "providers": [
    {
      "name": "gateway",
      "type": "openai",
      "baseUrl": "https://gateway.example.com/v1",
      "wireApi": "responses",
      "apiKeyCommand": ["/usr/local/bin/agentdesktop", "credential", "--client-id", "copilot-cli"]
    }
  ],
  "models": [
    { "provider": "gateway", "id": "gpt-4.1", "modelId": "gpt-4.1", "wireModel": "gpt-4.1" }
  ]
}

(Field names other than apiKeyCommand should follow whatever the current providers.json schema uses. A bearerTokenCommand twin would mirror the existing apiKey / bearerToken pair.)

Prefer an argv array executed without a shell; optionally also accept a string executed like the env var does today.

Managed settings: allow the same provider definition (including the command) under enterprise managed settings, so an organization can pin the default provider and its credential source, and users cannot override it with a personal providers.json or env var.

Precedence: managed settings win when present; below that, keep env > providers.json > default, consistent with the flag > env > config ordering proposed in #2710. The env var keeps working as an override for ad-hoc use.

Security: never persist the command's output; redact it from logs, /collect-debug-logs, session state, and telemetry; run the command with a timeout and a bounded output size; treat non-zero exit as "no credential" rather than sending an empty bearer.

Example prompts or workflows

# Dropped once by MDM or a fleet agent, no per-user setup:
#   ~/.copilot/providers.json   the provider entry above
#   ~/.copilot/settings.json    { "model": "gateway/gpt-4.1" }

copilot                            # interactive
copilot -p "summarize this repo"   # non-interactive
copilot --acp                      # spawned by an IDE or ACP client

All three route through the gateway with no wrapper or alias, and the token rotates for the life of the session.

Additional context

Related: #3682 , #3282, #2710