Under Ventura we are noticing that our software "service" is displaying under Apple Settings the "person's name" associated with the Apple Account rather than labeling the service using the name of "the service". Obviously confusing. Does anyone have a suggestion how to get a service to grab and use the service name from some plist entry in the Launch Daemon plist file? Any clues would be very welcome. Thanks.

I'm attempting to root-cause analyze issues I've been having with launch daemons controlled by launchd. My product has a single privileged LaunchDaemon running in the system domain (supposed to at least). I was looking at a client's machine that, for some reason, was running the daemon process both in the system domain and the gui/ domain for the logged in user. When I would kill both processes on the client machine, both of them would start right back up in their respective domains. The associated plist for this daemon process only exists in /Library/LaunchDaemons. My question is, how can this be possible that launchd would spin up multiple privileged daemons, but one of them running in the gui/ domain? How can this be prevented from happening? Some context/details: It was observed on the client's machine that the daemon service was previously disabled. The service was manually re-enabled using: launchctl enable system/<nameOfDaemon> sudo launchctl enable system/<nameOfDaemon> The daemon was reloaded by using: sudo launchctl load /Library/LaunchDaemons/<plist of daemon process>

I am developing a screen share app and would like to launch an agent on demand whenever i receive a request to the port on which the app listens. Based on the documentation available from Daemons &amp; Agents , i designed a plist file which looks like this, &lt;?xml version="1.0" encoding="UTF-8"?&gt; &lt;!DOCTYPE plist PUBLIC "-//Apple//DTD PLIST 1.0//EN" "http://www.apple.com/DTDs/PropertyList-1.0.dtd"&gt; &lt;plist version="1.0"&gt; &lt;dict&gt; &lt;key&gt;Label&lt;/key&gt; &lt;string&gt;com.myapp.assist-loginserver&lt;/string&gt; &lt;key&gt;LimitLoadToSessionType&lt;/key&gt; &lt;array&gt; &lt;string&gt;LoginWindow&lt;/string&gt; &lt;string&gt;Aqua&lt;/string&gt; &lt;/array&gt; &lt;key&gt;ProcessType&lt;/key&gt; &lt;string&gt;Interactive&lt;/string&gt; &lt;key&gt;ProgramArguments&lt;/key&gt; &lt;array&gt; &lt;string&gt;/Applications/My\ App\ share.app/Contents/MacOS/My\ App\ Assist&lt;/string&gt; &lt;string&gt;--args&lt;/string&gt; &lt;string&gt;--launcher&lt;/string&gt; &lt;/array&gt; &lt;key&gt;Sockets&lt;/key&gt; &lt;dict&gt; &lt;key&gt;Listeners&lt;/key&gt; &lt;dict&gt; &lt;key&gt;SockServiceName&lt;/key&gt; &lt;string&gt;50053&lt;/string&gt; &lt;/dict&gt; &lt;/dict&gt; &lt;/dict&gt; &lt;/plist&gt; However when i pass a request to the listening port '50053' , i don't see the app being launched. From the terminal , if i provide the Program Arguments separated by space , i can see app launch . So i don't think there is a problem with Program Arguments. When i look for active ports , i can see the port '50053' being monitored by launchd. sh-3.2# lsof -i:50053 COMMAND PID USER FD TYPE DEVICE SIZE/OFF NODE NAME launchd 1 root 30u IPv6 0xb9009595656d4fe7 0t0 TCP *:50053 (LISTEN) launchd 1 root 43u IPv4 0xb900959efe5cf82f 0t0 TCP *:50053 (LISTEN) when i pass in a curl request to the port , i do see a TCP Establishment , but it doesn't launch the app. I would like the app to be launched and let the app handle the socket connection (50053) till it is alive sh-3.2# lsof -i:50053 COMMAND PID USER FD TYPE DEVICE SIZE/OFF NODE NAME launchd 1 root 30u IPv6 0xb9009595656d4fe7 0t0 TCP *:50053 (LISTEN) launchd 1 root 43u IPv4 0xb900959efe5cf82f 0t0 TCP *:50053 (LISTEN) curl 15759 testuser 5u IPv4 0xb900959efe5ca2ff 0t0 TCP localhost:50054-&gt;localhost:50053 (ESTABLISHED) Any help on this will be much appreciated Thanks, Abhilash

