BYOK custom inference forwarding requests should send or allow configuring User-Agent

[makoMakoGo]

Describe the bug

When Warp uses a BYOK / custom inference OpenAI-compatible endpoint, the server-side forwarding request to the custom endpoint does not send a usable User-Agent header, and Warp does not provide a way to configure one.

This causes HTTPS OpenAI-compatible endpoints behind Cloudflare or another gateway to fail with HTTP 403 when the gateway requires or filters by User-Agent.

The same endpoint works when called directly with curl and an accepted User-Agent header. It also works through an intermediate proxy if that proxy adds a User-Agent header before forwarding the request upstream. Without that proxy-level header injection, Warp's BYOK / custom inference flow cannot use the endpoint directly.

Warp custom inference provider settings currently expose only:

• endpoint URL
• API key
• models

There is no configuration for:

• User-Agent
• custom HTTP headers
• extra request headers

To reproduce

1. Configure a BYOK / custom inference OpenAI-compatible endpoint in Warp.
2. Use an HTTPS endpoint behind Cloudflare or another gateway that requires a User-Agent header.
3. Send a request from Warp.
4. The request fails with HTTP 403.
5. Send the same request with curl and explicitly include an accepted User-Agent header.
6. The request succeeds.

Example:

curl https://example.com/v1/chat/completions \
  -H "Authorization: Bearer <redacted>" \
  -H "Content-Type: application/json" \
  -H "User-Agent: <accepted-user-agent>" \
  -d '{
    "model": "gpt-5.5",
    "messages": [
      {
        "role": "user",
        "content": "hello"
      }
    ]
  }'

Expected behavior

Warp should do one of the following for BYOK / custom inference forwarding requests:

1. Send a stable default User-Agent header, such as a Warp-specific value; or
2. Allow users to configure outbound HTTP headers for custom inference providers, at minimum User-Agent.

For example:

User-Agent: Warp/1.0

or user-configurable provider headers:

{
  "User-Agent": "custom-client/1.0"
}

Actual behavior

Warp's BYOK / custom inference flow does not provide a way to configure request headers, and the forwarded request to the custom endpoint does not send a usable User-Agent header.

This makes otherwise OpenAI-compatible endpoints fail with HTTP 403 when they are behind gateways that require or filter by request headers.

Workaround

I had to put another proxy in front of the target endpoint and configure that proxy to add a User-Agent header when forwarding the request upstream.

This works, but it should not be necessary. Warp should either send a default User-Agent for BYOK forwarding requests or allow users to configure one.

Additional context

This is not about HTTPS versus HTTP. The endpoint is served over HTTPS; the problem is the HTTP request headers inside the HTTPS connection.

I searched existing issues for BYOK/custom inference and User-Agent/custom headers and did not find a duplicate for this specific problem.

Operating system (OS)

Cross-platform / server-side BYOK forwarding behavior.

Current Warp version

Not version-specific from my testing; this is about the current BYOK custom inference forwarding behavior.

Regression

No, this issue appears to be present in the current BYOK custom inference flow.

Does this block you from using Warp daily?

Yes, this prevents using Warp directly with otherwise-compatible OpenAI-compatible custom endpoints behind gateways that require User-Agent.

Is this an issue only in Warp?

Yes. The same endpoint succeeds with curl when the required User-Agent header is included.

[oz-for-oss]

@makoMakoGo

Here's what I found while triaging this issue:

Thanks for the detailed repro. Warp's custom inference configuration currently exposes endpoint URL, API key, and model identifiers, and this looks like an unsupported outbound-header case rather than an OS-specific issue.

Maintainer details

I concluded that custom inference/BYOK requests to OpenAI-compatible endpoints can fail behind gateways that require a User-Agent because Warp exposes and forwards only endpoint URL, API key, and model metadata for custom providers..

Triage summary

This looks like an actionable custom inference/BYOK routing bug in the Agent area. The reporter's observed behavior is that a custom OpenAI-compatible endpoint behind a gateway returns HTTP 403 from Warp, while the same endpoint succeeds via curl when an accepted User-Agent is provided and succeeds through a proxy that injects that header.

Code and documentation findings

• crates/ai/src/api_keys.rs stores custom endpoints as name, url, api_key, and models, and serializes CustomModelProviders with only base_url, api_key, and model slug/config key data.
• app/src/settings_view/custom_inference_modal.rs and app/src/settings_view/ai_page.rs expose only endpoint name, endpoint URL, API key, and model rows in the custom inference UI; there is no custom header or User-Agent field.
• app/src/ai/agent/api.rs and app/src/ai/agent/api/impl.rs attach those custom model providers to agent request settings, but no additional provider headers are represented in the client request payload.
• crates/http_client/src/lib.rs adds Warp-specific headers for Warp API requests and explicitly notes Warp does not use the User-Agent header for client identity, but the inspected client code does not prove the exact headers used by the downstream model-provider forwarder.
• The public custom inference docs describe configuring an endpoint URL, credentials, and model identifiers, but do not document configurable outbound headers.

Duplicate check

I enumerated open issues in warpdotdev/warp and compared BYOK/custom inference/header/403 candidates. #11604 is adjacent because it reports a custom inference 403 with a private proxy domain, #11598 concerns Authorization header handling for OpenRouter, and #10628 concerns display of raw 403 HTML, but fewer than two existing issues match this specific User-Agent/custom outbound-header request closely enough to mark this as a duplicate.

Remaining uncertainty

The likely missing capability is clear from the client-side configuration and request schema, but the actual upstream model-provider forwarding logic is not in the inspected checkout. That keeps root-cause confidence at medium rather than high.

This is my automated analysis and may be incorrect. A maintainer will verify the details.

Powered by Oz