← Back to PRs

#15689: fix: propagate provider headers to inline model objects

by julius2016 open 2026-02-13 18:46 View on GitHub →
agents stale size: XS
## Summary - `buildInlineProviderModels()` passes `baseUrl` and `api` from provider config to model objects, but omits `headers` - This causes custom HTTP headers (e.g. `User-Agent` overrides) to be silently ignored for all chat/reply API requests - One-line fix: add `headers: entry?.headers` to the model spread ## Context When using a custom provider with an Anthropic-compatible proxy that validates `User-Agent`, the configured headers are never sent. The Anthropic SDK sends its default `User-Agent: Anthropic/JS <version>`, which gets rejected by the proxy (403). The `pi-ai` Anthropic provider already supports `model.headers` via `mergeHeaders()` in `defaultHeaders`, and the runner entry (`runner-*.js`) already reads `providerConfig?.headers` — only the main reply path was missing it. This is a follow-up to #2740 which fixed the same class of bug for `baseUrl` but missed `headers`. Fixes #15682 ## Changes - `src/agents/pi-embedded-runner/model.ts` — add `headers: entry?.headers` to `buildInlineProviderModels()` - `src/agents/pi-embedded-runner/model.test.ts` — add test for headers propagation, update existing snapshot ## Test plan - [x] Added unit test: `inherits headers from provider config` - [x] Updated existing snapshot test to include `headers` field - [ ] Verify with a custom provider that requires specific `User-Agent` <!-- greptile_comment --> <h2>Greptile Overview</h2> <h3>Greptile Summary</h3> This change updates `buildInlineProviderModels()` to propagate provider-level HTTP `headers` into the inline model objects, and adds a unit test + snapshot update to validate that propagation. The code lives in the pi-embedded runner model resolution path (`src/agents/pi-embedded-runner/model.ts`), which builds the inline model entries that `resolveModel()` can normalize and return when a model isn’t found in the registry. <h3>Confidence Score: 4/5</h3> - Mostly safe to merge, but there is one correctness issue around header precedence that can drop per-model headers for inline models. - The PR is small and well-tested for provider-level header propagation, but the current implementation unconditionally assigns provider headers and can override existing model-level headers (a supported config field), changing behavior for users relying on per-model header customization. - src/agents/pi-embedded-runner/model.ts <sub>Last reviewed commit: 35c99bf</sub> <!-- greptile_other_comments_section --> <sub>(2/5) Greptile learns from your feedback when you react with thumbs up/down!</sub> <!-- /greptile_comment -->

Most Similar PRs