I'm having some trouble getting a Login Item to launch at all. Both the main App and the Login Item are Sandboxed. I'm launching the Login Item with the following call: try SMAppService.loginItem(identifier: agentBundleID).register() The call does not fail in any way, and the subsequent status of the login item is "registered", but the login item does not launch. Then I do: -> launchctl list | grep myapp - 78 teamid.com.myorg.myapp.agent.debug and -> launchctl error 78 78: Function not implemented and -> launchctl list teamid.com.myorg.myapp.agent.debug { "EnableTransactions" = true; "LimitLoadToSessionType" = "Aqua"; "MachServices" = { "teamid.com.myorg.myapp.agent.debug" = mach-port-object; }; "Label" = "teamid.com.myorg.myapp.agent.debug"; "OnDemand" = true; "LastExitStatus" = 19968; "Program" = "teamid.com.myorg.myapp.agent.debug"; }; The LastExitStatus 19968 doesn't tell me a lot. Just that launch services probably is not being able to find my login item for some reason. Is there anything I can do to try and narrow this down to something I can fix? I have a different target for our DeveloperID App and Agent (same code different targets), and that combination works just fine. The plist produced is very similar.

We were using API "SMLoginItemSetEnabled" earlier to register loginItem with launchd. loginItem(helperApp) registers with launchd and on next reboot launchd service launches helperApp which in-turn launches mainApp. Our loginItem app is bundled within mainApp LoginItem path: $mainAPP.app/Contents/Library/LoginItems/helper.app But since it got depreciated in macOS 13 so we are planning to use new API's of "SMAppService" as suggested in this link https://developer.apple.com/documentation/servicemanagement/updating_helper_executables_from_earlier_versions_of_macos. But on invoking the register() API of SMAppService it returns success but fails to register with launchd service. On checking the status for our loginItem in terminal via command launchctl list it shows as 78 Also on checking launchd logs we observed errors related to our loginItem Please suggest if any other changes are need to be done. Thanks in Advance.

I have a UI App, myApp that I launch before login. The app launches when a button on the authorization plugin is clicked. I have acheived this using launchd. When I click the button, I write to a file which is in watchPaths in my launchd plist file. When the file is written to, launchd launches myApp. I am able to achieve this behaviour during logout-login. But it does not happen on lock-unlock. On clicking the button , the file is written to , but myApp is not launched. I need it achieve the same behaviour at lock-unlock too. How can I achieve this behaviour at lock-unlock?

I have an app that I would like to register a launchd agent at the login window. my plist looks like this: <?xml version="1.0" encoding="UTF-8"?> <!DOCTYPE plist PUBLIC "-//Apple//DTD PLIST 1.0//EN" "http://www.apple.com/DTDs/PropertyList-1.0.dtd"> <plist version="1.0"> <dict> <key>RunAtLoad</key> <true/> <key>LimitLoadToSessionType</key> <array> <string>LoginWindow</string> </array> <key>AssociatedBundleIdentifiers</key> <string>com.myapp</string> <key>Label</key> <string>com.myapp.login-window</string> <key>ProgramArguments</key> <array> <string>/usr/local/myapp.app/Contents/MacOS/myapp-agent</string> <string>--login-window-agent</string> </array> </dict> </plist> If I manually copy the com.myapp.loginwindow.plist to /Library/LaunchAgents and load it manually it works as I'd expect If I use SMAppService though it does not work: let service = SMAppService.agent(plistName: "com.myapp.login-window.plist") do { try service.register() } catch let error { print(error.localizedDescription) } I get: The operation couldn’t be completed. Service cannot load in requested session. That makes sense as I'm not at the login window when I run that routine. However checking service.status() (with formatting) I get LaunchAgent(com.myapp.login-window.plist) status: Enabled which would suggest that it's loaded, yet when I log out or reboot and I'm at the login window the agent is not running. Indeed the agent does not appear in launchctl list I'm not sure what else to check to see what's going on. I've tested loading LaunchAgents and LaunchDaemons in other contexts using the ServiceManagement framework and these all work as I'd expect once approved. It's just the LoginWindow agent that is having issues.

