Mac login items checklist: prove each app is ready

A Mac login item passes only when four facts line up: the app preference says it should start, macOS reports the service as enabled, the process appears after a real login, and the first user-facing state is correct. Apple's Service Management documentation describes an enabled service as eligible to run. Eligibility is not proof that the app launched or applied the state you expected.

Let a utility open at login when missing its early state would make the day worse. A microphone mute app, screen-time counter, system monitor, clipboard history, sync agent, backup helper, or file shelf can earn that. A converter, color tool, screenshot editor, or one-off maintenance app usually can stay manual.

Disclosure: I build TeenyApps, including TeenyScreeny and TeenyMute. My bias is toward small native menu bar apps. The checklist below is still strict: launch at login is not a prize. It is a responsibility.

Pass four startup gates

Keep a short acceptance record: login-item setting, System Settings state, login time, first visible state, and any corrective action. That is more useful than a screenshot of one toggle.

Separate Open at Login from background access

Apple keeps both controls in System Settings, General, Login Items & Extensions. Open at Login covers apps, documents, folders, volumes, and connections that open for your user. The background list covers apps allowed to perform tasks when their main interface is not open.

A visible menu bar app and a background helper are separate trust decisions. A menu bar utility can use the main-app login service without installing a separate background agent. Do not infer that an app needs background access merely because it should open after login.

Service Management also has states beyond enabled and not registered. A service can require user approval, or macOS can report that it was not found. If an in-app toggle disagrees with System Settings, use the system state as the registration evidence and the next login as the launch evidence.

Define the first state before enabling startup

A state utility deserves automatic launch only when you can name the first state it must prove. "The icon appeared" is not enough.

TeenyScreeny's launch-at-login guide uses the live counter as the acceptance state. Its current source defaults the preference to on, compares that preference with SMAppService.mainApp.status, and reverts the saved setting when registration fails. After login, the useful proof is that the counter appears before work and then advances under a deliberate activity test.

TeenyMute's startup-mute guide has a stricter state test. The current source defaults to an unmuted launch. A muted preference requests muted state, Use Last State restores the Boolean saved on normal termination, and push-to-talk overrides the preference by starting muted. If no input device is available, startup-state application returns without changing anything. The acceptance record therefore needs the selected physical input, not just the icon color.

Keep one-off utilities manual

Not every TeenyApps-style utility needs to be present all day. A local converter, URL encoder, color picker, PDF helper, or screenshot cleanup tool may be fast enough from Spotlight, Raycast, the Dock, or the Applications folder. Starting it every morning can add a menu bar icon you only use once a week.

The test I use is: would I notice a missing minute of data or the wrong first state? If yes, open at login. If no, keep it manual. That means a screen-time counter and mic mute app can earn startup. A batch image resizer probably cannot.

This is also the cleaner privacy habit. A utility that runs only when you ask has less time to hold data, watch state, or clutter the menu bar. Always-on tools can still be private and local, but they should explain why always-on is part of the product.

Test a real login boundary

Launch-at-login registration applies to subsequent user logins. Quitting and reopening an app tests ordinary launch behavior; sleep and wake test a different lifecycle. Use log out and log in, or restart and log in, for the acceptance pass.

1. Open System Settings, General, Login Items & Extensions.
2. Record which app should open and the first state it should show.
3. Log out and log back in, or restart and complete the login.
4. Before opening work apps, confirm the menu bar item or process is present.
5. Run the smallest safe state test: activity advances the counter, or the intended input device reports the expected mute state.
6. Repeat the login once. A startup rule that passes only once is not ready.

A useful acceptance record can fit on one line. For a counter: "login completed, item visible, total loaded, five-minute activity window advanced." For a microphone control: "login completed, intended input present, startup mode applied, physical input confirmed." Record a failure at the first gate that breaks. Do not let a later green icon erase an earlier registration error.

Run the test under the user account that will use the utility. Apple's registration applies per user, and each user can have a different Open at Login list. A pass in an administrator account does not prove the same item is enabled for a separate work account.

Apple also documents a Shift-key path for temporarily preventing automatic items from opening during login. Keep that as a recovery test when one item blocks a normal session. It is not evidence that the item's saved configuration changed.

Troubleshoot the failed gate

If the in-app preference turns itself off, registration threw an error and the app corrected its saved state. Check System Settings before changing unrelated permissions.

If the item is listed but requires approval, resolve that system decision. If it is enabled but absent after login, inspect the app's own launch or crash behavior. If it launches but the first value is wrong, stay inside the product's state model: selected device, saved mode, push-to-talk override, pause state, idle rules, or another explicit setting.

For a general startup conflict, Apple recommends removing login items and adding them back one at a time after a restart. Preserve a list before you change anything. This isolates the offender without turning the test into a bulk deletion.

Common questions

Which Mac apps should open at login?

Open apps at login when they provide state you need before the first click: microphone mute, screen-time tracking, system monitoring, clipboard history, sync, backup, VPN, or a file handoff shelf. Keep occasional tools manual.

Should every menu bar app launch at login?

No. A menu bar app should launch at login only when its value depends on being present all day or on capturing state from the start of the session.

How do I know a Mac app opened correctly at login?

Verify the app preference, its enabled state in Login Items & Extensions, the running process after a real login, and the first counter, device, or control state the app should apply.

Sources checked

• TeenyScreeny facts were checked against the TeenyScreeny homepage and current local Swift source for the default preference, Service Management status comparison, registration failure handling, and live counter.
• TeenyMute facts were checked against the TeenyMute homepage and current local Swift source for Service Management sync, default startup mode, last-state storage, push-to-talk override, and unavailable-input behavior.
• Apple Support: Open items automatically when you log in on Mac.
• Apple Support: Remove login items to resolve startup problems on your Mac.
• Apple Developer Documentation: SMAppService.
• Apple Developer Documentation: SMAppService status values.
• Apple Developer Documentation: Registering a service.