Outpost startet nicht

Wenn kein Fenster und keine Konsole erscheint, braucht ihr die Anwendung nicht zur Diagnose.

1. Logs öffnen

Gebt im Windows-Explorer in die Adresszeile ein:

%LOCALAPPDATA%\meinGPT Outpost\logs

Unter macOS und Linux heißt der Unterordner ebenfalls logs; wo der Datenordner dort liegt, steht unter Wo der Outpost Daten ablegt.

main-process.jsonl erfasst den Start noch vor dem Fenster. Daneben liegen outpost-core.log und Kompatibilitätslogs älterer Installationen; eine ältere Fassung endet auf .1. Kopiert den Ordner, bevor ihr neu installiert oder Dateien verändert. Die Rohlogs können Dateinamen und Pfade enthalten.

Bei migrierten oder verwalteten Installationen kann der Datenordner an einem anderen Ort liegen - unter anderem, wenn auf diesem Rechner bereits ein maschinenweiter Ordner existiert: %ProgramData%\meinGPT Outpost unter Windows. In diesem Fall verwendet der Outpost automatisch diesen Ordner statt %LOCALAPPDATA%. Ohne startende Anwendung lässt sich der sonst maßgebliche Reiter System nicht prüfen - findet ihr unter %LOCALAPPDATA%\meinGPT Outpost\logs nichts, prüft zusätzlich %ProgramData%\meinGPT Outpost\logs. Alle möglichen Speicherorte und Inhalte: Wo der Outpost Daten ablegt.

2. Diagnose-Paket ohne Fenster erstellen

Öffnet im Windows-Startmenü meinGPT Outpost - Collect diagnostics. Dieser Eintrag startet weder Fenster noch Outpost-Kern. Er schreibt den Pfad des ZIPs ins Konsolenfenster; die Datei liegt hier:

%LOCALAPPDATA%\meinGPT Outpost\diagnostics

Wie bei den Logs oben gilt das für den üblichen nutzerbezogenen Datenordner. Bei einer migrierten oder verwalteten Installation, die bereits den maschinenweiten Ordner nutzt, landet das Paket stattdessen unter %ProgramData%\meinGPT Outpost\diagnostics - schaut dort nach, wenn ihr unter %LOCALAPPDATA% nichts findet.

Den Startmenü-Eintrag legt nur das Windows-Installationsprogramm an. Unter macOS und Linux ruft ihr dieselbe Sammlung auf, indem ihr die Anwendung auf der Kommandozeile mit --collect-diagnostics startet; sie schreibt den Pfad des ZIPs auf die Standardausgabe und legt es im Unterordner diagnostics des Datenordners ab. Unter macOS ist das:

"/Applications/meinGPT Outpost.app/Contents/MacOS/meinGPT Outpost" --collect-diagnostics

Unter Linux startet ihr das heruntergeladene AppImage selbst, aus dem Ordner, in dem es liegt. Sein Dateiname trägt die Version — dafür steht das *:

./"meinGPT Outpost"-*.AppImage --collect-diagnostics

Funktioniert auch dieser Eintrag nicht, sichert die Logs und prüft zuerst die Quarantäne eurer Sicherheitssoftware.

Wenn eine Fehlermeldung statt eines leeren Bildschirms erscheint

Meldet der Start „Konsole nicht verfügbar" mit dem Hinweis, die lokale Konsole sei unerwartet beendet worden und der Outpost-Dienst laufe unabhängig davon weiter, ist das ein eigener Fall: Anzeige („Konsole") und Hintergrunddienst sind zwei getrennte Prozesse, hier ist nur die Anzeige abgestürzt. Schritt 1 und 2 oben gelten unverändert — sammelt Logs und Diagnose-Paket unabhängig vom Zustand der Konsole.

Für den laufenden Betrieb braucht ihr kein „Als Administrator ausführen"; Administratorrechte braucht nur die einmalige Installation (siehe Installationsrechte). Tritt die Meldung nur beim elevierten Start auf, gebt das dem Support zusammen mit dem Diagnose-Paket mit — das ist für uns ein eigenes Signal.

Wenn der Rechner ein Mac ist

Drei Ursachen gibt es nur unter macOS, und sie stehen vor der Liste weiter unten: bei ihnen läuft entweder nie ein Prozess — dann entsteht auch kein Logordner — oder die Anwendung liegt gar nicht mehr dort, wo sie einmal gestartet wurde.

1. Der Mac hat einen Intel-Prozessor. Es gibt genau eine macOS-Fassung, und die ist für Apple Silicon gebaut. Auf einem Intel-Mac lässt macOS sie nicht öffnen und meldet, die Anwendung werde auf diesem Mac nicht unterstützt; aus dem Terminal gestartet endet derselbe Versuch mit Bad CPU type in executable. Rosetta hilft nicht — es übersetzt in die andere Richtung. Prüft es am Rechner: Apfel-Menü → Über diesen Mac, unter Chip muss ein „Apple M…" stehen; im Terminal gibt uname -m dann arm64 aus und nicht x86_64. Nehmt sonst für diesen Outpost einen Windows- oder Linux-Rechner — die Anwendung ist auf allen drei Systemen dieselbe.

