One Mac, Many Doors

"You don't run a command 'on a Mac.' You run it through a door — and each door hands you a different set of keys."

One machine, many doors

It's natural to picture a Mac as one thing with one fixed set of powers: it can do what it can do. But the same machine is reached through several very different envelopes — an interactive login at the physical screen, an SSH session, a launchd daemon, a WebUI assistant, a delegated coding agent. Each is a door into the same box, and each door hands you a different keyring.

What changes between doors

The differences are exactly the ones that matter for real work: whether you can read the login Keychain; whether there's a live GUI session that can pop an approval dialog; whether you have non-interactive sudo; whether a human is present to approve something; whether the work will survive a reboot. An SSH session has no GUI session. A launchd daemon has no login Keychain. Only the interactive login can raise a graphical prompt. Same Mac, wildly different capabilities.

Why this bites, over and over

Here's the classic failure: a step works perfectly when you run it in Terminal, so you schedule it under launchd or fire it over SSH — and it fails. Not because the command is wrong, but because the new envelope can't reach a credential the command silently depended on. The command didn't change; the door did.

The right question

So can this machine do X? is the wrong question — it has no single answer. The right question is can this envelope, on this machine, do X?, because capabilities travel with the door you came through, not with the box behind it.

Capabilities belong to the door, not the machine. The same Mac is a different set of powers depending on how you knocked.

Code

Same machine, five doors, five keyrings·python

ENVELOPES = {
    # door                login_keychain  gui_session  sudo_ni  human_present  reboot_survivable
    "interactive_login":  (True,          True,        True,    True,          False),
    "ssh_session":        (False,         False,       None,    False,         False),  # None = depends
    "launchd_daemon":     (False,         False,       True,    False,         True),
    "webui_assistant":    (False,         False,       False,   True,          False),
    "delegated_agent":    (False,         False,       None,    False,         None),
}

# 'Can this Mac read the login Keychain?' has NO single answer:
# True through the physical login, False through SSH or launchd.
# Always ask about the ENVELOPE, never just the machine.

Exercise

Pick a task you automate on a machine (a backup, a deploy, a sync). List the capabilities it silently depends on — a stored credential, a GUI prompt, sudo, surviving a reboot. Then check: does the door you run it through (cron, launchd, SSH, a CI runner) actually have all of them? Find the one gap that would bite you.

Hint

The gap is usually a credential that's easy to read when you're logged in at the screen and invisible to a headless job. 'It works when I run it by hand' is the exact symptom of a capability that lives in the interactive door and nowhere else.

One machine, many doors

What changes between doors

Why this bites, over and over

The right question

Code

External links

Exercise

Progress

Comments 0