Bug: Causes net::ERR_BLOCKED_BY_CLIENT and 403 errors on facebook.com

[WoodyBreizh]

Dear Peter,
First of all, I would like to thank you for the excellent quality of your work on summarize, as well as for the impressive body of open-source projects you maintain — in particular OpenClaw, which demonstrates remarkable vision and execution in the field of personal AI agents.
I recently installed the Chrome extension summarize (current version as of February 20, 2026) and observed that it systematically triggered the following errors on facebook.com:

net::ERR_BLOCKED_BY_CLIENT on legitimate AJAX endpoints such as /ajax/qm/?__a=1…
HTTP 403 errors on CDN resources (scontent-*.fbcdn.net)
Minified React error #418 (hydration failure), most likely caused by DOM or request modification introduced by the extension
Multiple ERR_NAME_NOT_RESOLVED failures and asynchronous message port closure issues

These symptoms rendered Facebook partially unusable (missing images, broken interface, blocked Messenger features).
After progressively disabling my extensions, I identified summarize as the direct cause. Once the extension was disabled, all errors disappeared immediately.
I understand that the extension likely performs content injections or request interception to enable page summarization (side panel), which can conflict with Facebook’s very strict anti-fraud mechanisms and security policies.
Would it be feasible to consider one of the following improvements in the medium term?

A user-configurable exclusion list (e.g., the ability to add facebook.com and *.facebook.com to ignored domains);
Automatic detection or temporary disabling of the “summarize current tab” mode on domains known to be highly restrictive (even if imperfect);
At minimum, a note in the README or on the store page warning that certain heavily protected social networks (Facebook, Instagram, etc.) may trigger conflicts.

Thank you once again for your outstanding contributions to the open-source ecosystem. I will continue to follow your projects with great interest — OpenClaw in particular looks fascinating.
Best regards,

[steipete]

$1

[steipete]

I did a fresh code read on current main.

I do not see any request-blocking path in the extension, so I can’t currently explain ERR_BLOCKED_BY_CLIENT from summarize alone. What I do see is:

• the extension still has broad host scope and content-script injection on <all_urls>
• the hover-summary localhost path was already moved behind the background service worker, which avoids page-origin localhost fetches
• there is now an extension E2E covering that hover proxy path

Relevant paths:

• apps/chrome-extension/wxt.config.ts
• apps/chrome-extension/src/entrypoints/extract.content.ts
• apps/chrome-extension/src/entrypoints/hover.content.ts
• apps/chrome-extension/src/entrypoints/background.ts
• apps/chrome-extension/tests/extension.spec.ts

So I think the remaining risk is broad manifest injection on strict domains like Facebook, not a known request blocker in summarize. The most robust fix would be to move from manifest-wide injection to on-demand chrome.scripting.executeScript when panel/hover/automation is actually used. A smaller mitigation would be a domain denylist (for example facebook.com, instagram.com). I’d keep this open until we either reproduce it or ship one of those mitigations.