Set CEF main bundle path on MacOS so the engine works inside player builds - #441

The problem

On MacOS the CEF engine works in the Editor but crashes in player builds. The case discussed in #374. Every helper process dies on startup and the engine gives up:

ERROR:content/browser/gpu/gpu_process_host.cc:1005] GPU process exited unexpectedly: exit_code=5
WARNING:content/browser/gpu/gpu_process_host.cc:1447] The GPU process has crashed 1 time(s)
ERROR:content/browser/network_service_instance_impl.cc:613] Network service crashed or was terminated, restarting service.
...
FATAL:content/browser/gpu/gpu_data_manager_impl_private.cc:415] GPU process isn't usable. Goodbye.

Unity then reports It appears that the engine process has quit!, followed by EndOfStreamException on every input event. The macOS crash reports show the helpers stopping on an internal assertion (EXC_BREAKPOINT / SIGTRAP inside cef_execute_process).

The cause

CefSettings.MainBundlePath is never set. CEF documents that an empty value defaults to the top-level app bundle. In the Editor, UnityWebBrowser.Engine.Cef.app is the top-level bundle. In a build it is embedded in <Game>.app/Contents/Frameworks/, so CEF treats the Unity player as its main bundle, and every helper fails at startup.

I reproduced this without Unity by running the engine executable directly, with the same arguments UWB passes:

This is also why moving the engine outside the player's .app works around the problem, as described in this comment. The hardened runtime isn't required to trigger it: my player build was ad-hoc signed without the hardened runtime and still crashed. Code signing isn't the cause either. Re-signing the engine and the app ad hoc (inside-out) makes codesign --verify pass, but the crash stays.

The change

On MacOS, set MainBundlePath to the engine's own .app. It is resolved as ../.. from the working directory, the same base the existing frameworksPath uses (Contents/MacOS -> .app):

Windows and Linux are untouched. The engine can now stay in Contents/Frameworks/, where the existing post-processor puts it, so no changes are needed on the Unity side.

Testing

Apple M1 Max, macOS 26.6.2, Unity 6000.3.25f1. Engines built with build_cef_macosarm64.py / build_cef_macosx64.py (CEF 143.0.13).

Notes

• The original report in [Issue] Getting "Error in data loop! System.IO.EndOfStreamException: Attempted to read past the end of the stream." on Mac M3 Max. #374 (the engine quitting after closing a popup) looks like a different crash, so I haven't marked this PR as closing the issue.
• Happy to add a CHANGELOG entry if you'd like one.