Custom inference endpoint via private proxy domain returns 403 in Warp while direct curl succeeds (no request observed at proxy)

[Skyxim]

Summary

Using a self-hosted multi-API proxy domain as a custom inference endpoint returns HTTP 403 in Warp, while direct curl requests to the same endpoint succeed.

Problem

When the user configures Warp to use a privately deployed proxy endpoint (custom domain) for model inference, Warp fails with 403. Official provider endpoints (xAI, DeepSeek) work under the same Warp setup. Direct curl calls to the custom domain with the same credentials/path succeed, suggesting the endpoint itself is reachable and functioning outside Warp.

Expected behavior

Warp should send requests to the configured custom inference endpoint and receive normal model responses, consistent with direct curl behavior.

Actual behavior

Warp returns HTTP 403 when using the custom endpoint. During failure, proxy-side packet capture shows no request being initiated from Warp, and server access logs show no corresponding access records. Switching to official provider APIs works.

Reproduction steps or desired workflow

1. Configure a custom inference endpoint in Warp Settings -> AI, using a self-hosted proxy domain.
2. Select a model routed through that custom endpoint and send a prompt.
3. Observe Warp returning 403.
4. Check proxy server logs / packet capture: no request from Warp is observed.
5. Call the same endpoint directly with curl using equivalent credentials: request succeeds.
6. Switch Warp back to official provider APIs (xAI / DeepSeek): requests succeed.

Artifacts

• Related conversation_id:
  {"conversation_id":"7ebab498-88c4-4df7-afc3-5b0de16e4734"}
• Proxy-side packet capture indicates no request was initiated from Warp, and server access logs show no corresponding access records during failures (not attached).

Warp version

v0.2026.05.20.09.21.stable_03

Operating system

macOS 26.5 (build 25F71)

[oz-for-oss]

@Skyxim

Here's what I found while triaging this issue:

This looks specific to custom inference endpoint routing rather than the proxy being generally unreachable, since direct curl succeeds and Warp's official provider endpoints still work. The supplied debugging ID should help maintainers check where the 403 is being generated.

I have a few follow-up questions before I can narrow this down:

1. Was the failed prompt sent from a local Warp Agent conversation or from a Cloud Agent run?
2. Does the custom endpoint hostname resolve only inside your private network or VPN, or is it publicly reachable from outside that network?

Reply in-thread with those details and the triage workflow will automatically re-evaluate the issue and update the diagnosis, labels, and next steps.

Maintainer details

I concluded that custom inference through a private proxy domain returns 403 in Warp before the reporter's proxy observes traffic, pointing to the custom model routing/backend egress path but still needing environment-specific endpoint details..

Triage summary

This appears to be a bug in custom inference endpoint routing for Agent requests, not a generic endpoint outage: the reporter says direct curl to the same proxy works, official provider endpoints work in Warp, and the proxy logs/packet capture show no inbound request when Warp returns 403.

Current client code stores custom endpoints locally, creates synthetic custom model IDs, and includes custom_model_providers in the multi-agent request settings (crates/ai/src/api_keys.rs, app/src/ai/llms.rs, app/src/ai/agent/api.rs, app/src/ai/agent/api/impl.rs). The custom endpoint dialog also requires HTTPS and rejects literal localhost/private IP hosts (app/src/settings_view/custom_inference_modal.rs), but a private DNS name can still pass client-side validation. If the hostname is only reachable from the reporter's private network/VPN, the 403 may be produced before the backend can reach the proxy, which would match the 'no request observed at proxy' symptom.

Repro confidence is medium: the report includes version/OS, steps, a debugging conversation ID, and an outside-Warp success case, but the actual proxy URL shape, network reachability, and run context are not included.

Dedupe check: I searched all open issues via gh api --paginate and checked recently closed issues from the last 7 days. Related but non-duplicate issues include #11598 (OpenRouter auth header prompt), #11589/#11591 (local/private URL validation), and #11538 (OpenRouter 402 payment error). I did not find two existing issues with the same private proxy + Warp 403 + no inbound proxy request pattern.

Question reasoning

1. Was the failed prompt sent from a local Warp Agent conversation or from a Cloud Agent run? — Custom endpoint configuration is local and routing differs by run context; knowing this materially changes whether Warp should have attempted to use the configured endpoint.
2. Does the custom endpoint hostname resolve only inside your private network or VPN, or is it publicly reachable from outside that network? — The proxy seeing no inbound request plus a private domain points to a possible backend reachability/egress boundary that maintainers cannot infer from the redacted report.

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

Powered by Oz