obs-studio icon indicating copy to clipboard operation
obs-studio copied to clipboard

OBS 32.0.4 Keeps Asking for Re-authentication of My YouTube Account on macOS

Open mohul-gaikwad opened this issue 2 weeks ago • 5 comments

Operating System Info

Other

Other OS

macOS Tahoe 26.2

OBS Studio Version

Other

OBS Studio Version (Other)

32.0.4

OBS Studio Log URL

https://obsproject.com/logs/LkMz8vsTCaHOQkk1

OBS Studio Crash Log URL

No response

Expected Behavior

Definitely expect not to log me out each time i open obs

Current Behavior

I’m currently using OBS version 32.0.4 on macOS and I’ve run into an issue where it keeps asking me to re-authenticate my YouTube account every time I start the program. Essentially, the login doesn’t persist between sessions. There are no error messages it just prompts for re-authentication each time.

I wanted to note that this issue did not occur in version 32.0.2, but it started happening in versions 32.0.3 and continues in 32.0.4. I’ve also tried running OBS in safe mode, but the issue still persists even there.

I’m not certain if reverting to version 32.0.2 would solve the problem, but it appearsthat the recent updates introduce it. Just wanted to report this so you’re aware. Thanks for looking into it!

Steps to Reproduce

1.	Open OBS 32.0.4 on macOS.
2.	Click on Start Stream get prompted (Could not access the specified channel or stream key, please        double-check your stream key. If it is correct, there may be a problem connecting to the server.)
3.	go to settings re authenticate 
4.	start stream (works normally)
5.     close obs
6.     open obs (after few minute or after few hour) get logged out need to re authenticate again
7.      close it and open it again and authenticate each time

Anything else we should know?

everything was working good till version 32.0.2, I have noticed this problem in 32.0.3 and 32.0.4, this is previous log url might be help full https://obsproject.com/logs/HryXee9S143xsIuj I’m using MacBook M1 (Mac with apple silicone chip) macOS version 26.2

mohul-gaikwad avatar Dec 15 '25 15:12 mohul-gaikwad

image

Didn't know how and where to add this image but after closing obs it shows this on my screen and then issue starts

mohul-gaikwad avatar Dec 15 '25 15:12 mohul-gaikwad

Tried reverting to 32.0.2 but it shows server failed error so got no option but to get back to .4, this is extremely frustrating please fix the issue

mohul-gaikwad avatar Dec 15 '25 15:12 mohul-gaikwad

Was confirmed on another user, attached relevant log and crash report.

2025-12-15 03-48-18.txt OBS-2025-12-15-034950.ips.json

Penwy avatar Dec 15 '25 17:12 Penwy

Was confirmed on another user, attached relevant log and crash report.

2025-12-15 03-48-18.txt OBS-2025-12-15-034950.ips.json

I am sorry, I was unaware that this issue had already been reported. Thank you for the confirmation and for looking into this. I hope the issue will be resolved soon.

mohul-gaikwad avatar Dec 15 '25 20:12 mohul-gaikwad

They were just adding that another user could also reproduce, there is no other issue report at the moment, this remains the primary issue for tracking.

Fenrirthviti avatar Dec 15 '25 20:12 Fenrirthviti

Preliminary investigation suggests that this crash is due to OBSBasic's destructor running recursively when the YouTube browser dock is active (user-created browser docks don't seem to produce the same outcome):

  • Shutting down OBS from within the application is implemented as closing the "main window".
  • Closing the main window triggers a very bespoke series of events, at which end a DeferredDelete event is scheduled that actually deletes the main window
  • This leads to the OBSBasic destructor being run
  • As part of the destructor, the destructor for QList<std::shared_ptr<QDockWidget>> is invoked
  • Because of the YouTube browser dock, this invokes std::default_delete<QDockWidget> and thus the destructor of YouTubeAppDock and QCefWidgetInternal
  • QCefWidgetInternal's destructor calls closeBrowser() (a perpetual bugbear of the app) which runs its own event loop to "wait" for CEF to shut down while blocking execution of the destructor

Because there can only be one event loop active for an application, this event loop will not only wait for CEF to emit its event when finished, but also handle all other application events, one of them being a QMetaCall to QCocoaIntegration::Quit (which just calls [NSApp terminate:nil]).

This triggers the - (NSApplicationTerminateReply) applicationShouldTerminate:(NSApplication *) sender AppKit delegate method implement by Qt's platform plugin, calling QWindowSystemInterface::handleApplicationTermination(), which sends a proper "Quit" event to the QGuiApplication instance.

The aboutToQuit event is emitted, the custom event handler in OBSapp runs and explicitly calls delete on the mainWindow, effectively calling OBSBasic's destructor recursively while the destructor is still pending (blocked by the event loop used in closeBrowser()) and hence will attempt to access already deallocated memory.

PatTheMav avatar Dec 17 '25 14:12 PatTheMav