Chrome 147 unpacked extension loading anomaly (2026-05-09)

Context

During a Codex OAuth ordinary-account test run, the flow stopped before registration because the isolated visible Google Chrome profile did not reliably expose the unpacked automation extension.

Environment observed:

Chrome stable: Chrome/147.0.7727.139
Browser binary: /Applications/Google Chrome.app/Contents/MacOS/Google Chrome
Isolated profile root: /Users/chick/.Hermes/workspace/browser-profiles/codex-oauth
Remote debugging: 127.0.0.1:9223 / test 9224
Automation extension repo: /Users/chick/.Hermes/workspace/research/codex-oauth-automation-extension
Browser proxy used for the actual run: socks5://192.168.2.8:1085

Launch flags used for the working profile included:

--user-data-dir=/Users/chick/.Hermes/workspace/browser-profiles/codex-oauth/20260509-192515-working
--remote-debugging-port=9223
--enable-extensions
--disable-extensions-except=/Users/chick/.Hermes/workspace/research/codex-oauth-automation-extension
--load-extension=/Users/chick/.Hermes/workspace/research/codex-oauth-automation-extension
--proxy-server=socks5://192.168.2.8:1085
--no-first-run
--no-default-browser-check
--new-window https://api.ipify.org?format=json

Symptoms

Chrome process and CDP port started correctly.
Process args showed --load-extension and --disable-extensions-except exactly as expected.
CDP /json/version worked.
CDP /json only showed regular pages such as https://api.ipify.org/?format=json.
Opening chrome://extensions/ via CDP PUT /json/new?... worked, but the page was empty.
Default/Preferences existed, but extensions.settings was {} / empty.
Visual screenshot confirmed chrome://extensions displayed no codex-oauth-automation-extension card and no visible extension error.
Chrome stderr had updater/GCM/GPU noise but no clear manifest error.

A retry/minimal-extension probe showed confusing behavior:

A trivial unpacked MV3 extension under /tmp/hermes-test-extension was launched with the same style of --load-extension flags on port 9224.
CDP at one point listed service_worker | chrome-extension://fignfifoniblkonapihmkfakmlgkbkcf/service_worker.js, matching the prior automation extension ID, even when the current test was a different minimal extension.
chrome://extensions/ still displayed no extension cards.
Default/Preferences extensions.settings could still be empty even while transient extension-related targets appeared.

Confirmed root cause: Google Chrome stable blocks the flag

Verbose Chrome logging later produced the decisive line:

--load-extension is not allowed in Google Chrome, ignoring.

This means that on this BOSS macOS setup, Chrome stable 147 can show the --load-extension argument in ps, but still intentionally ignore it. This affected both the real automation extension and a minimal MV3 test extension, proving it was not a manifest/repo problem.

Working workaround: visible UI load-unpacked

Use the real visible Chrome UI instead of the command-line flag:

Launch the isolated proxied Chrome profile without relying on --load-extension:

/Applications/Google\ Chrome.app/Contents/MacOS/Google\ Chrome \
  --user-data-dir="$PROFILE_DIR" \
  --remote-debugging-port=9223 \
  --proxy-server="$BROWSER_PROXY_SERVER" \
  --no-first-run \
  --no-default-browser-check \
  --new-window chrome://extensions/

Open chrome://extensions/ via visible UI or CDP PUT /json/new?chrome%3A%2F%2Fextensions%2F if Chrome landed on a new-tab page.
Enable Developer Mode. CDP from the chrome://extensions page can do this:

chrome.developerPrivate.updateProfileConfiguration({ inDeveloperMode: true })

Physically click 加载未打包的扩展程序 in the visible Chrome window. A DOM btn.click() may not open the native file picker; cliclick physical coordinates did.
In the macOS “选择扩展程序目录” dialog, use Cmd+Shift+G, paste the extension repo path, press Enter, then press Enter/选择.
Verify chrome://extensions shows the card:
- name codex-oauth-automation-extension
- location UNPACKED
- state ENABLED
- service worker chrome-extension://<id>/background.js
- no manifest/runtime errors

Observed successful extension ID for the 2026-05-09 run: inebnmemmodcfoejiofegbeckbmjdlil.

Suggested next debug steps

Confirm no old profile owns the CDP port:

lsof -nP -iTCP:9223 -sTCP:LISTEN || true
ps auxww | grep -F '/Users/chick/.Hermes/workspace/browser-profiles/codex-oauth/' | grep -v grep || true

Kill only exact isolated profile processes; do not kill BOSS's normal Chrome unless explicitly approved.

pkill -f '/Users/chick/.Hermes/workspace/browser-profiles/codex-oauth/<profile-name>' || true

Launch a clean profile and verify with all three channels: CDP targets, Preferences, and screenshot of chrome://extensions/.
If Chrome stable continues hiding/ignoring unpacked extensions, check for policy restrictions and extension developer-mode behavior:

chrome://policy
# or inspect policy files / managed preferences if present

Consider a controlled comparison with another local Chrome/Chromium build only after preserving the requirement that the registration itself runs in a real visible browser and with the intended proxy.

User-facing reporting guidance

When this happens, report clearly that the run is blocked before registration, not on OpenAI signup itself. Include:

browser/profile launched: yes/no
proxy applied: yes/no
extension visible/registered: yes/no
registration started: no
mailbox status remains pending unless a signup was actually attempted

Avoid overclaiming that the extension loaded based only on a sleeping/transient service worker target.

5.8 KiB Raw Blame History