LandfallDocs
Deploy

Deploy Landfall Edge to a fleet

Landfall Edge is a small macOS companion app that keeps each responder's investigation context flowing into the shared war room while they keep working in their own AI harness. This page is for whoever owns the laptops: how to push it through the deployment tooling you already run, with no per-machine setup, and how to take it off again just as cleanly.

What you deploy

Three files, all served from edge-dl.landfalls.ai, and all of them are formats your tooling already understands. Landfall ships no fleet-deployment machinery of its own.

FileWhat it is
LandfallEdge-<version>.pkgA signed, notarized, stapled distribution package. Installs /Applications/Landfall Edge.app and a system-wide LaunchAgent.
managed-login-items.mobileconfigApproves the background agent and removes the user's ability to switch it off. Without this the app installs and can be silently disabled.
pppc.mobileconfigGrants the one privacy permission Edge needs, so a managed install needs no approval click on any machine.

Requirements

  • macOS 13 or later. Landfall Edge v1 is macOS only; Windows is an intended fast-follow, not a current capability.
  • An MDM that is user-approved or supervised. Both profiles above are MDM-only payloads — no installer script can deliver them — so an unsupervised enrolment gets the app but not the guarantees.

Install it

Any of the following, whichever your fleet already uses. All four consume the same package; none of them needs anything Landfall-specific.

  • Jamf Pro — upload the .pkg and scope a policy, or push it as an InstallEnterpriseApplication command pointing at the manifest URL.
  • Kandji — a Custom App library item, install type Installer Package.
  • Microsoft Intune — macOS app (PKG).
  • Munki — import with munkiimport, or use the published AutoPkg recipe.

On a machine you can reach directly, the same package installs with the standard tool and no interactive input:

Terminal
sudo installer -pkg LandfallEdge-0.1.0.pkg -target /

Then push both .mobileconfig profiles as configuration profiles. Order does not matter, but a machine that has the package and not the profiles is a machine where a user can quietly turn the agent off — so scope them to the same group, in the same change.

Why the login-items profile is not optional

The package installs a system-wide LaunchAgent, which starts Landfall Edge in every user session at login. On macOS 13 and later that agent also appears to the user as a Login Item, announced by a “Background Items Added” notification, and it can be switched off from System Settings.

For a tool whose entire value is being already running when an incident starts, that is a real gap: one dismissed notification and one toggle, on the laptop of the responder who most needs it, with nothing anywhere reporting it. The managed-login-items.mobileconfig profile approves the agent by Team Identifier and removes the toggle. Deploy it.

What the privacy profile actually grants

One service: App Data access, so Landfall Edge can read and write AI coding-assistant configuration that lives inside other applications' data directories.

Deliberately not requested:

  • Full Disk Access. It would cover the above and a great deal more. Landfall does not need unrestricted read of a responder's laptop and does not ask for it.
  • Apple Events. Edge runs agent adapters as its own child processes; it does not script other applications.
  • Screen Recording. Not used, and worth stating plainly: macOS does not allow Screen Recording to be granted by profile at all — only denied — so any tool that needs it cannot be deployed without a per-machine click.

Verify a machine

After setup, Landfall Edge runs an end-to-end check against a synthetic incident and reports the result, so a broken install is found before a real incident rather than during one.

It distinguishes three outcomes, and the middle one is the point: a check that could not run is never reported as a check that passed. A machine whose report says partly verified has parts nobody has confirmed, and it says so rather than showing a green tick.

Remove it

The uninstaller is left at a fixed path, so your removal automation can be written once:

Terminal
sudo /usr/local/bin/landfall-edge-uninstall --json
# add --dry-run to see what it would do and change nothing

It reverses every change Landfall Edge wrote into a third-party tool's configuration, removes its own files using the package receipt as the bill of materials, and prints one line per target using four statuses:

StatusMeaning
removedLandfall Edge's change was reversed exactly.
left-in-placeA Landfall entry that somebody edited by hand, or one that belongs to the landfall CLI rather than to Edge. Never overwritten, never deleted.
not-installedNothing of Landfall's was there.
failedSomething could not be removed. This is the only status that exits non-zero.

A left-in-place is a success, not a failure. If your removal script treats any non-empty output as an error, it will flag every machine that also runs the landfall CLI. Branch on the exit code, or on --json's exitCode field.

Then remove the two configuration profiles through your MDM. The package cannot remove them, because it did not install them.

Updates

On managed machines, you control the version: re-push the newer package the same way you pushed the first one. Landfall publishes a static version manifest, a Jamf external patch source feed and an AutoPkg recipe so your existing tooling can decide when that happens.

Landfall Edge also has a built-in updater for unmanaged, personally-owned Macs. It disables itself when it detects a managed preference forcing it off, so a machine you manage does not update itself underneath you.

For your endpoint-security team

Landfall Edge is a notarized Electron application with a hardened runtime. It runs a background process that opens outbound HTTPS connections to your Landfall control plane and a local Unix socket, and — for investigators who opt into the highest-fidelity attach mode — spawns AI-harness adapter binaries as child processes.

That shape (JIT-enabled, spawns subprocesses, opens sockets) is one endpoint-detection products reasonably flag. It can be allowlisted deterministically rather than by hash: the Team Identifier and the bundle identifier ai.landfalls.edge are stable across releases, and the process tree below is the whole of it.

Process tree
launchd
└── Landfall Edge (--daemon)          ELECTRON_RUN_AS_NODE=1, headless
    │                                 outbound HTTPS to your control plane
    │                                 listens on a per-user Unix socket
    ├── Landfall Edge                 the panel (GUI), started on demand
    └── <agent adapter>               Full attach mode ONLY, one per
                                      attached session, stdio only
  • Entitlements: cs.allow-jit, cs.allow-unsigned-executable-memory, cs.disable-library-validation, network.client. Notably absent: get-task-allow, and no disable-executable-page-protection.
  • Network: outbound HTTPS and a WebSocket to your own Landfall control plane, plus edge-dl.landfalls.ai for updates on unmanaged machines. It listens on no TCP port.
  • Child processes: none at all in the Default and Minimum attach modes. The Full mode spawns the agent adapter the investigator chose, and only while a session is attached.
  • Files written: its own state directory, and marked entries in the AI harness configuration the investigator explicitly attached — each one journaled before it is written and reversed exactly on uninstall.