A Cypress run fails to connect to the Chrome DevTools Protocol after 50 seconds. What do you check?

`Cypress failed to make a connection to the Chrome DevTools Protocol after retrying for 50 seconds` is one of the few Cypress errors that has nothing to do with your tests. Reading it correctly saves hours, because the instinct — rerun it, raise a timeout, blame flake — is wrong in every particular. ## What the error is actually telling you Cypress drives Chrome, Chromium and Edge over the **Chrome DevTools Protocol**, reached on a remote debugging port that the browser opens when Cypress launches it. After launching, Cypress retries that connection for up to 50 seconds. The error means two things at once: - **The browser did start.** A launch failure looks different; this one got far enough to spawn a process. - **The port never answered.** Typically the connection was refused outright. Because the connection is a precondition for everything, no spec ran, no screenshot exists, and the Command Log was never created. There is nothing to debug inside the runner — the evidence is on the machine. ## The policy that closes the channel In managed and corporate environments the most common cause is a browser policy that disables remote debugging. Chrome and Edge both expose `RemoteDebuggingAllowed`; when an administrator sets it to disabled, the browser refuses to open a debugging port at all, and Cypress — which has no other way to control it — cannot connect. The wording of the error in Cypress 16 says so explicitly and points at where to look. To confirm it: 1. **Open `chrome://policy`** (or `edge://policy` on Edge) in the affected browser, on the affected machine. Applied policies are listed with their values. 2. **Find `RemoteDebuggingAllowed`.** It must be undefined or enabled. Disabled is the failure. 3. **Re-run with a browser the policy does not cover.** The policy applies to branded Chrome and Edge, not to the Electron browser bundled with Cypress, so `cypress run --browser electron` is a quick control. If Electron connects and Chrome does not, the difference is the policy and not your project. Chromium builds and Chrome for Testing are generally outside branded-Chrome policy as well, which makes either of them a second useful control — and, for CI, a durable answer rather than just a diagnosis. ## Ruling out the other causes If the policy is clean, the remaining possibilities are environmental rather than project-level: - **Something else is holding the port**, or a firewall or endpoint-security product is intercepting loopback connections. - **The browser is being killed or sandboxed** by security tooling shortly after launch, so the port disappears before Cypress reaches it. - **The machine is badly overloaded**, so the browser genuinely takes longer than 50 seconds to become ready — plausible on a starved CI container, rare on a laptop. - **The binary is not what you think it is**: a wrapper script, a snap or flatpak confinement, or a profile directory the process cannot write. The distinguishing evidence is whether the same command works with a different browser binary on the same machine. That single comparison separates "this environment blocks remote debugging" from "this project is broken". ## What not to do - **Do not raise `defaultCommandTimeout`.** It governs command retries inside a test; no test has started. - **Do not add retries at the CI level.** A policy-blocked browser fails identically every time, and retrying just multiplies the wait. - **Do not reinstall Cypress** as a first move. The binary is fine; the browser is refusing to be driven. - **Do not treat it as flake.** Filing it as a flaky suite buries an environment problem that will keep recurring. ## Preventing the recurrence Once diagnosed, the fix is a decision about which browser binary the suite runs on, and it is worth making deliberately rather than per-developer. Pinning CI and local runs to a build that is not subject to branded-browser policy removes the whole class of failure and, as a bonus, removes silent browser upgrades from the picture. Where the suite must run on branded Chrome for fidelity reasons, the alternative is to get `RemoteDebuggingAllowed` explicitly permitted for the machines that run tests — an IT conversation, not a code change. Either way, write the diagnosis down where the next person hits it, because the error message reads like a Cypress bug and is not one.