In Selenium, what do the Chrome arguments --no-sandbox and --disable-dev-shm-usage do on a CI container?
answer
- Browser switches, not Selenium settings
- One is about process isolation
- One is about shared memory
- Will not start versus crashes later
- Both work around a constrained container
basics
~20 sBoth are Chromium switches Selenium passes to the browser. The first turns off Chrome's process sandbox so it can start in a container without the needed kernel privileges. The second moves shared memory off a small /dev/shm.
solid answer
~40 sThey are browser command-line switches, not Selenium settings; Selenium forwards them when the session starts. `--no-sandbox` disables Chrome's renderer sandbox, which needs kernel privileges a locked-down CI container often withholds — without the flag the browser refuses to start at all. `--disable-dev-shm-usage` makes Chrome write its shared-memory files to an ordinary temporary directory instead of `/dev/shm`, because container runtimes usually mount a small one and renderer processes crash part-way through a run when it fills. Both are workarounds for a constrained container, and both have a proper fix outside Selenium: grant the privileges, or enlarge the shared-memory mount. Add them where the driver is built, not in individual tests.
code
java · 10 linesChromeOptions options = new ChromeOptions();
options.addArguments(
"--no-sandbox",
"--disable-dev-shm-usage",
"--window-size=1600,1200");
WebDriver driver = new ChromeDriver(options);
driver.get("https://irrigation.example.internal/schedule");
System.out.println(driver.getTitle());
driver.quit();go deeper
Recognise both arguments and be able to say, in one sentence each, what they turn off and why a container needs them. Know that Selenium passes them straight to the browser.
Explain the mechanism behind each: which kernel privileges the sandbox wants, and what fills up in a small shared-memory mount. Say what the non-Selenium fix would be for both.
Show that you distinguish the symptoms in a real pipeline log and that you would remove a flag once the container it worked around is fixed, rather than carrying it forever.
Own the standard: which browser arguments every pipeline gets, why each is on the list, who may add one, and how the security trade of disabling the sandbox is scoped to disposable agents only.
## The two arguments, one at a time Both are **Chromium command-line switches**. Selenium does not interpret them; it forwards them to the browser process when the session starts, which is why they read the same whether you are running locally or on a build agent. `--no-sandbox` turns off Chrome's sandbox, the mechanism that confines each renderer process so a compromised web page cannot reach the rest of the machine. Chrome's sandbox needs privileges from the kernel, and a locked-down CI container often does not grant them. Without the privileges Chrome refuses to start at all; with the flag it starts, minus that isolation layer. `--disable-dev-shm-usage` changes where Chrome puts its shared-memory files. By default they go in `/dev/shm`, the shared-memory filesystem. Container runtimes commonly mount a small `/dev/shm`, and when it fills, Chrome's renderer processes die mid-test — which surfaces as tabs crashing, sessions dying, and a suite that fails differently on every run. The flag tells Chrome to use an ordinary temporary directory on disk instead, which is slower but does not run out. ## Why they show up together in CI They travel as a pair because they answer the same question — *what does this container refuse to give the browser?* — from two directions. | | `--no-sandbox` | `--disable-dev-shm-usage` | |---|---|---| | What it turns off | the renderer sandbox | use of `/dev/shm` for shared memory | | Symptom without it | the browser will not start | renderers crash part-way through a run | | What it trades away | process isolation | some speed | | The alternative fix | grant the container the privileges | give the container a bigger `/dev/shm` | | Where the fix lives | the container platform | the container platform | The right-hand column of that table matters: both flags are **workarounds for a container that is too small or too restricted**, and both have a proper fix that lives outside Selenium, in whatever runs the container. Selenium's own browser images ask for a larger shared-memory mount at run time for exactly this reason. ## Passing them from a Selenium suite They are added as browser arguments on the options object, alongside anything else the job needs: - Set them where the driver is built, not in individual tests. - Keep them together with the other CI-only arguments so it is obvious they are environmental. - Do not scatter copies through page objects or fixtures; one factory, one list. Concretely, the nightly suite for a farm irrigation-schedule panel builds one `ChromeOptions`, adds the container flags and the window size, and every session inherits them. ## Where people go wrong 1. **Adding `--no-sandbox` everywhere, including local development.** On a disposable CI container running your own application it is a defensible trade. On a laptop that also browses the web it removes a real security boundary for no benefit, since the laptop's kernel grants Chrome what it needs anyway. 2. **Treating `--disable-dev-shm-usage` as a performance flag.** It is not. It moves shared memory from a memory-backed filesystem to disk, which is the slower option; you accept that because crashing is worse. 3. **Copying a whole block of flags from an internet answer.** Each argument should be there because a symptom made it necessary. A list nobody can explain is a list nobody can safely shorten later. 4. **Assuming these fix flaky tests generally.** They fix two specific environment problems. A wait that is racing, or a viewport that is the wrong width, is untouched by either of them. ## How to tell which one you actually needed The symptoms are distinguishable, and it is worth learning them rather than pasting both by reflex: - If the **session never opens** — the browser process exits immediately and no page is ever loaded — that is the sandbox. - If the session opens, some tests pass, and then the browser **dies part-way through a longer run**, especially one with several tabs or heavy pages, that is shared memory. - If the session opens and the page loads but the *layout* is wrong, neither flag is involved; look at the window size instead. Knowing which flag answered which symptom is what lets you remove one later, when the container it was working around has been fixed.
- If both flags are workarounds, what are the proper fixes?Give the container the kernel privileges Chrome's sandbox needs so the sandbox can stay on, and mount a larger shared-memory filesystem so `/dev/shm` does not fill. Both levers belong to whoever configures the container, not to the Selenium suite. Selenium's own browser images ask for a larger shared-memory mount for exactly this reason.
- How would you tell which of the two flags a failing job actually needed?Look at when it fails. A browser that exits immediately and never loads a page points at the sandbox. A session that opens, passes a few tests and then dies part-way through a longer run points at shared memory. A session that runs fine but renders the wrong layout points at neither.
saying these in an interview costs you the question
- Calls them Selenium options rather than browser switches
- Adds --no-sandbox on a laptop that browses the web
- Thinks --disable-dev-shm-usage makes the browser faster
- Pastes a whole flag block nobody on the team can explain
- Expects these flags to fix timing-related test flakiness