You signed in with another tab or window. Reload to refresh your session.You signed out in another tab or window. Reload to refresh your session.You switched accounts on another tab or window. Reload to refresh your session.Dismiss alert
{{ message }}
Repository navigation
Chrome Runtime regression: Local Network Access blockedΒ #545
Local network requests should behave as before the CEF upgrade.
Current Behavior
Local network requests are blocked by default.
Access to fetch at 'http://localhost:3000/' from origin 'https://file.wzd.li' has been blocked by CORS policy: Permission was denied for this request to access the `loopback` address space.
Steps to Reproduce
Create a browser source that calls localhost
Notice the API call fails
Anything else we should know?
It looks like none of the alternate options outside of disabling LocalNetworkAccessChecks work properly. None of the standard permission dialogs are triggered. Will re-test before creating a PR.
So far, I have two users who've hit this issue on OBS 33.0.0, though I wasn't able to reproduce it on my machine.
When querying the navigator.permissions API, it returns granted for my machine and prompt for the other users (in addition to the error above being put into the OBS log).
This test link will display the permissions API's response on-screen in red text and also attempt to connect locally.
@e3ndr Appreciate the heads up. I expect there are three possibilities here
The user launched the beta before this fix was in place, and Chrome's code saved the automatic denial. Annoyingly the only fix for this is to delete the cache, I will look into ways of improving this but the available methods are quite limited
CEF's code didn't trigger the callback function so our code couldn't auto-accept it - a restart of OBS should kick it into gear
User simply needed to refresh the page and wait a few seconds - I experienced this in a quick test today
1 seems plausible, I'll have to ask them if they used the RC builds. If it helps, I did get a copy of their plugin_config/obs-browser which is able to reproduce the issue. What would be the best way of giving you a copy of that? Email or Discord?
For 2 and 3, there were a few restarts and browser source reloads during our testing (and, after getting a repro locally, refreshing and restarting doesn't seem to kick it into action). So I don't think those are the issue.
I didn't try the release candidate builds, at least I don't believe I did since I just update OBS whenever the newest release pops up when the app starts
I believe the OBS update dialog doesn't appear for RC builds. Which would've been the only builds to have the issue for 1, right?
Correct, yes. I will have to do some experimentation. I had originally considered running functions to be more forceful about this particular permission. It seems I might have to take that approach. Thanks for the added detail.
Just got confirmation that deleting plugin_config/obs-browser does indeed resolve the issue. Let me know if you want that copy of the busted browser cache. Apologies for all of the notifications :)
I'm having an issue that might be related to it: an app that I use to send MIDI inputs trough local host on the Browser Source stopped to work when I updated to version 33. Downgrading to prior version of OBS the same Browser Source start working again.
Activity
e3ndr commentedon Oct 28, 2026
Hate to necro, but I'm still seeing this issue crop up.
18:21:32.963: [obs-browser: 'Chat'] Error: Access to fetch at 'http://127.0.0.1:8092/api/test/0.dap0h7p992kh' from origin 'https://widgets.casterlabs.co' has been blocked by CORS policy: Permission was denied for this request to access the
loopbackaddress space. (https://widgets.casterlabs.co/caffeinated/loader-lnatest?addresses=%5B0%3A0%3A0%3A0%3A0%3A0%3A0%3A1%5D%2C127.0.0.1&port=8082)So far, I have two users who've hit this issue on OBS 33.0.0, though I wasn't able to reproduce it on my machine.
When querying the
navigator.permissionsAPI, it returnsgrantedfor my machine andpromptfor the other users (in addition to the error above being put into the OBS log).This test link will display the permissions API's response on-screen in red text and also attempt to connect locally.
WizardCM commentedon Oct 28, 2026
@e3ndr Appreciate the heads up. I expect there are three possibilities here
e3ndr commentedon Oct 28, 2026
1 seems plausible, I'll have to ask them if they used the RC builds. If it helps, I did get a copy of their
plugin_config/obs-browserwhich is able to reproduce the issue. What would be the best way of giving you a copy of that? Email or Discord?For 2 and 3, there were a few restarts and browser source reloads during our testing (and, after getting a repro locally, refreshing and restarting doesn't seem to kick it into action). So I don't think those are the issue.
e3ndr commentedon Oct 28, 2026
Update from the user:
I believe the OBS update dialog doesn't appear for RC builds. Which would've been the only builds to have the issue for 1, right?
WizardCM commentedon Oct 28, 2026
Correct, yes. I will have to do some experimentation. I had originally considered running functions to be more forceful about this particular permission. It seems I might have to take that approach. Thanks for the added detail.
e3ndr commentedon Oct 28, 2026
Just got confirmation that deleting
plugin_config/obs-browserdoes indeed resolve the issue. Let me know if you want that copy of the busted browser cache. Apologies for all of the notifications :)juliocargnin commentedon Nov 2, 2026
I'm having an issue that might be related to it: an app that I use to send MIDI inputs trough local host on the Browser Source stopped to work when I updated to version 33. Downgrading to prior version of OBS the same Browser Source start working again.
WizardCM commentedon Nov 2, 2026
@juliocargnin sounds more likely to be obsproject/obs-studio#14118