# 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:

```bash
--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:

```text
--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:

1. Launch the isolated proxied Chrome profile **without relying on** `--load-extension`:

```bash
/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/
```

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

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

4. Physically click **加载未打包的扩展程序** in the visible Chrome window. A DOM `btn.click()` may not open the native file picker; `cliclick` physical coordinates did.
5. In the macOS “选择扩展程序目录” dialog, use `Cmd+Shift+G`, paste the extension repo path, press Enter, then press Enter/选择.
6. 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

1. Confirm no old profile owns the CDP port:

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

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

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

3. Launch a clean profile and verify with all three channels: CDP targets, Preferences, and screenshot of `chrome://extensions/`.

4. If Chrome stable continues hiding/ignoring unpacked extensions, check for policy restrictions and extension developer-mode behavior:

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

5. 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.