debugManifestsFile property not accepting anything other than localhost

[emmostrom]

What type of issue is this?

Question

What SharePoint development model, framework, SDK or API is this about?

💥 SharePoint Framework

Target SharePoint environment

SharePoint Online

What browser(s) / client(s) have you tested

• 💥 Internet Explorer
• 💥 Microsoft Edge
• 💥 Google Chrome
• 💥 FireFox
• 💥 Safari
• mobile (iOS/iPadOS)
• mobile (Android)
• not applicable
• other (enter in the "Additional environment details" area below)

Additional environment details

• browser version
• SPFx version
• 1.22.1
• Node.js version
• etc

Issue description

I am trying to test a webpart on a SharePont online workbench from a different machine than the development SPFx is running on.

adding debugManifestsFile=https://somewhere.com:4321/temp/build/manifests.js used to work but now seems to be ignored unless it is localhost with some port.

I can look in the developer console and see that it doesn't even try to load the manifest from that url and instead reverts to localhost.

I know the property is being set correctly because if I do localhost with an obscure port like https://localhost:4444/temp/build/manifests.js it does indeed try to pull the manifest from that port.

I thought it could be related to CSP changes and added the domain (like https://somewhere.com) to the trusted scripts but that didn't have any effect.

Is there another setting to get it to pull the manifest from somewhere other than localhost?

[Ashlesha-MSFT]

Hello @emmostrom,
Thank you for bringing this issue to our attention. We will look into it and get back to you shortly.
If you don’t receive a reply within two working days, please use this escalation form to escalate.

[Ashlesha-MSFT]

Hi @emmostrom,

Investigated this on SPFx 1.22.2 — unable to reproduce the original issue.
Here's what we found:

Repro attempt:

1. Added 127.0.0.1 devmachine.local to the Windows hosts file to simulate a non-localhost hostname pointing to the same machine
2. Started dev server with heft start --clean (SPFx 1.22 equivalent of gulp serve)
3. Opened workbench with:
   ?debugManifestsFile=https://devmachine.local:4321/temp/build/manifests.js&loadSPFX=true

Result: Web part loaded successfully — no fallback behavior observed.

Key observation from the CSP response header:
The workbench.aspx response automatically includes devmachine.local context was handled and the web part rendered correctly showing REST API data and Graph user info as expected.

Questions for you:

1. Can you confirm which exact SPFx version showed the regression? (working version vs broken version)
2. Does the issue still occur on 1.22.2 specifically?
3. Is your dev server on a genuinely separate physical/network machine, or same machine with a different hostname?

This would help narrow down whether it was fixed in a recent release or is still present in specific network configurations.

[emmostrom]

Yes it is a genuinely separate server with different ip, hostname and accessable via a dns entry.

I checked what you did with devmachine.local and it only appears to work for me. If I look at the web browser development console I see it pulling the manifest from localhost not devmachine.local. It only appears to work because devmachine.local is pointing to the local machine.

I don't think it is an issue with an SPFx version directly since it never gets to that point. It seems to be a problem with the SharePoint Online workbench.aspx not including the specific url I put in the debugManifestsFile parameter.

[Ashlesha-MSFT]

@emmostrom,
This seems to be due to security validation on remote origins (not strictly localhost-only), and we’re checking with the engineering team to confirm the exact constraints and supported scenarios.