I need to know the list of all users connected live to the system. I am able to fetch the users detail using ioreg -d1 -c IORegistryEntry -a and look for IOConsoleUsers . But this doesn't provide information regarding the users connected via native screen share app of Mac. How can we get this detail via command line or using some files ? Thanks in Advance, Abhilash Vaidhya

We have a UI app for Mac which we want to keep running all the time, for all the non-admin users on the system. It looks like this can be achieved by adding a 'KeepAlive' launch agent in /Library/LaunchAgents. But since this solution adds an entry into System Preferences -&gt; Login Items -&gt; Allow in Background, any user can toggle the ON/OFF switch to stop the app from 'keeping alive'. Is there a way to restrict user from toggling the switch (unless the user enters admin credentials)?

I'm currently developing a screen-sharing app and i followed this post to setup daemons &amp;amp; agents , and i am able to screen share succesfully. In user-context , keyboard and mouse movements work fine; But during the login screen (first login or all users logged out) , i can perfectly relay the screen , but the app is not able to interact with the login window . ie Mouse clicks/keyboard actions fail in the login window. Is there a special configuration i'm missing to ensure the system trusts third party app for getting user inputs when logged out ? Request your help on this Attach LaunchAgents plist LaunchAgents

I have a swift app which uses SMJobBless with kSMDomainSystemLaunchd to install a privileged helper tool which performs some actions which require root. My app talks to it over XPC using NSXPCConnection. I embed the helper tool under Contents/Library/LaunchServices When building my app under macOS 13.2.1 with Xcode 14.2, installing the helper tool with SMJobBless no longer works. A copy of the app built on earlier macOS / Xcode does work fine. Can I use SMAppService.agent() ? The helper does not need to run when the user logs out. It only performs some actions as root when invoked over XPC and can exit afterwards. Is there some workaround to make SMJobBless work as before? If I use SMAppService.agent, where do I put the plist file? In which directory should I embed the tool executable if I use an agent? How should the plist file look like for a XPC launch agent? Can I have a working example xcode project which uses SMAppService.agent() to embed a privileged helper?

We have a launch daemon installed to /Library/LaunchDaemons which is loaded in the installer's postinstall by "launchctl load /Library/LaunchDaemons/com.company.AppName.service.plist". Since there have bin problems with the service starting on startup on ventura, we tried to install the plist-file into the bundle to /Contents/Library/LaunchDaemons, as recommended in the article "Updating helper executables from earlier versions of macOS", for installations on ventura. The problem is, that loading it in postinstall by "lauchctl load /Applications/AppName.app/Contents/Library/LaunchDaemons/com.company.AppName.service.plist" fails with "Load failed: 125: Domain does not support specified action". launchctl seems not to be prepared to handle LaunchDaemons included in bundles. So how can I load my launch daemon in postinstall?

Hello all, I am working on an application which will work as daemon for the user. With the update to Ventura I have seen that notification when daemons are installed is displayed. is there any way to add code to prevent that notification to show up? Thanks!

I'm writing a program that shouldn't be stopped automatically by the user. Is there a way to write code so that the UI of the background allowed item in the login item cannot be manipulated by the user? Any hints are appreciated.

On the systems with FileVault enabled, the LaunchDaemons and system extensions start after the first user login. But I expect that they will launch before LaunchAgents and other user services. When I use endpoint security as a LaunchDaemon, it launches after some LaunchAgents in 100% of cases. When I use endpoint security as a system extension with the flag NSEndpointSecurityEarlyBoot, it launches after some LaunchAgents in 90% of cases. This behavior looks like a system issue because the flag NSEndpointSecurityEarlyBoot should guarantee an earlier start than other services.

