Chrome 152.0.7977.64-152.0.7977.75 silently fails to load unpacked extension: manifest registered but never parsed (no service worker, no UI card)

[ardha27]

Environment

• flow-agent version: v2.0.7 (commit 206285a, latest release)
• Chrome version: Google Chrome Stable 152.0.7977.64-152.0.7977.75 (tested both)
• OS: Ubuntu 20.04 (kernel 5.15.0-139-generic), headless X11 display :0
• Profile paths tested:
  • /home/rishua/.config/chrome-automation-profile (full of pre-existing extensions)
  • /home/rishua/.flow-chrome-profile (clean, previously worked in earlier sessions)
• Extension path: /home/rishua/flow-agent/flow-extension (default install)

Problem

Chrome silently fails to load the unpacked flow-agent extension on Chrome 152.x. The extension entry gets registered in Default/Preferences but the manifest is never parsed (manifest: NONE), no service worker ever starts, and the extension does not appear in the chrome://extensions UI list — even when the user clicks "Load unpacked" and the path is accepted (no error toast).

Reproduction steps

Via --load-extension CLI flag

/opt/google/chrome/chrome --user-data-dir=/home/rishua/.flow-chrome-profile \
  --remote-debugging-port=9334 --no-first-run --password-store=basic \
  --use-mock-keychain \
  --load-extension=/home/rishua/flow-agent/flow-extension \
  --disable-extensions-except=/home/rishua/flow-agent/flow-extension \
  --no-default-browser-check

Then query http://127.0.0.1:9334/json — no service_worker target appears, only the standard Google Network Speech worker. Inspecting Default/Preferences:

"mgkpdlhappckhnkbgoakaokheflhjlll": {
  "path": "/home/rishua/flow-agent/flow-extension",
  "manifest": null,   // ← THIS IS THE SMOKING GUN
  "disable_reasons": [],
  "state": 1
}

Via UI Load unpacked

1. Open chrome://extensions
2. Toggle Developer mode ON
3. Click Load unpacked → select the flow-agent/flow-extension directory
4. Click Open

Result: Chrome displays the toast "extension loaded successfully" but the card does not appear in the list. The same manifest: null state is observed in Preferences. No service worker ever starts, even after opening a labs.google/fx tab (which would normally trigger the content script to inject and wake the SW via onInstalled).

Things I already tried (all failed identically)

1. --load-extension flag with both fresh and populated Chrome profiles
2. Renaming the extension folder to force a new extension ID (mgkpdlhappckhnkbgoak... → jedmdoolcjlboglgekepkgkcoejdjhid → new ID each time, but same manifest: null result)
3. Manually clicking Load unpacked via the UI
4. Setting extensions.ui.developer_mode: true in Preferences manually
5. Disabling all other user-installed extensions (Grammarly, Adblock, Tampermonkey, etc.) in Preferences
6. pkill -9 chrome and re-launching Chrome with same flags
7. Upgrading Chrome from 152.0.7977.64 → 152.0.7977.75 via apt
8. Default/Extensions/<id>/ cache directory is never created by Chrome in any of these attempts (it usually appears immediately when a successful unpacked extension is loaded)
9. Waiting 30+ seconds for Chrome's 30s chrome.alarms reconnect loop in background.js to fire

Historical context

I previously ran this same extension successfully with the same flags on a Chrome 147-149 build (around late August 2026, see also #6 PR merge). The exact same folder, manifest.json, and background.js worked back then. The regression is correlated with the Chrome 152.x stable channel — there's no change in flow-agent source between working and broken states on my side.

Diagnosis

• Manifest file itself is valid (UTF-8, JSON-strict parseable, all required MV3 fields present: manifest_version, name, version, background.service_worker, content_scripts, permissions, host_permissions, declarative_net_request, side_panel, action, icons).
• No chrome_debug.log error is emitted for the extension — Chrome just doesn't materialize the Default/Extensions/<id>/ cache folder.
• creation_flags: 38 (binary 0b100110) in Preferences for the entry — flag 5 (FROM_BOOKMARK?) might be a Chrome 152-specific misclassification of unpacked extensions.

Suggested fix in flow-agent

Add "minimum_chrome_version": "100" (or higher) to flow-extension/manifest.json. Chrome 152 may be silently rejecting unpacked extensions that don't declare a minimum supported version, defaulting to a very old baseline that no longer matches MV3 expectations in the current stable channel. This single-line change would be a low-risk preventive fix — any Chrome 100+ user can still install it, and it signals to Chrome 152 to apply the modern unpacked-extension code path that the previous Chrome 147-149 builds were using implicitly.

Workaround used until this is fixed

Switched to direct CDP-driven browser automation of labs.google/fx/tools/flow UI (no extension required). The agent connects to Chrome's DevTools port, submits prompts via DOM event injection, polls media.getMediaUrlRedirect from the tRPC responses, and downloads results via Network.getCookies + urllib. This works but loses the parallel multi-worker benefit of the extension HTTP bridge.

Let me know if you need me to test a PR or grab additional Chrome logs.