2. Die Anwendung liegt nicht im Programme-Ordner. Wird sie direkt aus dem geöffneten Disk-Image gestartet, läuft sie von einem schreibgeschützten, temporären Ort: Sobald das Image ausgeworfen wird — spätestens beim nächsten Neustart —, ist nichts mehr da, was starten könnte. Aktualisieren kann sie sich von dort ebenfalls nicht, denn dafür muss sie sich selbst überschreiben. Woran ihr es seht, wenn sie zwischendurch lief: main-process.jsonl schreibt beim Start ein Feld execPath mit dem Ort der laufenden Kopie. Steht dort nicht /Applications/meinGPT Outpost.app/…, ist sie nicht installiert. Öffnet dann das Disk-Image, zieht die Anwendung in den Programme-Ordner, werft das Image aus und startet sie von dort. Der Datenordner bleibt dabei unberührt — er liegt unter ~/Library/Application Support, nicht in der Anwendung.

3. Die Kopie stammt nicht aus dem Original-Disk-Image. Die ausgelieferte Anwendung ist mit einem Developer-ID-Zertifikat signiert, von Apple notarisiert und trägt das Ticket fest eingebettet — sie startet deshalb auch ohne Internetzugang per Doppelklick. Wird das .dmg intern jedoch ausgepackt, neu gepackt und über eine Dateiablage weitergereicht, überlebt das Programmpaket das oft nicht: Symlinks und erweiterte Attribute gehen dabei verloren, die Signatur passt nicht mehr, und macOS meldet die Anwendung als beschädigt, statt sie zu starten. Ob eine Kopie noch intakt ist, sagen dieselben zwei Befehle, die unsere Auslieferung vor jeder Veröffentlichung ausführt:

   spctl -a -vvv -t exec "/Applications/meinGPT Outpost.app"
   xcrun stapler validate "/Applications/meinGPT Outpost.app"

   Der erste muss accepted und source=Notarized Developer ID melden, der zweite The validate action worked!. Tut er das nicht, ladet das Disk-Image in MeinGPT erneut herunter und zieht die Anwendung daraus neu in den Programme-Ordner. Umgeht die Meldung nicht mit xattr -cr: das entfernt nur die Herkunftsmarkierung und verdeckt genau den Integritätsfehler, den ihr gerade gefunden habt.

Ist keine der drei die Ursache, gilt die Liste unten unverändert — Proxy, Firewall, belegte Ports, Systemzeit und ein Datenordner auf einem Netzlaufwerk verhalten sich unter macOS wie unter Windows. Lest dort %LOCALAPPDATA%\meinGPT Outpost als ~/Library/Application Support/meinGPT Outpost.

Wahrscheinliche Ursachen — in dieser Reihenfolge

1. Antivirus oder EDR: Defender, CrowdStrike und ähnliche Werkzeuge können native Node-Addons des Outposts blockieren oder data\outpost.sqlite sperren. Lasst die Quarantäne und Ereignisse vom Sicherheitsteam prüfen; nicht blind den ganzen Ordner ausschließen.
2. Proxy oder TLS-Inspection: Ein Unternehmensproxy kann den ausgehenden Tunnel am Zertifikat stoppen. Sobald das Fenster wieder öffnet, führt unter Verbindung die Prüfung aus. Bei eigener CA: Eigenes Stammzertifikat.
3. Ausgehende Firewall: Der Bridge-Host muss ausgehend erreichbar sein. Die konkrete Freigabeliste steht unter Verbindung → Netzwerkfreigaben; es sind keine eingehenden Ports nötig.
4. Lokaler Port blockiert: Der Outpost weicht automatisch auf einen freien Loopback-Port aus. Ein einzelner belegter Port reicht daher nicht; relevant sind Regeln oder Programme, die lokale Bindings insgesamt verhindern.
5. Datenordner verschoben: Verschiebt den Outpost-Datenordner nicht auf SMB, ein Netzlaufwerk oder in einen OneDrive-Ordner. SQLite und die automatische Wiederherstellung brauchen ein lokales Laufwerk. Der tatsächlich verwendete Pfad steht im Diagnose-Paket unter den Systemangaben.
6. Umgebungsvariable ungültig: Bei einer verwalteten Installation kann MEINGPT_OUTPOST_APP_DATA_DIR den Datenordner auf einen abweichenden Pfad umleiten - siehe Wo der Outpost Daten ablegt. Ein ungültiger Wert (leer, relativ, ein nicht vorhandenes Laufwerk) lässt den Speicher-Layer schon vor dem Fenster abbrechen. Prüft den tatsächlich gesetzten Wert und den unter System angezeigten Pfad.
7. Berechtigungen: Das Konto, das den Outpost startet, braucht Lese- und Schreibzugriff auf seinen tatsächlich verwendeten Datenordner.
8. Falsche Systemzeit: Eine stark abweichende Uhr kann Zertifikate, Kopplung und Tokens ungültig erscheinen lassen. Die Verbindungsprüfung meldet eine Abweichung ab zwei Minuten.
9. Ruhezustand oder Windows Update: Wurde der Rechner beim Indexieren angehalten oder neu gestartet, weckt beziehungsweise startet ihn und öffnet den Outpost erneut; der Lauf setzt nach der Wiederherstellung fort.

An den Support senden

Schickt das ZIP mit Zeitpunkt und kurzer Fehlerbeschreibung an enterprise@meingpt.com. Es enthält System- und Versionsangaben, bereinigte Konfiguration, Wiederherstellungsstatus und begrenzte Logauszüge. Es sammelt keine Dokumentdateien oder Dokumentinhalte. Da Logauszüge enthalten sind, können in der aktuellen Version jedoch Dateinamen, Pfade oder Suchtext vorkommen; prüft das ZIP nach euren Richtlinien.