Birth: a startup item manager for macOS that shows who signed what

The four places macOS hides startup items

The README states the problem plainly: startup items are spread across at least four mechanisms, and System Settings shows them as one vague "background items" entry. User agents live in ~/Library/LaunchAgents, global agents in /Library/LaunchAgents, root daemons in /Library/LaunchDaemons, and BTM login items are the "Open at Login" apps. Only the last group gets a real UI in System Settings, and even there you get no path and no detail.

The audience is therefore narrow and specific. If you have ever opened Activity Monitor, seen a process you do not recognise, and had no way to connect it back to the plist that launched it, Birth is aimed at you. The same goes for anyone who has uninstalled an app and later found a leftover helper still running. Birth is not a general system cleaner and does not try to be one.

How Birth maps a running process back to its plist

Birth is a Swift package with three targets: BirthCore holds scanning, control and signing logic and is UI-free; BirthUI is the app itself; Birth is described in the README as a three-line main. There is no Xcode project file and no third-party dependency, which keeps the build surface small.

The scanning side reads the four sources above and renders them in one window. Each entry carries a code-signing identity checked against certificate-chain anchors, bucketed into Apple, App Store, Identified Developer, Untrusted Certificate, Ad-hoc, Unsigned or Invalid. A separate check looks for items claiming a com.apple.* identifier whose signature contradicts that claim; these get a red Masquerading badge. The README calls this the most common malware persistence disguise, and the logic is worth understanding: the badge compares the claimed name against the signing identity, nothing more.

The control side is where the permission model bites. User-level and global agents can be toggled without a password. Daemons go through the standard macOS administrator prompt on every operation. Safe removal stops the job first, moves the plist to the Trash, and keeps a backup in ~/Library/Application Support/Birth/Backups. Search accepts a name, developer, path, or a PID, so typing a PID answers which startup item spawned that process.

Installing Birth and auditing your first daemon

Birth requires macOS 14 (Sonoma) or later. The README says it is primarily developed and tested on macOS 26, and asks you to file an issue if you hit problems on earlier versions. The DMG is a universal binary and runs natively on Apple Silicon and Intel.

Download the latest Birth-x.x.x.dmg from the Releases page and drag Birth into Applications. Birth is not notarized by Apple, so the first launch will warn that the developer cannot be verified. The README gives the exact path out:

# After the first-launch warning:
# System Settings -> Privacy & Security -> click "Open Anyway" (once)

If you prefer to build it yourself, the README gives this sequence. It clones the repository, builds, and opens the resulting app bundle:

git clone https://github.com/iAmCorey/birth.git
cd birth
./scripts/make-app.sh
open dist/Birth.app

By default that builds for your machine's architecture. To produce the universal form that official DMGs ship in, pass universal as an argument:

./scripts/make-app.sh universal

The README notes that with Xcode 26 or later installed, packaging also compiles the adaptive Default/Dark app icon used by macOS 26; Command Line Tools or an older Xcode still produce a working app with the legacy static icon, but the release gate requires the adaptive icon.

Once open, the Login Apps page needs no permission at all. Browsing user agents, global agents and daemons also needs none. The first real audit is to open the Advanced view, keep the default third-party-only filter, and sort by the run-state column. Anything running with an Ad-hoc or Unsigned identity is the first thing to look at. A Homebrew cask is listed as planned, so today the DMG or a source build are the only two routes.

The permissions are the real cost of ownership

The README is unusually direct about this, and it is the strongest reason to think twice. Birth currently ships with an ad-hoc signature, which changes with every build. The consequence: after upgrading, Full Disk Access and Automation permissions must be re-granted in System Settings by toggling Birth off and back on. The README's own text is cut off mid-sentence on that point, so the full behaviour within a single version is not documented in the README.

The permission table is otherwise well thought out. Viewing the Login Apps list, browsing all four categories, and enabling or disabling user and global agents require nothing. Adding or removing login apps triggers a one-time Automation (System Events) prompt on your first change. Viewing the Login Items category needs Full Disk Access, checked once. Daemon operations need the administrator password every time, which is macOS's security model rather than a Birth choice. Missing permissions degrade gracefully: one-time setup guidance in the app, an automatic refresh when you return from System Settings, and silence afterwards.

Two other limits are stated rather than hidden. The signing badge shows identity, not integrity: Birth verifies certificate-chain anchors, and does not hash the full bundle contents, which the README assigns to Gatekeeper. And the Login Items category is read-only, because macOS offers no third-party API to toggle those items; Birth gives you a jump to System Settings instead.

Where Birth stops and a scripted approach begins

The obvious alternative is doing this by hand or with a shell script: reading the plist directories directly, calling launchctl to list and unload jobs, and inspecting signatures with codesign. That approach has no GUI, no permission prompts, and no ad-hoc-signature problem, and it works over SSH on a headless Mac. What it does not give you is the signing-identity classification, the masquerade check, or the ability to see a running process and ask which startup item spawned it without writing the join yourself.

A second alternative is to trust System Settings alone. It covers the BTM login items and nothing else in any detail, which is exactly the gap the README describes. Birth's advantage over both is that the four sources sit in one table with a shared set of columns and a remembered sort order, Finder-style.

The honest framing is that Birth is a read-mostly audit tool with a convenient toggle. If your goal is fleet-wide enforcement across many Macs, a script or a configuration management tool is the better fit, because Birth is a per-machine GUI with an administrator prompt on every daemon operation.

Licence, maintenance and what an upgrade actually costs

Birth is MIT licensed. That permits commercial use, modification and redistribution provided the copyright notice and permission notice are included; it also means there is no warranty. This is a description of the licence text, not legal advice, and if you plan to redistribute a modified build you should read the LICENSE file in the repository rather than rely on this summary.

The repository is not archived, and the last push was on 2026-08-29, the same day as the v0.2.11 release. Releases run v0.2.9 on 2026-08-08, v0.2.10 on 2026-08-14 and v0.2.11 on 2026-08-29, so the cadence over that three-week window is roughly weekly. The README describes a release gate: swift test for unit tests, then ./scripts/release-check.sh, which runs tests, a universal package build, a self-contained smoke launch and health checks, and it must pass before every release. That is a real constraint on contribution speed, and it is also the main reason to trust a release tag over a random build.

The upgrade cost is the ad-hoc signature. Every version bump means re-granting Full Disk Access and Automation by toggling Birth off and back on in System Settings. If you run Birth on a machine you rarely touch, budget for that step each time you update; if you update often, it is a recurring interruption rather than a one-time setup.

Editorial conclusion

Adopt Birth if you run macOS 14 or later and want to see which developer signed each background item before you disable it; skip it if you need a notarized, zero-friction install or an MDM-managed fleet tool, because Birth is ad-hoc signed and not notarized. Before relying on it, verify three things: that the DMG you downloaded matches the latest release tag, that you are willing to re-grant Full Disk Access and Automation after each upgrade, and that the daemon you plan to disable is not one you actually need, since removal moves the plist to the Trash with a backup under ~/Library/Application Support/Birth/Backups.

Frequently asked questions

Official sources

1. iAmCorey/birth on GitHub
2. Issues
3. License: MIT
4. README
5. Releases