ChromeOS Flags Worth Enabling — And the Ones to Avoid

ChromeOS shares the generic chrome://flags surface with desktop Chrome — GPU rasterization, parallel downloading, tab UI experiments — but it also carries a second category of flags that gate ChromeOS-only subsystems: the Crostini VM stack, ARCVM, Borealis, the scheduler, and privacy/permission surfaces tied to the Chromebook hardware model. This article only covers the second category. Generic Chrome browser flags are the same on ChromeOS as on Windows or Linux and aren't worth a dedicated pass.

Channels Gate What You Can See

Flag availability is a function of release channel, not just ChromeOS version. Stable exposes the smallest, most vetted subset. Beta and Dev expose progressively more, and Canary exposes everything currently in the tree, including flags whose backing code isn't feature-complete. Some ChromeOS-only flags — Borealis is the standing example — are hard-gated to Beta/Dev/Canary and simply don't render on Stable regardless of search terms.

Switching channels on a Chromebook is not equivalent to switching a flag. A channel change triggers a full OS image swap and, moving from a lower to higher channel, a Powerwash. Don't switch channels just to test one flag; check whether the flag is present on your current channel first.

Flags Worth Enabling

Crostini GPU support — #crostini-gpu-support

Crostini's Linux container (Termina VM, Debian userspace named "penguin") renders through virgl over virtio-gpu by default with CPU-side software rendering unless this flag is on. Enabling it routes GPU work through the host's graphics stack instead of falling back to LLVMpipe, which matters for anything doing OpenGL work inside the container — VS Code with GPU-accelerated rendering, Blender, or any Wayland app with compositing overhead. Requires a Chromebook with a GPU the virtualization layer actually supports; on unsupported hardware the container silently falls back to software rendering with no error.

ARCVM (Android runtime as a VM)

Android apps on ChromeOS have moved from ARC++ (a privileged LXC-style container sharing the kernel with the host) to ARCVM (a full VM booting its own guest kernel under crosvm). This is default on current Chromebooks and not a manually-toggled flag on recent hardware, but it's worth knowing which one you're running — chrome://system or cat /run/chrome/is_arcvm from crosh's vsh shell will tell you. ARCVM's isolation model is a meaningful security improvement over ARC++: a kernel exploit inside an Android app no longer has a direct path to host kernel structures. The tradeoff is memory overhead from running a second kernel image, which matters on 4GB devices.

Scheduler configuration (conservative) — #scheduler-configuration

Covered in detail below since the same flag appears in both the "enable" and "avoid" lists depending on which value you pick and what the device is used for.

Input device settings split — #enable-input-device-settings-split

Separates per-device input settings (trackpad sensitivity, keyboard remapping, mouse acceleration) so multiple connected pointing devices can each carry their own configuration instead of one global profile. Useful the moment you dock a Chromebook and plug in an external mouse with different acceleration expectations than the built-in trackpad. Low risk — worst case is settings duplication you have to clean up.

Touchscreen calibration — #enable-touchscreen-calibration

Exposes a calibration UI for touchscreen digitizer drift, which shows up on convertibles after a year or two of use as touch targets registering a few millimeters off from the visible element. Low risk, narrow use case, genuinely fixes a real hardware-aging problem when it applies.

Flags to Avoid

Scheduler configuration set to performance

#scheduler-configuration controls whether ChromeOS's core scheduler treats sibling hyperthreads as schedulable independently (performance) or keeps them idle unless both threads belong to the same security domain (conservative, the default). This exists because of L1TF and MDS-class speculative execution vulnerabilities: two hyperthreads sharing a physical core also share L1 cache and other microarchitectural state, and a malicious process on one thread can, under the right conditions, read data being processed on the sibling thread. conservative mode is ChromeOS's implementation of core scheduling — it keeps sibling threads either both idle or both running work from the same trust domain, which closes that channel at a throughput cost, typically single-digit to ~15% depending on workload.

Setting this to performance re-enables full SMT scheduling for the throughput back. That's a reasonable trade on a personal device where the primary threat model is "I want my build to finish faster," but it's the wrong default on shared, managed, or enterprise-enrolled hardware, or any machine that runs untrusted code (student devices, kiosk mode, multi-user Chromebooks). If you don't know why conservative is the shipped default, that's the reason.

#crostini-multi-container

Multiple Linux containers under one Termina VM sounds appealing if you want isolated dev environments without spinning up full VMs, but as of recent Dev/Canary builds the feature is incomplete: container lifecycle management (Cicerone/Concierge) wasn't built with more than one LXC container per VM as a first-class case, and the Terminal app's container-switching UI lags behind what the flag technically permits. Reports of container filesystem corruption after concurrent access from switched containers are the actual reason this stays on Dev/Canary. If you need isolated Linux environments, use separate vmc-managed VMs instead of stacking containers inside one Termina instance.

Canary-exclusive UI/feature flags

Anything gated to Canary got there because its backing service, IPC surface, or storage schema isn't finalized. The specific failure mode worth knowing: flipping a Canary-only flag that touches on-disk state (VM disk images, container filesystems, sync schemas) and then rolling back to Beta or Stable can leave that state in a format the older code doesn't understand. Recovery in that situation is usually a Powerwash, not a flag reset. If you're testing Canary-only ChromeOS-subsystem flags — not simple UI toggles — do it on a device you can afford to wipe.

Dead flags: the Lacros remnants

Lacros — the effort to decouple the Chrome browser binary from the ChromeOS system UI binary (ash-chrome) so the browser could ship on its own update cadence — was killed as an independent project in mid-2024 as Google redirected toward integrating more of the Android stack instead. Flags like #lacros-only and #lacros-availability-ignore still surface in some flag list snapshots and copy-pasted guides, but the ash/lacros split code they controlled has been removed from the tree. Toggling them does nothing — not an error, not a warning, just a flag with no consumer left to read it. This is a useful general lesson for chasing flags from older guides: a flag existing in a list someone published two years ago is not evidence it does anything today.

---

Practical Workflow

• Verify before you rely on a flag. Search chrome://flags directly by ID rather than trusting a blog post's flag list — if the search returns nothing, the flag has been removed, renamed, or was never on your channel.
• Check what's actually active. chrome://version lists command-line flags in effect, which is a more reliable audit trail than trying to remember what you toggled six months ago.
• Flags don't sync. Each device's flag state is local and doesn't travel with your Google account, and Powerwash resets it entirely. Keep your own list if you maintain more than one Chromebook.
• Enterprise policy overrides user flags. On managed devices, admin-configured policies for the same underlying feature take precedence over anything set in chrome://flags, silently. If a flag you set isn't taking effect on an enrolled device, check policy before assuming the flag is broken.
• One flag at a time. Especially for anything touching Crostini, ARCVM, or Borealis — these subsystems interact with disk allocation and VM lifecycle, and stacking multiple experimental changes makes it much harder to isolate which one caused an issue.