What is the workaround for SharePoint developers blocked from workbench?

Does NOT WORK, I am very frustrated with Microsoft about this.

Hi Matthew Rogers

Thank you for reaching out to Microsoft Q&A forum

This is a well-known behavior caused by Private Network Access (PNA) enforcement in Chromium-based browsers (Edge, Chrome). The browser blocks the SharePoint-hosted workbench (a public origin) from fetching your local manifests.js served on localhost:4321, because it considers that a request from a public network to a private/loopback address.

Therefore, in this situation, you can use gulp serve with --nobrowser and test directly on a real SharePoint page, this is the officially supported approach going forward:

gulp serve --nobrowser 

Then navigate to any modern SharePoint page and append this query string:

?loadSPFX=true&debugManifestsFile=https://localhost:4321/temp/manifests.js 

For example:

https://yourtenant.sharepoint.com/sites/yoursite/SitePages/Home.aspx?loadSPFX=true&debugManifestsFile=https://localhost:4321/temp/manifests.js 

SharePoint will prompt you to allow loading debug scripts and click "Load debug scripts". This works because the request to localhost originates from a user action/permission prompt, not an automatic cross-origin fetch.

Hope my answer will help you.

If the answer is helpful, please click "Accept Answer" and kindly upvote it. If you have extra questions about this answer, please click "Comment".   

Note: Please follow the steps in our documentation to enable e-mail notifications if you want to receive the related email notification for this thread.  

The error is caused by the browser blocking access to http://localhost:4321 (loopback) while trying to load the SPFx debug manifests for the workbench/modern page.

Workaround for SharePoint developers:

1. Start the local SPFx dev server as usual:

      heft start --nobrowser
   

2. Load the modern SharePoint page and explicitly point it to the local manifests file by appending the debug query string parameters to the page URL:

      ?loadSPFX=true&debugManifestsFile=https://localhost:4321/temp/build/manifests.js
   

   Example (single line, no spaces):

      https://contoso.sharepoint.com/sites/team-a/sitepages/news.aspx?loadSPFX=true&debugManifestsFile=https://localhost:4321/temp/build/manifests.js
   

3. When prompted, confirm loading debug scripts. This lets SharePoint load the local SPFx bundles from the loopback address despite normal restrictions.
4. If using Dev Proxy or another local proxy, ensure it is not intercepting SPFx workbench or manifests requests. In devproxyrc.json, exclude the SPFx component API so workbench/debugging can function:

      {
        "urlsToWatch": [
          "!https://*.sharepoint.com/_api/web/GetClientSideComponents*"
          // other URLs to watch
        ]
      }
   

   The SPFx preset in Dev Proxy’s Sample Solution Gallery already includes this exclusion.

This combination (explicit debug query string plus excluding SPFx workbench APIs from interception) is the supported way to continue debugging SPFx solutions when loopback/CORS restrictions interfere.

References:

• Debug SharePoint Framework solutions on modern SharePoint pages
• Use Dev Proxy with SharePoint Framework (SPFx) solutions
• What is a proxy?