Fixing the 'absl::InitializeLog' STDERR warning in Selenium with ChromeDriver: causes and safe suppression

Seeing 'All log messages before absl::InitializeLog()...' with Selenium and ChromeDriver? Learn the native cause and suppress it via stderr redirection.

When you launch Selenium with Chrome or ChromeDriver and immediately see a noisy line like “All log messages before absl::InitializeLog() is called are written to STDERR”, it’s tempting to hunt for a Python logging tweak or a Selenium flag to silence it. The trouble is, this warning isn’t coming from your Python process at all, and most familiar knobs won’t touch it.

Reproducing the issue

A minimal Selenium script is enough to trigger the message on startup:

from selenium import webdriver
cfg = webdriver.ChromeOptions()
cfg.add_argument('log-level=3')
client = webdriver.Chrome(options=cfg)
client.get("https://example.com")
input()

The console may show something like:

DevTools listening on ws://127.0.0.1:62699/devtools/browser/8462948e-49fc-4e39-aa2b-bc89d4e3d0e4
WARNING: All log messages before absl::InitializeLog() is called are written to STDERR
I0000 00:00:1751797016.966696   65184 voice_transcription.cc:58] Registering VoiceTranscriptionCapability

Even if you already turned down Chrome logging via log-level, the abseil warning still appears.

What’s actually happening

The message is produced by native code inside the Chrome/Chromedriver stack and written directly to the process’ stderr. It’s not emitted by Selenium, and it doesn’t flow through Python’s logging facilities. Libraries like Abseil or gRPC in recent Chromium builds initialize their own C++ logging and can print early boot messages before any higher-level logging configuration is in place. That’s why you see the line about absl::InitializeLog and why it can be accompanied by lines referencing voice_transcription.cc.

Because the message is produced at the binary level, it bypasses Python-level redirection and Selenium verbosity controls. Changing ChromeOptions, tweaking Python loggers, or modifying environment variables that affect Python packages won’t affect a line written directly by a native child process to the terminal’s stderr.

Why the usual levers don’t work

Attempts like changing environment variables for unrelated stacks or redirecting Python’s file descriptors won’t help here. For example, setting these environment variables in Python has no effect on the Chromium-level printout:

import os
os.environ["GRPC_VERBOSITY"] = "ERROR"
os.environ["GLOG_minloglevel"] = "2"

Similarly, redirecting sys.stdout or sys.stderr inside Python doesn’t intercept what a native child process writes to the terminal:

import sys
buf = []
class Sink:
    def write(self, chunk):
        buf.append(chunk)
sys.stdout = Sink()
sys.stderr = Sink()

These changes only affect Python’s own file objects. Chrome/Chromedriver is separate and speaks directly to the OS-level streams.

What you can realistically do

There isn’t a clean, officially supported toggle to hide this particular warning today. It’s harmless and does not affect Selenium behavior. If you must remove it from your output, the practical options live outside Selenium and Python’s logging stack.

The reliable approach is to redirect stderr at the process boundary. You can run your Selenium script under a wrapper that starts the Python process with its stderr sent to a null device. In Python, that looks like invoking your script via subprocess with stderr redirected:

import subprocess
import sys
subprocess.Popen([sys.executable, "your_selenium_script.py"], stderr=subprocess.DEVNULL)

Alternatively, use your operating system’s shell to redirect the entire process’ stderr. Both techniques are workarounds, not fixes, but they do prevent the abseil warning from surfacing in your console or CI logs.

A note on which browser binary is used

Whether you see the message can vary depending on which Chromium-family binary is actually launched and which flags are passed. The runtime may pick Chrome or Chromium based on what appears first on your PATH, and if neither is available it can fall back to Chrome-for-Testing. It’s also possible to see the warning when starting google-chrome directly, yet not see it when Selenium launches the browser, simply because different executables or startup arguments are involved. None of this changes the root cause: the message comes from the native browser stack and not from Selenium or Python.

Why this matters

In CI pipelines and test runners, stray stderr output can confuse log parsers or make triage noisy. Understanding that this is a native startup message prevents you from chasing the wrong levers—Python logging, Selenium capabilities, or unrelated environment variables. It also clarifies why per-module suppression in Python won’t help and why redirection has to happen at the process level.

Summary and practical advice

If you encounter the “All log messages before absl::InitializeLog() is called are written to STDERR” line while running Selenium with Chrome/Chromedriver, treat it as a benign native warning. It’s not emitted by Selenium and won’t be silenced by Python-level logging tweaks, environment variables like GLOG_minloglevel or GRPC_VERBOSITY, or sys.stderr redirection. When the message must be eliminated from output, run the Selenium script under a wrapper that redirects the entire process’ stderr, or apply OS-level redirection. Otherwise, ignore it and proceed—the browser automation will work as expected.