Skip to content
All writing Part 03 of 12 · Remote-Controlling Chrome in Containers
Engineering · 3 min read

Chrome 128 Locks DevTools to Localhost

Chrome version 128 silently ignores --remote-debugging-address=0.0.0.0. Cross-pod connections break with no error message. Here is why, and what to do.

The Breaking Change

Before Chrome version 128, --remote-debugging-address=0.0.0.0 told Chrome to accept connections from any pod. Chrome version 128 ignores this flag. Chrome now always listens on 127.0.0.1 (group chat only).

Prerequisites: localhost vs 0.0.0.0 and CDP.

Chrome 127 and earlier --remote-debugging-address =0.0.0.0 works 0.0.0.0 = accept all calls Other pods CAN connect Chrome 128+ Flag IGNORED Always 127.0.0.1 127.0.0.1 = group chat only Other pods CANNOT connect

Why: CDP has no password. Anyone who connects can control Chrome. The Chromium team decided that network exposure is too dangerous.

Same Pod vs Separate Pods

Same pod: works API localhost Chrome Shared network namespace Separate pods: broken API Pod Chrome Pod 127.0.0.1 only
  • Same pod: API and Chrome share the group chat. No problem.
  • Separate pods: API must dial the extension. Chrome only reads the group chat. Connection fails.

The fix: put a socat receptionist inside the Chrome pod.

“Chrome has a flag called --remote-debugging-address=0.0.0.0. From version 128 onward, it does nothing.”


References:

Related: see the socat receptionist pattern that fixes this, or go back to the series overview.

Tags #kubernetes #chrome-devtools #containers
// connect

Be brave | Be wise | Be grateful

21 BreakinCode

// elsewhere
LinkedInMedium (lang: en)Life RecordYoutube
wh:~$William Hung· © 2026 Taipei · GMT+8 · Available for collaboration