How to figure out how a process auto started itself after login?

Question

(I added an Update in the end.)

My related questions:

How to delete hidden login iterms from backgrounditems.btm?

A launchd job without plist file, how does that work and how to find what job triggers it?

Even though the above questions are related, but they are not the same to this question.

I am running MacOS Big Sur.

I found out there were many apps downloaded online will auto start themselves somehow. I am having really a hard time to trace how they auto started.

Take an example, com.xunlei.Thunder.ThunderHelper is always started automatically after the system starts.

So far, I found out there were two things which are related to this process autostart.

One is from launchd job (no .plist file):

$ launchctl list | grep -i thunder
405 0   com.xunlei.Thunder.ThunderHelper

$ launchctl print gui/$(id -u)/com.xunlei.Thunder.ThunderHelper
...
    path = (submitted by otherbsd.330)
    program identifier = com.xunlei.Thunder.ThunderHelper
    parent bundle identifier = com.xunlei.Thunder
...

One is a hidden login iterm from $HOME/Library/Application Support/com.apple.backgroundtaskmanagementagent/backgrounditems.btm file. NOTE: this login iterm is NOT shown in System Preferences. I found it by using a python script mentioned in my another question in detail python3 ./bgiparser.py -f backgrounditems.btm -c.

I do NOT find anything related to thunder process in the following directories:

/Library/StartupItems
/System/Library/StartupItems
~/Library/LaunchAgents/
/Library/LaunchAgents
/Library/LaunchDaemons
/System/Library/LaunchAgents
/System/Library/LaunchDaemons

I don't start thunder app by myself.

NOW, in order to stop it auto starts, I did the following

launchctl stop com.xunlei.Thunder.ThunderHelper
launchctl remove com.xunlei.Thunder.ThunderHelper
kill -9 405
rm "$HOME/Library/Application Support/com.apple.backgroundtaskmanagementagent/backgrounditems.btm"

Note again, I don't start thunder app by myself. Now, I shutdown the MacOS system and unplug the power cable, plug the power cabe, start MacOS system.

Magically, the thunder helper app starts it automatically again. It created a running launchd job again. It created a hidden login iterm again in a new backgrounditems.btm file.

I am very confused and how does it do this?

If I open the app manually and then it creates laucnhd job and login iterm, I am fine with it. BUT I don't start the app at all. I have removed the login iterm file. I have stopped its related process.

Can anyone help me finding how this program auto starts itself?

Thank you very much.

PS:

I know there are the following file and directory:

/Applications/Thunder.app/Contents/Library/LaunchServices/com.xunlei.Thunder.HelperTool

/Applications/Thunder.app/Contents/Library/LoginItems/ThunderHelper.app/

I know I could remove them (although I haven't tried it). But I want to figure out how they are started automatically instead of removing them. Cheers.

Update

I found a scary truth on this issue.

After killing/remove any running thunder processes (inlcuding rm backgrounditems.btm).

I moved Thunder.app to other directory with the following command:

$ mkdir -p $HOME/tmp/thunder_tmp/
$ mv /Applications/Thunder.app $HOME/tmp/thunder_tmp/

And then restart macos system. The most weird thing happened. Thunder helper app started automatically from the new path and login iterms with the new path added to new backgrounditems.btm file:

# Part of decoded backgrounditems.btm file:
{
    "name": "ThunderHelper.app",
    "path": "/Users/myuser/tmp/thunder_tmp/Thunder.app/Contents/Library/LoginItems/ThunderHelper.app"
},

It seems MacOS searches my entire harddrive to find all helper app and starts them automatically and added them as a hidden iterm to login iterms automatically too. (might not be true)

If this is true, it will be very scary!

How can I stop MacOS doing this scary thing? Why does it search my entire drive everytime at startup and try to find a helper app to start and add to login iterms too? It's really unbelievable.

Answer 1

This is not actually scary - it is intended, well defined and documented behavior.

Applications on macOS can come with a helper application that is run in the background. The helper app is stored within the application bundle of the main app and managed through the Service Management framework.

When you add an app to a macOS computer, the system will look into the application bundle to determine how this app relates to the system. In particular things such as:

• which types of files can this program open
• which icon should be displayed
• does this program require a background helper application

As you can install applications in any folder on a Mac, this detection and inspection happens everywhere. In particular, you do not have to install apps in the /Applications folder. It does not involve the system "searching the entire hard drive", as application bundles are already specially marked. When an application bundle is added to the file system (or moved around), the system knows about it and keeps note of the above mentioned information.

Registering helper applications by including them in the application bundle is actually the recommended method for apps that are sandboxed (i.e. for example coming from the Mac App Store), as these apps are not allowed themselves to create files outside the sandbox.

If the application does not itself include an option to disable the helper application, it is because the app developer has decided that their application cannot function with the helper. The correct way to uninstall the helper application is to uninstall the main app.

In order to manually inactivate the login item, the least "aggressive" method is to change the Info.plist file inside the application bundle. Using the Property List Editor find the key SMLoginItemSetEnabled and change the associated boolean value to false.

You could also be more aggressive and manually delete the contents of the <app>.bundle/Contents/Library/LoginItems folder.

In any case, you risk the app itself not working - and you will have to be wary of application updates that reverse this change.