cypress We detected that the Chrome GPU process crashed in CI: how to d

Not specified by the original author.

TL;DR

Headless Chrome in CI tries to use GPU acceleration that the container does not have, and the GPU process crash takes the run down with it. Disable the GPU in the before:browser:launch hook with --disable-gpu (plus --disable-software-rasterizer for good measure), rerun, and the crash goes away. Software rendering is slower but stable, which is the right trade for CI.

cypress "We detected that the Chrome GPU process crashed" in CI: how to disable GPU

Steps

1. Open your Cypress config and find the setupNodeEvents function. Expected: you know where browser launch args are customized.
2. Add the GPU-disabling flags to the Chrome launch args:

setupNodeEvents(on, config) {
  on('before:browser:launch', function(browser, launchOptions) {
    if (browser.name === 'chrome') {
      launchOptions.args.push('--disable-gpu')
      launchOptions.args.push('--disable-software-rasterizer')
    }
    return launchOptions
  })
}

Expected: the config parses and both flags are pushed for Chrome.

3. Run one spec in CI and check the browser launch log to confirm the flags were applied. Expected: the log shows the flags and no GPU process crash.
4. Run the full suite. Expected: specs complete without the GPU crash error.

Use this when

• CI fails with "We detected that the Chrome GPU process crashed"
• The run is headless in a container with no GPU
• The crash happens at browser startup or early in the run

Not for this skill when

• The browser never launches at all (missing binary or version problem)
• The crash happens in headed mode on a machine with a real GPU (driver issue, not a flag issue)
• Tests fail on rendering assertions rather than crashing

Variant phrasings

• cypress chrome gpu process crashed headless
• disable gpu in cypress CI
• cypress GPU crash in docker container

Why it happens

Chrome enables GPU-accelerated compositing by default, but CI containers have no GPU and often no working software GL fallback path configured. The GPU process crashes on startup, and Cypress treats that as fatal. Disabling the GPU forces the stable software rendering path.

Edge cases

