Skip to content

Chrome Runtime regression: Local Network Access blockedΒ #545

Closed
obsproject/obs-studio
#14009

Description

@WizardCM

Operating System Info

Windows 10

Other OS

No response

OBS Studio Version

33.0.0-beta6

OBS Studio Version (Other)

No response

OBS Studio Log URL

N/A

OBS Studio Crash Log URL

No response

Expected Behavior

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

  1. Create a browser source that calls localhost
  2. 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.


See past analysis #538 (comment)

Activity

  1. added this to the OBS Studio 33.0 milestone on Oct 7, 2026
  2. e3ndr commented on Oct 28, 2026

    @e3ndr

    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 loopback address 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.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.

  3. WizardCM commented on Oct 28, 2026

    @WizardCM
    MemberAuthor

    @e3ndr Appreciate the heads up. I expect there are three possibilities here

    1. 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
    2. 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
    3. User simply needed to refresh the page and wait a few seconds - I experienced this in a quick test today
  4. e3ndr commented on Oct 28, 2026

    @e3ndr

    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.

  5. e3ndr commented on Oct 28, 2026

    @e3ndr

    Update from the user:

    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?

  6. WizardCM commented on Oct 28, 2026

    @WizardCM
    MemberAuthor

    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.

  7. e3ndr commented on Oct 28, 2026

    @e3ndr

    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 :)

  8. juliocargnin commented on Nov 2, 2026

    @juliocargnin

    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.

  9. WizardCM commented on Nov 2, 2026

    @WizardCM
    MemberAuthor
Sign up for free to join this conversation on GitHub. Already have an account? Sign in to comment

Metadata

Metadata

Assignees

No one assigned

    Labels

    No labels
    No labels

    Type

    No type

    Projects

    Relationships

    None yet

    Development

    No branches or pull requests

    Issue actions