2026 — Geplanter Agent auf Fern-Mac: launchd-Orchestrierung, MCP-Trigger und Mietdauer-Validierung

1. Warum geplante Agenten 2026 auf einen Fern-Mac gehören

Cursor Automations, n8n-MCP-Orchestrierung und Codex CLI remote-control machen 2026 aus „Agent zur festen Uhrzeit starten“ eine abrechenbare Last. Die Ausführung bleibt auf macOS: launchd plant nur lokale Prozesse, Seatbelt und Schlüsselbund blockieren undeclarierte Tools, und ein lokaler Mac verliert Jobs durch Ruhezustand, WLAN-Wechsel und Update-Neustarts.

Ein geplanter Agent auf einem Fern-Mac M4 liefert: ① 7×24-Verfügbarkeit mit kontrollierten Neustarts; ② niedrigeren RTT zu LLM/MCP-APIs (APAC oder US East); ③ elastische Tages-/Wochen-/Monatsmiete, um gescheiterte PoCs ohne Hardwarekauf freizugeben.

Dieser Artikel behandelt zeit-/ereignisgesteuerte Trigger und MCP-Orchestrierung, nicht git-worktree-Farmen (anderswo). OpenClaw-Gateway, Port 18789, Cold Start und Tunnel+MCP erscheinen nur als Grenzverweis — ohne Deployment-Wiederholung.

2. SSH-Bereitstellung und launchd/crnd-Umgebung: 30-Minuten-Checkliste

Nach Bereitstellung eines Fern-Mac M4 die Punkte unten in 30 Minuten abschließen, bevor der erste LaunchAgent geladen wird. SSH-Details im Hilfe-Center.

1. SSH-Schlüssellogin; uname -m liefert arm64; Zeitzone und NTP korrekt.
2. Homebrew, Node 22 (üblich für Agent-CLIs) und tmux oder screen für Troubleshooting installieren.
3. ~/agent-runs/state, ~/agent-runs/logs, ~/agent-runs/scripts anlegen.
4. API-Keys in ~/.config/agent/env (Modus 600); per EnvironmentVariables im LaunchAgent injizieren — nie im plist hardcoden.
5. Testjob per crnd schedule oder manuellem launchd-Lauf starten und Log-Schreiben auf Disk bestätigen.
6. curl zu LLM/MCP-Endpunkten von der Maschine und RTT notieren; Firewall für Webhook-Callbacks prüfen.

Danach PoC-Mietdauer wählen. Schlägt ein Schritt fehl, noch nicht auf Wochen- oder Monatsmiete wechseln.

3. LaunchAgent launchd-Topologie

Benutzerebene-Geplantaufgaben liegen in ~/Library/LaunchAgents/, geladen mit launchctl bootstrap gui/$(id -u) (Ventura+, bootstrap statt legacy load).

Typische LaunchAgent-Keys:

• StartCalendarInterval: Tag/Stunde/Minute — Crontab-Ersatz.
• KeepAlive: Neustart bei Exit; mit ThrottleInterval gegen Crash-Loops koppeln.
• StandardOutPath / StandardErrorPath: Pflicht — ohne Logs rätselt man.

<?xml version="1.0" encoding="UTF-8"?>
<!DOCTYPE plist PUBLIC "-//Apple//DTD PLIST 1.0//EN" "http://www.apple.com/DTDs/PropertyList-1.0.dtd">
<plist version="1.0"><dict>
  <key>Label</key><string>com.kvmboot.agent.codex-batch</string>
  <key>ProgramArguments</key><array>
    <string>/bin/zsh</string><string>-lc</string>
    <string>source ~/.config/agent/env && ~/agent-runs/scripts/run-codex-batch.sh</string>
  </array>
  <key>StartCalendarInterval</key><dict>
    <key>Minute</key><integer>0</integer><key>Hour</key><integer>*/1</integer>
  </dict>
  <key>ThrottleInterval</key><integer>300</integer>
  <key>StandardOutPath</key><string>/Users/runner/agent-runs/logs/codex.out.log</string>
  <key>StandardErrorPath</key><string>/Users/runner/agent-runs/logs/codex.err.log</string>
</dict></plist>

Laden: launchctl bootstrap gui/$(id -u) ~/Library/LaunchAgents/com.kvmboot.agent.codex-batch.plist. Entladen per bootout auf demselben Pfad.

4. MCP-/n8n-Webhook-Triggerkette und curated Tools

MCP-Trigger laufen typischerweise so: Agent-CLI verbindet direkt mit MCP-Server (im VPN oder SSH-Tunnel), oder n8n/Cursor Automations ruft einen Webhook auf, der Skripte auf dem Fern-Runner ausführt (wenn Approvals, Retries und Alerts nötig sind).

Sicherheitsgrenzen:

• Nur curated Tools — Datei-I/O auf Whitelist und feste APIs. Unrestricted Shell-MCP nie ins Internet.
• Eingehende Webhooks per HMAC oder Kurzzeit-Token validieren; Idempotenz-Keys in state/runs schreiben.
• Strikte Timeouts auf LLM-Calls; exponentielles Backoff, um launchd+Webhook-Doppelstürme zu vermeiden.