In macOS 13 Ventura, as soon as mac apps gets installed from packages, it shows two alerts (Login Items Added) one as "Unknown Developer" and other as with proper developer name. On click of alerts, it opens System Preferences and navigates to General -&gt; Login Items. It lists our apps under "Allow in the Background", one with "unidentified developer" and other with proper developer name. We followed all steps required with all apps. So why one app showing as "unidentified developer" and other with proper developer name? Also app with correct developer name, missing with its app icon.

I have an app that seems to be properly signed and notarized which I installed using Homebrew. Upon the first launch macOS warned that the app was downloaded from the internet and asked whether I want to proceed, to which I agreed. Subsequent launches do not show this warning. However, launchd refuses to launch its login item: 2023-01-11 10:23:16.258575 (gui/501/org.p0deje.Maccy-LaunchAtLoginHelper [16190]) <Warning>: Could not find and/or execute program specified by service: 155: Refusing to execute/trust quarantined program/file: org.p0deje.Maccy-LaunchAtLoginHelper Indeed, the com.apple.quarantine is still set on the app itself and all is contents, including this helper: $ ls -la@ /Applications/Maccy.app total 0 drwxr-xr-x@ 3 kentzo staff 96 Aug 31 14:20 . com.apple.macl 72 com.apple.provenance 11 com.apple.quarantine 67 drwxrwxr-x 84 root admin 2688 Jan 11 10:20 .. drwxr-xr-x@ 11 kentzo staff 352 Aug 31 14:29 Contents com.apple.quarantine 67 codesign and scptl seem to be happy though: $ codesign --verify -vvv /Applications/Maccy.app --prepared:/Applications/Maccy.app/Contents/Frameworks/libswiftObjectiveC.dylib --validated:/Applications/Maccy.app/Contents/Frameworks/libswiftObjectiveC.dylib --prepared:/Applications/Maccy.app/Contents/Frameworks/libswiftCoreImage.dylib --validated:/Applications/Maccy.app/Contents/Frameworks/libswiftCoreImage.dylib --prepared:/Applications/Maccy.app/Contents/Frameworks/libswiftXPC.dylib --validated:/Applications/Maccy.app/Contents/Frameworks/libswiftXPC.dylib --prepared:/Applications/Maccy.app/Contents/Frameworks/libswiftCore.dylib --validated:/Applications/Maccy.app/Contents/Frameworks/libswiftCore.dylib --prepared:/Applications/Maccy.app/Contents/Frameworks/libswiftAppKit.dylib --validated:/Applications/Maccy.app/Contents/Frameworks/libswiftAppKit.dylib --prepared:/Applications/Maccy.app/Contents/Library/LoginItems/LaunchAtLoginHelper.app --validated:/Applications/Maccy.app/Contents/Library/LoginItems/LaunchAtLoginHelper.app --prepared:/Applications/Maccy.app/Contents/XPCServices/org.sparkle-project.Downloader.xpc --validated:/Applications/Maccy.app/Contents/XPCServices/org.sparkle-project.Downloader.xpc --prepared:/Applications/Maccy.app/Contents/Frameworks/libswiftCoreGraphics.dylib --validated:/Applications/Maccy.app/Contents/Frameworks/libswiftCoreGraphics.dylib --prepared:/Applications/Maccy.app/Contents/Frameworks/libswiftMetal.dylib --validated:/Applications/Maccy.app/Contents/Frameworks/libswiftMetal.dylib --prepared:/Applications/Maccy.app/Contents/Frameworks/libswiftCoreData.dylib --validated:/Applications/Maccy.app/Contents/Frameworks/libswiftCoreData.dylib --prepared:/Applications/Maccy.app/Contents/XPCServices/org.sparkle-project.InstallerConnection.xpc --validated:/Applications/Maccy.app/Contents/XPCServices/org.sparkle-project.InstallerConnection.xpc --prepared:/Applications/Maccy.app/Contents/XPCServices/org.sparkle-project.InstallerStatus.xpc --validated:/Applications/Maccy.app/Contents/XPCServices/org.sparkle-project.InstallerStatus.xpc --prepared:/Applications/Maccy.app/Contents/XPCServices/org.sparkle-project.InstallerLauncher.xpc --validated:/Applications/Maccy.app/Contents/XPCServices/org.sparkle-project.InstallerLauncher.xpc --prepared:/Applications/Maccy.app/Contents/Frameworks/libswiftos.dylib --validated:/Applications/Maccy.app/Contents/Frameworks/libswiftos.dylib --prepared:/Applications/Maccy.app/Contents/Frameworks/libswiftDispatch.dylib --validated:/Applications/Maccy.app/Contents/Frameworks/libswiftDispatch.dylib --prepared:/Applications/Maccy.app/Contents/Frameworks/libswiftDarwin.dylib --validated:/Applications/Maccy.app/Contents/Frameworks/libswiftDarwin.dylib --prepared:/Applications/Maccy.app/Contents/Frameworks/libswiftCoreFoundation.dylib --validated:/Applications/Maccy.app/Contents/Frameworks/libswiftCoreFoundation.dylib --prepared:/Applications/Maccy.app/Contents/Frameworks/libswiftQuartzCore.dylib --validated:/Applications/Maccy.app/Contents/Frameworks/libswiftQuartzCore.dylib --prepared:/Applications/Maccy.app/Contents/Frameworks/Sparkle.framework/Versions/Current/. --validated:/Applications/Maccy.app/Contents/Frameworks/Sparkle.framework/Versions/Current/. --prepared:/Applications/Maccy.app/Contents/Frameworks/libswiftIntents.dylib --validated:/Applications/Maccy.app/Contents/Frameworks/libswiftIntents.dylib --prepared:/Applications/Maccy.app/Contents/Frameworks/libswiftIOKit.dylib --validated:/Applications/Maccy.app/Contents/Frameworks/libswiftIOKit.dylib --prepared:/Applications/Maccy.app/Contents/Frameworks/libswiftCoreLocation.dylib --validated:/Applications/Maccy.app/Contents/Frameworks/libswiftCoreLocation.dylib --prepared:/Applications/Maccy.app/Contents/Frameworks/libswiftFoundation.dylib --validated:/Applications/Maccy.app/Contents/Frameworks/libswiftFoundation.dylib /Applications/Maccy.app: valid on disk /Applications/Maccy.app: satisfies its Designated Requirement $ codesign --display -vvv /Applications/Maccy.app Executable=/Applications/Maccy.app/Contents/MacOS/Maccy Identifier=org.p0deje.Maccy Format=app bundle with Mach-O universal (x86_64 arm64) CodeDirectory v=20500 size=6460 flags=0x10000(runtime) hashes=191+7 location=embedded Hash type=sha256 size=32 CandidateCDHash sha256=fab018cde6fe6239b18e2a5a9055b9b6c0ca7ee2 CandidateCDHashFull sha256=fab018cde6fe6239b18e2a5a9055b9b6c0ca7ee2f1d34d9cb8e114a1f72b28b5 Hash choices=sha256 CMSDigest=fab018cde6fe6239b18e2a5a9055b9b6c0ca7ee2f1d34d9cb8e114a1f72b28b5 CMSDigestType=2 Launch Constraints: None CDHash=fab018cde6fe6239b18e2a5a9055b9b6c0ca7ee2 Signature size=8981 Authority=Developer ID Application: Alexey Rodionov (MN3X4648SC) Authority=Developer ID Certification Authority Authority=Apple Root CA Timestamp=Aug 31, 2022 at 2:21:06 PM Info.plist entries=29 TeamIdentifier=MN3X4648SC Runtime Version=12.3.0 Sealed Resources version=2 rules=13 files=186 Internal requirements count=1 size=208 $ spctl -a -t exec -vvv /Applications/Maccy.app /Applications/Maccy.app: accepted source=Notarized Developer ID origin=Developer ID Application: Alexey Rodionov (MN3X4648SC) Other apps with login items that I downloaded with Safari and manually moved to /Applications seem to work properly. What could be wrong with Homebrew's installation process? Tested on 13.1 with M1 processor, homebrew 3.6.15

