selenium headless chrome crashes in docker: --no-sandbox fix

TL;DR

Add --no-sandbox and --disable-dev-shm-usage to Chrome's arguments; that pair fixes nearly every Docker crash. The sandbox needs kernel privileges containers usually lack, and /dev/shm defaults to 64MB which starves the renderer. Verify Chrome launches before touching test logic.

Problem

Headless Chrome starts then crashes immediately inside Docker, while the same code works on a developer machine.

Steps

1. Add Chrome options args: --no-sandbox, --disable-dev-shm-usage, --disable-gpu, --headless=new. Expected: the browser process stays alive past startup.
2. Run a minimal script that only opens a blank page. Expected: the page loads with no crash.
3. If it still crashes, run the container with --shm-size=2g as well. Expected: renderer crashes on heavy pages stop.
4. Keep --no-sandbox scoped to test containers; do not browse as root with it disabled outside CI. Expected: local dev keeps the sandbox on.

When to use

• Selenium 4 with headless Chrome in Docker or CI containers.
• Chrome exits with sandbox or shared-memory errors in container logs.
• The same tests pass on bare metal or a full VM.

When not to use

• Chrome crashes on a normal desktop; that is a driver or version mismatch, not sandboxing.
• You run as non-root with user namespaces available; try keeping the sandbox first.
• Firefox (geckodriver) has different flags; these are Chrome-only.

Tool compatibility

• Selenium 4.x with Chrome for Testing and a chromedriver matching the Chrome major version.
• Docker and most CI container runtimes; --shm-size flag on docker run.

Variant phrasings

chrome failed to start crashed in docker selenium

Same fix; the crash is the sandbox or /dev/shm, not your test code.

selenium session not created in docker

If the error mentions DevToolsActivePort, the same flag pair usually unblocks it.

Why it happens

Chrome's sandbox relies on kernel features that are restricted inside unprivileged containers, so it aborts at startup. Separately, Docker's default 64MB /dev/shm is too small for Chrome's renderer, causing tab crashes on real pages.

Edge cases

• Old headless vs new headless mode behave differently; pin the mode that works and keep chromedriver matched.
• Corporate proxies can mimic a crash at session start; check the driver log for the real error line.
• ARM images need the right chromedriver build; an x86 binary crashes instantly on ARM.

Provenance

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