Disabling startup items that run on their own

I've found a couple apps that seem to be able to launch themselves on startup, despite that they don't appear in the usual places...

- Login Items (in the Users preference pane)
- /Library/LaunchAgents
- /Library/LaunchDaemons
- /Library/StartupItems
- /System/Library/LaunchAgents
- /System/Library/LaunchDaemons
- /System/Library/StartupItems
- ~/Library/LaunchAgents
- ~/Library/LaunchDaemons
- ~/Library/StartupItems

At least some of these apps (e.g. Day One and Pauses – both from the Mac App Store) seem to be launching an item from their own internal LoginItems folders:

/Applications/Day One.app/Contents/Library/LoginItems/Day One Reminders.app
/Applications/Pauses.app/Contents/Library/LoginItems/PausesLauncher.app

As good citizens, both apps allow you to disable the launch-on-login behavior, but it's disconcerting that this behavior doesn't seem to be controllable from a system-wide preference, and I'd like a way to systematically identify/control these login items. So, the (two-part) question is:

• What is actually controlling whether/how these app-specific launch items are being activated, and
• How can I get an inventory of all these login items?

[edited for clarity 2013-03-20 11:22 PT]

Day One seems to store the login item in /var/db/launchd.db/com.apple.launchd.peruser.501/overrides.plist:

$ /usr/libexec/PlistBuddy -c 'Print _com.apple.SMLoginItemBookmarks:com.dayoneapp.dayone-agent' /var/db/launchd.db/com.apple.launchd.peruser.501/overrides.plist
book 0(UserslaurTorrents
                        Day One.apContentsLibrary
LoginItemsDay One Reminders.app $4HXh?kld ????$A????H???A?1M?$5DF7A03E-A7FB-3E80-B61D-F10CD8BF7B5D?/?0c75ae904b0f99cb3a794e7360629c822a0f4a14;00000000;0000000000000020;com.apple.app-sandbox.read-write;00000001;01000002;0000000000641712;/users/lauri/torrents/day one.app/contents/library/loginitems/day one reminders.app??????D|@l 0 ? ? ? ?  0 <???????D

Changing this to true in that same file disabled it:

<key>com.dayoneapp.dayone-agent</key>
<dict>
    <key>Disabled</key>
    <false/>
</dict>

(This is not about the user visible Login Items under the Users & Groups Systems Preferences)

The Contents/Library/LoginItems/ buried in the application bundle is what appears to be the implementation of Apple's approach to sandboxed apps.

The tip from @user495470 about the storage of the login item reference in /var/db/launchd.db/ seems to be now defunct in macOS 10.12

Apple's direction appears to be heading into the app-self-contained approach where the LaunchDaemons, LaunchAgents, and StartupItems may be off-limits in the future as Mac apps may be required to be sandboxed at some point (personal conjecture, not fact). On the other hand CFPreferences API and sending AppleEvents to launch are deprecated...

Ref:

• Adding Login Items - Apple Developer
• Table 3: Std locations for code in bundle
• App Sandbox LoginItem Sample Code

While in the past it was easy to look in the aforementioned folders for startup launch information (per Dan), this new sandboxed model, while theoretically safer operationally, hides the an app's (or Trojan's?) startup capability from all normal users and most superusers who know to look in the system directories. Finding these hidden Login Items now has become a PITA (pain in the app) with either grep'ing your way through the Applications folder or manually open app bundles looking in /Contents/Library/ for a "LoginItems" folder and it's contents. For the user level solution, I did find a tool that lists the app bundle embedded Login Items called CleanMyMac (can deactivate or activate them. Be careful, only get this app from the company. There are cracked versions available that actually carry a virus in a way very similar to how Login Items now works (irony)..)

And notice how these items, enabled or disabled, are not part of the user visible "Login Items" under the "Users & Groups" System Preferences:

If you are like me and you are working this at a code level, a consolidated guide to implementation is here (by Tim Schroeder 2013): The Launch at Login Sandbox Project