Hi. We have an app which happens to be code signed , which in turn shows up in the login items as coming from an unidentified developer on Ventura platform.Ventura shows the same component with the same description even though checking the signature shows that it is code signed. Is there some extra step we need to do so that the OS updates the state. Any suggestion on this will be highly appreciable.

My app contains a daemon and an agent. So once it is downloaded, my deleloper ID shows on System Settings&gt;General&gt;Login Items (Allow in the Background). but even after uninstalling the app, my developer ID still on the list so it can be turned off anyway.(It is understandable.) When I turn off background item(my developer ID) and reinstall the app, the background item turned on automatically but an agent from my app failed to initialize after reinstallation. On the other hand, the daemon from my app works properly. I'm concerned that if this happen our users will have no idea why the app or the agent doesn't work even though the background item shows 'on' status. I summarized the steps and the error messages below. It can be reproduced on Ventura beta 10&amp;11. Install the app A Background Item is added with my developer ID Uninstall the app My app's background item is still in the Login Items section Turn off my app's background item. Reinstall my app. My app's background item turned on after the installation. An agent in my app is expected to load but it did not show up. Error messages found from launchd.log are as follows: 2022-10-06 11:19:06.110655 (gui/501/com...**** [32250]) : Service could not initialize: Untrusted spawn was denied for /Library/LaunchAgents/com.ahnlab.v3mac.v3tray.plist, error 0xa1 - Service cannot be launched because of BTM policy 2022-10-06 11:19:06.110667 (gui/501/com...**** [32250]) : initialization failure: 22A5365d: xpcproxy + 21413 [422][59A833C0-060A-3ADE-A0C2-74CD09766F1D]: 0xa1 2022-10-06 11:19:06.110669 (gui/501/com...**** [32250]) : Untrusted service was denied launch by BTM. Removing. com...**** is my agent in /Library/LaunchaAgents

