feat(providers): add custom API key header name for all provider types#2287
feat(providers): add custom API key header name for all provider types#2287Jesean wants to merge 3 commits intofarion1231:mainfrom
Conversation
Allow users to specify a custom HTTP header name for API key authentication when adding providers across all six app types (Claude, Codex, Gemini, OpenCode, OpenClaw, Hermes). - Default behavior is unchanged: Authorization: Bearer <key> - When a custom header name is set (e.g. x-api-key), the proxy sends the raw key value directly without the "Bearer" prefix - Universal injection is handled once in forwarder.rs so all adapters benefit without individual changes - Shared ApiKeyHeaderSection component keeps the UI consistent across forms - ProviderMeta.apiKeyHeaderName persists the setting to config Changes: - src/types.ts: add apiKeyHeaderName to ProviderMeta interface - src-tauri/src/provider.rs: add api_key_header_name to Rust ProviderMeta - src-tauri/src/proxy/providers/auth.rs: add custom_auth_header to AuthInfo - src-tauri/src/proxy/providers/claude.rs: apply custom header in Claude adapter - src-tauri/src/proxy/forwarder.rs: universal custom header injection before adapter call - shared/ApiKeyHeaderSection.tsx: new shared UI component (toggle + input + reset) - All six FormFields components: add ApiKeyHeaderSection after ApiKeySection - ProviderForm.tsx: wire up state and remove claude-only gate
|
@codex review |
There was a problem hiding this comment.
💡 Codex Review
Here are some automated review suggestions for this pull request.
Reviewed commit: 80d2ca6b91
ℹ️ About Codex in GitHub
Your team has set up Codex to review pull requests in this repo. Reviews are triggered when you
- Open a pull request for review
- Mark a draft as ready
- Comment "@codex review".
If Codex has suggestions, it will comment; otherwise it will react with 👍.
Codex can also answer questions or update the PR. Try commenting "@codex address that feedback".
- forwarder.rs: keep adapter companion headers when overriding auth. Previously the entire adapter header set was discarded; now only the authorization header is replaced, preserving headers like x-goog-api-client (Gemini) and Copilot-specific headers. - Remove custom API key header UI from OpenCode/OpenClaw/Hermes forms. These apps run from settingsConfig rather than provider.meta, so the field had no effect at runtime. Scope is now limited to Claude/Codex/ Gemini where meta is the authoritative config source.
|
Both review points have been addressed in 83a59a3:
|
Summary
Allow users to customize the HTTP header name used for API key
authentication when adding providers. Supported app types: Claude,
Codex, Gemini.
Motivation
Some third-party providers (e.g. those using `x-api-key` or other
custom headers) cannot be used with the default `Authorization: Bearer`
scheme. This change allows those providers to be configured with an
arbitrary header name.
Behavior
the raw key value is sent directly, without the `Bearer` prefix
Gemini, Copilot-specific headers) are preserved — only the
`authorization` header is replaced
Scope
Custom header is supported for Claude, Codex, and Gemini only.
OpenCode, OpenClaw, and Hermes run from `settingsConfig` rather than
`provider.meta`, so the feature is intentionally excluded from those
forms to avoid a silent no-op.
Changes
Backend (Rust)
replaces only the `authorization` header while keeping all other
adapter headers intact
Frontend (TypeScript)
reset to default, reused by Claude, Codex, and Gemini forms
consistent position across all three forms)
assembly now apply to Claude, Codex, and Gemini
Test plan
verify requests arrive with `x-api-key: ` (no `Bearer` prefix)
unchanged
pre-populated correctly