Embedded browser shows custom error page for non-200 HTTP status codes (blocks login pages, error page development)

Support Bug Reports
,
1

Where does the bug appear (feature/product)?

Cursor IDE

Describe the Bug

When the embedded browser (Simple Browser or browser_navigate via MCP) encounters a non-200 HTTP status code — including 302 redirects, 403, and 404 — it renders Chrome’s generic error page (“This page isn’t working / sent an invalid response”) instead of the actual response content.

This affects two audiences:

Developers using the embedded browser for local development cannot:

  • Preview custom error pages (404, 403, 500) they are building or styling
  • Test login/auth flows that use HTTP redirects
  • Debug any server response that isn’t 200

Agents using cursor-ide-browser MCP cannot:

  • Complete SSO login flows (e.g. Keycloak/OIDC redirects return a login page via 302/303 — never rendered)
  • Access private GitHub repos (unauthenticated 404 should show the login page — shows error instead)
  • Navigate CI dashboards or any site behind auth gates

Steps to Reproduce

  1. Open the embedded browser or use browser_navigate via MCP
  2. Navigate to any URL that returns a non-200 status code, e.g.:
    • localhost:3000/nonexistent (custom 404 page from a local dev server)
    • A Keycloak-protected site (302 redirect to login page)
    • A private GitHub repository URL when not logged in (404)
    • Any URL returning 403
  3. Actual: Chrome error page: “This page isn’t working — [host] sent an invalid response. HTTP ERROR 403”

Expected Behavior

The actual response body is rendered (custom error page, login form, redirect target, etc.) — the same way Chrome, Firefox, or any standard browser would render it.

Operating System

MacOS

Version Information

Version: 2.6.20
VSCode Version: 1.105.1
Commit: b29eb4ee5f9f6d1cb2afbc09070198d3ea6ad760
Date: 2026-03-17T01:50:02.404Z
Build Type: Stable
Release Track: Default
Electron: 39.8.1
Chromium: 142.0.7444.265
Node.js: 22.22.1
V8: 14.2.231.22-electron.0
OS: Darwin arm64 25.3.0

Does this stop you from using Cursor

Sometimes - I can sometimes use Cursor

4

Hey, this is a known issue. The built-in browser intercepts all HTTP responses with status >= 400 and shows its own error page instead of the real server content. There are already a few reports about the same thing:

As a workaround, you can use the Playwright MCP server instead of the built-in browser. It launches a full Chromium and handles all HTTP statuses correctly, including auth flows and custom error pages. Setup is described in the MCP docs at Model Context Protocol (MCP) | Cursor Docs.

The team is aware of the issue. There’s no timeline yet, but your report helps with prioritization, especially since you explained the impact well for both developers and agents.

5

Note that the 2 linked issues are related, but different – that’s why I opened a new one.

  • This Bug report: Cursor browser should at least render the request body of any HTTP response
  • The other 2 reports (as I understand them): Cursor browsers should implement Basic Auth
6

I’m writing code in PHP (Symfony). Using the built-in browser is completely impossible.
The following important conclusions are hidden from the user and agent:

  • 500 error with stack trace
  • dump()/dd() output (dd() is also outputs 500 error)