diff --git a/src/proxy.ts b/src/proxy.ts
index a2811a0..48feed7 100644
--- a/src/proxy.ts
+++ b/src/proxy.ts
@@ -171,11 +171,22 @@ export default clerkMiddleware(
       reportTo: "/api/csp-report",
       directives: {
         // Clerk's own middleware adds its frontend API host to connect-src
-        // automatically, but NOT to script-src — without this, the initial
-        // (unversioned) clerk.browser.js/ui.browser.js load is blocked by
-        // 'strict-dynamic' before the 307 redirect to the versioned URL,
-        // producing two CSP violations (reported to /api/csp-report) on
-        // every page load that renders Clerk UI.
+        // automatically, but NOT to script-src. Added it here too, but
+        // verified (2026-09-01) this does NOT fix it: with 'strict-dynamic'
+        // present, CSP3 browsers ignore host-based entries in script-src
+        // entirely (same reasoning as the 'unsafe-inline' fallback comment
+        // above) — Chrome's own violation message confirms this ("Note that
+        // 'strict-dynamic' is present, so host-based allowlisting is
+        // disabled"). The initial (unversioned) clerk.browser.js/ui.browser.js
+        // load still gets blocked before its 307 redirect to the versioned
+        // URL, producing two harmless-but-noisy CSP violations (reported to
+        // /api/csp-report) on every page that renders Clerk UI — Clerk loads
+        // fine via the redirect regardless. Root cause is on Clerk's side
+        // (that script tag isn't part of a nonce-trusted load chain); fixing
+        // it here would mean dropping 'strict-dynamic', a real regression
+        // from the CSP Enforcement hardening. Kept only as the same
+        // spec-mandated pre-CSP3 fallback the 'unsafe-inline' entry already
+        // relies on.
         "script-src": [`https://${getClerkFrontendApiHostname()}`, "unsafe-eval", "'report-sample'"],
         "img-src": [`https://${getSupabaseHostname()}`, "https://image.mux.com", "blob:"],
         "connect-src": [