In Macos 13 Ventura, after installing our app, it appears in Settings-&gt;General-&gt;Login Items with a line: Item from unidentified developer. I know there are other similar questions in this forums, the difference is we sign and build our code with the terminal, using a script. I am looking for a way to remove the warning and show the correct developer. We use an Apple Developer ID to sign and distribute the package from our own repositories. The code we use to sign(https://github.com/wazuh/wazuh-packages) is : function sign_binaries() { if [ -n "${KEYCHAIN}" ] &amp;&amp; [ -n "${CERT_APPLICATION_ID}" ] ; then security -v unlock-keychain -p "${KC_PASS}" "${KEYCHAIN}" &gt; /dev/null # Sign every single binary in Wazuh's installation. This also includes library files. for bin in $(find ${INSTALLATION_PATH} -exec file {} \; | grep bit | cut -d: -f1); do codesign -f --sign "${CERT_APPLICATION_ID}" --entitlements "${ENTITLEMENTS_PATH}" --deep --timestamp --options=runtime --verbose=4 "${bin}" done security -v lock-keychain "${KEYCHAIN}" &gt; /dev/null fi } function sign_pkg() { if [ -n "${KEYCHAIN}" ] &amp;&amp; [ -n "${CERT_INSTALLER_ID}" ] ; then # Unlock the keychain to use the certificate security -v unlock-keychain -p "${KC_PASS}" "${KEYCHAIN}" &gt; /dev/null # Sign the package productsign --sign "${CERT_INSTALLER_ID}" --timestamp "${DESTINATION}"/"${pkg_name}" "${DESTINATION}"/"${pkg_name}".signed mv "${DESTINATION}"/"${pkg_name}".signed "${DESTINATION}"/"${pkg_name}" security -v lock-keychain "${KEYCHAIN}" &gt; /dev/null fi } Any help is welcome. Thanks!