Network/CORS failure in Hoppscotch web app without Interceptor

Problem Context

When sending a request from the Hoppscotch web application to a server that does not expose permissive CORS headers, the browser blocks the request. The UI displays a network/CORS failure instead of the API response. This behavior is documented as a failure condition for the browser‑based client.

Goal

Determine how the Interceptor component (browser extension, desktop app, or official proxy) interacts with this failure mode and whether the web app can automatically fall back to the proxy when a direct request is blocked. The question is version‑sensitive, as recent releases have shifted the product’s stance on automatic fallback.

Unresolved Decision

It remains unclear if the current Hoppscotch web app will route a CORS‑blocked request through the official proxy without explicit user configuration, or if the user must enable the Interceptor manually. This impacts how users should set up their environment for seamless API testing.

Specific Questions

• Does the Hoppscotch web app automatically route requests through the official proxy when a direct request fails due to CORS?
• If automatic fallback is not present, what configuration steps are required to ensure CORS failures are handled without manual interceptor setup?
• Is there a particular version or flag that enables automatic fallback to the proxy for CORS‑blocked requests?