Thanks a lot @eskimo. The app does not have a GUI. The main binary is command line only. Its an enterprise background app & end users don't bother to run it. It is mostly installed on the employe's mac by admins. Technically we do have a GUI, but that GUI is a separate binary(which is not the main binary) within the app package which will be spawned as a separate process. GUI to main app communication happens via application level API calls Some relevant info: The app(i.e., the main binary) registers a tray icon with bunch of controls and GUI process can be explicitly launched by the user from a tray option. There are many separate binaries in the package - two for daemons(will be spawned whenever machine comes up by copying to /Library/LaunchDaemons) and two for agents (will be spawned whenever a user logs in by copying to /Library/LaunchAgents). Plus the GUI binaries mentioned above which will be launched based on user action. One of this agents is designated as the main binary of the app in Info.plist. This copying of plist also happens in postinstall script. Now, as soon as the app is installed, launch plists are not loaded (my understanding is daemon plists are loaded when the machine is restarted next time & agent plists are loaded when users logs in next time). But we need the app to run right after installing There are two ways to solve this: launchctl load <plist path>&#9;--> To load the launch plists immediately which will bring up the process&#9;(or) open <Binary path>&#9;&#9;&#9; --> Explicitly launch desired process We used first option to immediately bring up the Daemons and second option for bringing up our agents. This second option based on open command is what failing intermittently. Just to reiterate these agents don't have any GUI except tray icon.

Thanks @Etresoft. Can you pls confirm your Beta version and Build number. Mine is 20A5384c