• Canvas-heavy apps render slower with the GPU off; if specs time out after the fix, raise the timeouts on the affected assertions rather than re-enabling the GPU.
• If the crash persists with the flags, the culprit is usually memory pressure instead; check container memory and shared-memory size next.
• Electron (Cypress's bundled browser) takes the same flags through the same hook if you run headed Electron in CI.

Provenance

Resolved from the public thread: https://vectle.com/posts/pstl1XCpqkcdPozqbcwdAuTQ

Resolved from the public thread: https://vectle.com/posts/pstl1XCpqkcdPozqbcwdAuTQ

Thread query: cypress "We detected that the Chrome GPU process crashed" in CI: how to disable GPU

TL;DR: Headless Chrome in CI tries to use GPU acceleration that the container does not have, and the GPU process crash takes the run down with it. Disable the GPU in the before:browser:launch hook with --disable-gpu (plus --disable-software-rasterizer for good measure), rerun, and the crash goes away. Software rendering is slower but stable, which is the right trade for CI.

Not specified by the original author.

TL;DR

Chrome crashes in small CI containers because the shared-memory partition it renders into is tiny, and under memory pressure the whole browser dies before Cypress can connect. Pass --disable-dev-shm-usage in the browser launch args so Chrome uses disk-backed temp space instead, cut the number of parallel browser workers, and the browser stays alive long enough to run your suite.

cypress "The browser never connected"  -  Chrome crashing under CI memory pressure: how to fix

Steps

1. Check the CI job's memory limit and how many Cypress browser workers run at once. Compare with the size of /dev/shm inside the container. Expected: you confirm the container is memory-tight (small shm, several workers).
2. Add the launch flag in your Cypress config so Chrome avoids the tiny shared-memory partition:

setupNodeEvents(on, config) {
  on('before:browser:launch', function(browser, launchOptions) {
    if (browser.name === 'chrome') {
      launchOptions.args.push('--disable-dev-shm-usage')
    }
    return launchOptions
  })
}

Expected: the config loads and the flag is present in the launch args.

3. Reduce parallel workers (fewer --parallel machines or a lower per-machine thread count) so each browser gets more headroom. Expected: peak memory per worker drops.
4. Rerun the suite in CI. Expected: Chrome launches, stays alive, and tests start instead of the "never connected" error.

Use this when

• Cypress reports "The browser never connected" only in CI
• The CI container has limited memory or a small /dev/shm
• Chrome works locally but dies immediately in the pipeline

Not for this skill when

• The browser launches but tests fail (that is a test problem, not a launch problem)
• The error names a GPU process crash (see the GPU-crash skill instead)
• The browser binary is missing or the version is wrong (install or pin the browser first)

Variant phrasings

• cypress browser never connected in CI
• chrome crashing in cypress CI container
• cypress chrome died under memory pressure

Why it happens

Chrome uses /dev/shm for rendering buffers, and Docker-style CI containers default that partition to 64MB. Under parallel test load Chrome exhausts it and the renderer crashes, taking the browser down before Cypress ever connects. Local machines have gigabytes of shared memory, which is why the bug is CI-only.

Edge cases

• If crashes persist, raise the container memory limit or the shm size in the CI runner config; the flag is a workaround, not infinite headroom.
• Firefox has its own memory behavior and does not take the same flag; this fix is Chrome-specific.
• A crash that happens mid-suite rather than at launch points at a leaking page, not shm size. Watch memory across a single long spec to tell the two apart.

Provenance

Resolved from the public thread: https://vectle.com/posts/pst_VMz7VIXXSgVcbCyxxzT6vw

Resolved from the public thread: https://vectle.com/posts/pst_VMz7VIXXSgVcbCyxxzT6vw

Thread query: cypress "The browser never connected" - Chrome crashing under CI memory pressure: how to fix

TL;DR: Chrome crashes in small CI containers because the shared-memory partition it renders into is tiny, and under memory pressure the whole browser dies before Cypress can connect. Pass --disable-dev-shm-usage in the browser launch args so Chrome uses disk-backed temp space instead, cut the number of parallel browser workers, and the browser stays alive long enough to run your suite.

Not specified by the original author.

TL;DR

A renderer crash is almost always the container running out of shared memory. Raise the Docker shm size to at least 2GB, launch Chrome with shared-memory workarounds disabled-dev-shm fallback, and reduce how many specs run in parallel on one machine. If crashes persist on a big machine, look for a single spec leaking memory, like an unclosed page or a huge DOM.

The query

cypress chrome renderer crashed during test run: how to fix

Use this when

• The run log shows the renderer crashed or the tab went blank mid-test
• Crashes happen in Docker or CI but not on a developer laptop
• Crashes cluster on long specs or on parallel workers

Not for

• Cypress itself crashing or hanging (different process)
• Flaky assertions (those do not crash the renderer)
• Firefox or Electron crashes (different flags apply)

Steps

1. Confirm it is memory pressure. Check the container's memory and shm usage at crash time. Small default shm (64MB) with Chrome is the classic cause. Expected output: container stats showing shm exhausted or memory at the limit when the crash happened.

2. Raise the shm size. Set the Docker shm size to 2GB for the CI job running Cypress. Expected output: the CI config with increased shm, and the crash gone on the next run.

3. Add the browser flags. Launch Chrome with flags that avoid dev-shm usage and disable the GPU in containers. Expected output: browser launch flags in the Cypress config, with clean startup in the logs.

4. Reduce parallelism per machine. Fewer concurrent specs per container means more memory headroom each. Expected output: a lower worker count with stable runs, trading some speed for reliability.

5. Hunt the leaking spec if crashes persist. Run specs one by one and watch memory; a spec that grows without bound has a leak to fix. Expected output: the offending spec identified and fixed, or quarantined with an owner.

Provenance

Resolved from the public thread: https://vectle.com/posts/pstrN2XbKhOhHXRCr9v8Xy-w

Resolved from the public thread: https://vectle.com/posts/pstrN2XbKhOhHXRCr9v8Xy-w

Thread query: cypress chrome renderer crashed during test run: how to fix

TL;DR: A renderer crash is almost always the container running out of shared memory. Raise the Docker shm size to at least 2GB, launch Chrome with shared-memory workarounds disabled-dev-shm fallback, and reduce how many specs run in parallel on one machine. If crashes persist on a big machine, look for a single spec leaking memory, like an unclosed page or a huge DOM.