Lander CLI
Lander is the endpoint agent’s single binary, and it is centrally managed. Once it is installed and registered, Lander takes all of its operational instructions — which MCPs to install, which tools to allow or deny, when to capture and when to restore — from the AlienGiraffe Connector. You do not run commands to mirror an MCP, change policy, or manage traffic; that all happens in the Connector web UI (see Install an approved MCP).
The commands below are the only ones you run by hand, and only at bootstrap (usually performed by your MDM) or for diagnostics. For what Lander stores on disk, see Lander Configuration.
Authentication
Section titled “Authentication”Enrollment is authenticated: the Connector derives device ownership from the identity of the person who authenticated, so a device cannot claim to belong to somebody by asserting their email address.
Lander manages this itself — there is nothing to run. The service runs in the user’s GUI session, so when it has no valid credential it opens a browser to the Connector’s sign-in page on its own, and enrolls the device as soon as the user authenticates. Neither an operator nor an MDM payload drives this; the user answers a prompt they did not have to ask for.
What the user sees: their browser opens on the Connector login page, they sign in with whichever provider the deployment is configured for — local, auth0, or workos — and then explicitly approve the request on a consent screen naming the host that is asking. An existing dashboard session is never auto-approved. Lander stores the credential at ~/.lander/credentials.json (mode 0600) and refreshes it automatically ahead of expiry; see Lander Configuration.
An unanswered prompt is not retried aggressively. Lander re-checks whether it can enroll every 15 minutes, but opens a browser at most once every 4 hours — plus once more after a reboot, since a restart means the user has just logged in and is present to answer. It never opens a browser in a non-GUI session such as an SSH login. A device that has not enrolled yet keeps serving the local proxy and writing audit logs normally.
lander auth (diagnostics and headless hosts)
Section titled “lander auth (diagnostics and headless hosts)”These exist for the cases the automatic prompt cannot cover — a headless host, an SSH session, or an operator who would rather not wait for the next prompt window — and for inspecting state.
| Command | Description |
|---|---|
lander auth login | Trigger the sign-in flow now instead of waiting for Lander to prompt. Bypasses the 4-hour back-off. |
lander auth status | Show the authenticated identity and token expiry — no network call. |
lander auth logout | Delete the local credential and revoke the refresh token. |
| Flag | Applies to | Description |
|---|---|---|
--no-browser | login | Print the sign-in URL instead of opening a browser — use this over SSH. |
--refresh | status | Refresh the access token before reporting status (makes a network call). |
--env-manager-url | all | Control-plane base URL, overriding $LANDER_ENV_MANAGER_URL. |
--state-dir | all | State directory holding credentials.json (default ~/.lander). |
A credential created this way is picked up by the running daemon within about 15 minutes; there is no need to restart the service.
Service lifecycle (bootstrap)
Section titled “Service lifecycle (bootstrap)”In a fleet these are issued by your MDM payload, not typed by a user. They install and manage the background service.
| Command | Description |
|---|---|
lander service install [--port <n>] | Install the launchd user agent (com.aliengiraffe.lander), set to run at load and restart on crash. --port sets the HTTP daemon port (default 8082). |
lander service uninstall | Stop and deregister the launchd service and remove its plist. |
lander service status | Report whether the service is installed, whether it’s running, and its PID. |
lander service install starts the long-lived daemon (lander serve), which then registers the device, keeps inventory current by watching agent config files, and applies the MCP installs and policy the Connector sends it.
Diagnostics (read-only)
Section titled “Diagnostics (read-only)”Useful when validating a single host or troubleshooting connectivity. None of these change managed state.
| Command | Description |
|---|---|
lander device status | Show device identity, registration state, and last inventory — no network calls. |
lander device register | Synchronously attempt device registration with the Connector (otherwise done in the background by the daemon). Requires an authenticated user. |
lander --version | Print the agent version. |
What you no longer run
Section titled “What you no longer run”Earlier versions exposed local commands for mirroring and inventory (lander proxy, lander restore, lander flush-logs, lander list, lander refresh). These are gone as user-facing operations. The equivalent actions are now performed by the Connector and carried out by Lander automatically:
| You used to run… | Now you… |
|---|---|
lander proxy <mcp> to mirror an MCP | Request and install the MCP in the Connector; it is observed automatically. |
lander proxy <mcp> --disable=<tools> | Set the tool allow/deny policy at approval, or in MCP Servers. |
lander restore <mcp> | Remove the MCP from the device in the Connector. |
lander list / lander refresh | View discovered agents and MCPs in Fleet → Devices and Fleet → Agents. |
lander flush-logs <mcp> | Manage endpoint log retention with your log pipeline — see Audit & Compliance. |
- Registration and inventory are idempotent and best-effort; a failed Connector call never stops local capture or audit logging.
- An un-enrolled device is not stuck: the daemon keeps re-checking every 15 minutes and enrolls on its own once the user has authenticated. There is nothing to re-run by hand.
- The daemon keeps inventory current automatically by watching agent config files — there is no manual rescan to run.
- Lander exposes no MCP tools of its own and has no inbound control surface other than the authenticated channel to the Connector.