## 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