Mattermost+n8n+MCP-Erfahrungen 2026 zeigen Orchestrierung in n8n und Ausführung auf macOS-Runnern — kompatibel mit launchd-Direktaufrufen; wählen nach bestehender n8n-Nutzung.

5. Geplante Claude Code / Codex CLI Aufgaben — Vorlagen

Claude Code und Codex CLI unterstützen nicht-interaktive Batch-Läufe. AGENTS.md, Arbeitsverzeichnis und Env-Injection identisch halten, damit launchd dasselbe liefert wie manuelles SSH.

#!/bin/zsh
set -euo pipefail
cd ~/projects/my-repo
export CODEX_API_KEY="$(grep CODEX_API_KEY ~/.config/agent/env | cut -d= -f2-)"
/usr/local/bin/codex exec --prompt-file ~/agent-runs/prompts/nightly-review.md \
  >> ~/agent-runs/logs/codex-$(date +%Y%m%d).log 2>&1

Mit agent-reveille / crnd: reveille add "0 9 * * 1-5" -- codex exec ... zum schnellen Testen; stabilen plist als IaC exportieren.

Kombinieren mit unserem Worktree-Parallel-Workflow: geplante Jobs für Merge/Review-Batches; interaktives Coding in Worktrees gegen Verzeichnis-Locks.

6. Logs, Secrets und Speicherplanung

Langläufer-Agenten füllen state/runs, Modell-Caches und npm/pnpm-Stores schnell. Richtwerte (kein SLA): leichte Copy-Agenten halten Wochen auf 512 GB; lokales Ollama oder schwere Artefakte können 512 GB in 2–4 Wochen füllen.

• Log-Rotation — täglicher Split oder logrotate — damit eine Datei Inodes nicht erschöpft.
• Secrets nur im Schlüsselbund oder Env-Dateien mit 600; nie Klartext-Tokens in ProgramArguments.
• Bei 80 % Disk zuerst Run-Caches leeren, dann Speicher erweitern oder zweiten parallelen Runner hinzufügen.

RAM: API-only-Agenten passen oft in 16 GB; Ollama 7B+ oder paralleles Claude Code erfordert Swap-Monitoring und Speicher-Spitzen-Governance — 24 GB oder Lastverteilung.

7. Aufgabenfrequenz × Mietdauer: Entscheidungsmatrix und Migrations-Checkliste

Preise laut Tarifseite und Konsole. Ablauf: Tagesmiete-PoC (1–3 Tage, launchd + erster MCP-Job) → Wochenmiete → Monatsmiete nach zwei stabilen Wochen. PoC-Checkliste:

1. LaunchAgent lädt und überlebt Neustart.
2. Mindestens ein Webhook/MCP End-to-End-Erfolg mit idempotentem State.
3. 24 h Logs ohne ungefangenen Panic; Disk/Inode-Wachstum akzeptabel.
4. API-RTT und Fehlerrate im Team-Schwellen (APAC oder US East zur Last passend).

8. Grenze zu OpenClaw-Gateway (nur Kontrast)

OpenClaw eignet sich für Messaging-Gateways: öffentlich 18789, Tunnel+Webhook, Multi-Channel-Ingress. Der geplante Agent hier ist CLI-Batch — launchd-Trigger (kein dauerhaft offener HTTP-Port), ideal für Cron-Jobs. Beides kann einen Fern-Mac M4 mit getrennten Accounts teilen. Gateway-Deployment siehe OpenClaw-Spalte; hier nicht ausgeführt.

9. Troubleshooting-FAQ

plist lädt nicht? plutil -lint; eindeutiges Label; unter Ventura+ bootstrap, nicht load.

launchctl bootstrap I/O-Fehler? Zuerst bootout für denselben Job; plist unter LaunchAgents; Pfade ohne Leerzeichen-Fallen.

Job läuft, aber keine Logs? Parent von StandardOutPath existiert; Ausführungsuser darf schreiben.

KeepAlive-Neustart-Schleife? ThrottleInterval erhöhen; Traps vor set -e; Script darf nicht sofort exiten.

Seatbelt/Schlüsselbund blockiert CLI? Einmal interaktiv per SSH autorisieren; LaunchAgent braucht gleiches PATH und HOME wie Login-Shell.

MCP-Timeouts? Tool-Anzahl begrenzen, Timeout erhöhen, Runner näher an API-Region.

Webhook-Duplikate? Idempotenz-Keys in state/runs; Deduplizierung in n8n.

Ollama-OOM? Kleineres Modell, Concurrency begrenzen, RAM erhöhen oder zweiten Runner.

Wann zweiten parallelen Runner? Disk 80 %+ nach Cleanup, oder CPU >85 % sustained bei shardbaren Tasks.

Mindestdauer Tages-PoC? Einen vollen 24-h-Planungszyklus plus manuellen Webhook-Trigger abdecken.

Unterschied zum Worktree-Parallel-Artikel? Dieser Beitrag: wann Jobs laufen; Worktree: wo und paralleles Coding.

OpenClaw oder launchd? Messages/Gateway → OpenClaw; Cron/Batch → launchd. Kein SLA-Versprechen — per PoC-Messung validieren.