Skip to content

fix: send the product User-Agent on provider registry and catalog fetches#1597

Merged
7Sageer merged 2 commits into
mainfrom
fix/registry-fetch-user-agent
Jul 13, 2026
Merged

fix: send the product User-Agent on provider registry and catalog fetches#1597
7Sageer merged 2 commits into
mainfrom
fix/registry-fetch-user-agent

Conversation

@7Sageer

@7Sageer 7Sageer commented Jul 13, 2026

Copy link
Copy Markdown
Collaborator

Related Issue

No linked issue — the problem is described below.

Problem

Fetches of provider registries (api.json) and the models.dev catalog went out without the product User-Agent — they only carried the runtime default (User-Agent: node), while every other outbound request (LLM calls, managed usage, WebSearch/FetchURL tools) already sends kimi-code-cli/<version>. Registries therefore cannot tell which client and version is calling them, and a generic node UA is more likely to be treated as bot traffic by WAFs.

What changed

  • fetchCustomRegistry and fetchCatalog accept an optional userAgent; the shared provider-refresh orchestrator threads it through RefreshProviderHost.
  • The CLI (kimi provider add, kimi provider catalog list/add) and the TUI (provider-add flows and the startup background refresh) pass the standard kimi-code-cli/<version> UA.
  • The v1 and v2 daemons pass the host identity UA on scheduled refreshes — v2 via the existing IHostRequestHeaders scope seed, User-Agent only, so device-identity headers never leave the host (matching ModelResolverService).
  • kap-server now seeds a default product User-Agent at bootstrap, so standalone v2 servers identify themselves too; hosts embedding kap-server (e.g. the CLI) override it with their full identity headers through opts.seeds.
  • Added tests covering the header on both fetch helpers, the v1/v2 refresh paths, and the kap-server default/override behavior.

When no host identity is available the behavior is unchanged (the fetch falls back to the runtime default UA). OAuth endpoints intentionally keep their existing no-CLI-UA behavior.

Checklist

  • I have read the CONTRIBUTING document.
  • I have linked a related issue, or explained the problem above.
  • I have added tests that prove my feature works.
  • Ran gen-changesets skill, or this PR needs no changeset.
  • Ran gen-docs skill, or this PR needs no doc update (no user-visible behavior change; request headers only).

…ches

Registry (api.json) and models.dev catalog fetches only carried the
runtime default User-Agent while every other outbound request sends
kimi-code-cli/<version>. Thread an optional userAgent through
fetchCustomRegistry / fetchCatalog and the shared refresh host, pass
the product UA from the CLI, TUI, and both daemons, and seed a default
product UA in kap-server that hosts can override via opts.seeds.
@changeset-bot

changeset-bot Bot commented Jul 13, 2026

Copy link
Copy Markdown

🦋 Changeset detected

Latest commit: c970702

The changes in this PR will be included in the next version bump.

This PR includes changesets to release 1 package
Name Type
@moonshot-ai/kimi-code Patch

Not sure what this means? Click here to learn what changesets are.

Click here if you're a maintainer who wants to add another changeset to this PR

@pkg-pr-new

pkg-pr-new Bot commented Jul 13, 2026

Copy link
Copy Markdown
pnpm dlx https://pkg.pr.new/@moonshot-ai/kimi-code@c970702
npx https://pkg.pr.new/@moonshot-ai/kimi-code@c970702

commit: c970702

@7Sageer 7Sageer merged commit d601847 into main Jul 13, 2026
10 checks passed
@7Sageer 7Sageer deleted the fix/registry-fetch-user-agent branch July 13, 2026 09:45
Sign up for free to join this conversation on GitHub. Already have an account? Sign in to comment

Labels

None yet

Projects

None yet

Development

Successfully merging this pull request may close these issues.

1 participant