Kommandozeile und Schlüssel

Die Fabapp-Kommandozeile ist dasselbe Projekt, das Sie im Studio bauen, nur von woanders aus gesehen. Sie ist kein eigenes Produkt und keine andere App: pull holt die Definitionsdateien in Ihren Ordner, push schickt zurück, was Sie bearbeitet haben, und dev startet die App lokal auf derselben Vorlage, mit der die Plattform veröffentlicht.

Sie kommt zusammen mit dem MCP-Server, über den Claude Code, Cursor und andere Assistenten in Ihrem Projekt lesen und schreiben.

Was Sie brauchen

• Node 20 oder neuer. Prüfen Sie mit node --version.
• Den Builder-Plan oder höher. Die Kommandozeile ist ab Builder freigeschaltet. Wenn Ihr Plan sie noch nicht enthält, zeigt der Bildschirm Schlüssel und CLI, was sich ändert, und führt direkt zum Abschluss.

Mehr nicht. Das Werkzeug hat keine einzige Abhängigkeit: es hält eine Zugangsberechtigung und spricht mit Ihrem Konto, und jedes Paket im Graphen könnte beides erreichen.

Diesen Rechner autorisieren

Sie erstellen nie von Hand einen Schlüssel. Das übernimmt der Anmeldebefehl:

npx @fabappai/cli login

Er öffnet den Browser auf einer Fabapp-Seite mit einem kurzen Code. Sie prüfen, ob der Code auf dem Bildschirm derselbe ist wie im Terminal, autorisieren, und der Rechner ist verbunden. Auf einem Server oder in CI, ohne Browser, nutzen Sie --no-open und öffnen die Adresse selbst.

Das ist der Geräte-Ablauf, und es gibt ihn aus einem sehr konkreten Grund: ein Schlüssel, den man kopiert und einfügt, wandert durch Orte, durch die Schlüssel nicht wandern sollten, etwa die Shell-Historie, einen Chat-Kanal oder eine Konfigurationsdatei, die in einem Repository landet. Hier entsteht der Schlüssel in Ihrem Rechner und wird nie angezeigt.

Wo die Zugangsberechtigung liegt

Im Schlüsselbund des Betriebssystems. Hat der Rechner keinen, landet sie in einer Datei mit 0600, und der Befehl sagt das. Ein Werkzeug, das stillschweigend den schlechteren Ort wählt, bringt Ihnen bei, es sei immer sicher.

Lese- oder Schreibrecht

Standardmäßig fragt die Anmeldung nach Lesen und Schreiben. Für einen Rechner, der nur nachsehen muss, fragen Sie weniger:

npx @fabappai/cli login --scopes "read"

Eine Berechtigung nur zum Lesen sieht die Schreibbefehle gar nicht, weder im Terminal noch im MCP-Server. Eine Operation anzukündigen, die mit 403 antwortet, ist schlimmer, als sie nicht anzukündigen: der Assistent versucht es, scheitert und versucht es erneut mit anderen Argumenten, weil die Ablehnung wie ein Problem der Anfrage aussieht und nicht wie eines der Berechtigung.

Das erste Projekt auf der Festplatte

Wenn das Projekt noch nicht existiert, fangen Sie gleich im Terminal an:

npx @fabappai/cli create "Meine App"

Das legt das Projekt und seinen ersten Screen an und verknüpft den aktuellen Ordner damit. Das war der letzte Schritt, der nur im Browser ging. Wenn das Projekt schon existiert, verknüpfen Sie es über die id:

npx @fabappai/cli link <projekt-id>
npx @fabappai/cli pull

link bindet den aktuellen Ordner an ein Projekt und prüft Ihren Zugriff, bevor irgendetwas geschrieben wird. pull holt die Definitionsdateien: fab.schema.json (die Entitäten und ihre Felder), fab.automations.json, fab.settings.json, fab.connectors.json und die fab.config.json jedes Bildschirms.

Bearbeiten, und zurückschicken:

npx @fabappai/cli push

Lokal laufen lassen und veröffentlichen

npx @fabappai/cli dev

Beim ersten Lauf lädt dev die App herunter, baut einen Arbeitsbereich in .fabapp/workspace mit derselben Vorlage auf, mit der die Plattform veröffentlicht, installiert die Abhängigkeiten und startet Vite. Danach wird wiederverwendet, was schon da ist. --app <screen> wählt den Screen, wenn das Projekt mehrere hat, --port ändert den Port.

Bearbeiten Sie, was unter src/ liegt, sehen Sie es im Browser an, und veröffentlichen Sie:

npx @fabappai/cli deploy

deploy tut zwei Dinge, in dieser Reihenfolge: Es lädt hoch, was Sie geändert haben, und veröffentlicht erst dann. Die Reihenfolge ist wichtig. Vor dem Hochladen zu veröffentlichen würde den Stand des Servers veröffentlichen, der Befehl sähe erfolgreich aus, und Ihre Arbeit bliebe zurück. Zum Hochladen ohne Veröffentlichen, um vorher im Studio zu prüfen, --no-publish.

Bibliotheken und Plugins

Eine Bibliothek zu installieren funktioniert wie erwartet: npm install <Paket> in .fabapp/workspace, und deploy nimmt die Pakete mit, die Sie seit dem Aufbau des Arbeitsbereichs hinzugefügt haben. Jedes Paket, das im Browser läuft, ist geeignet.

Drei Dinge bleiben außen vor, und deploy sagt es vor dem Hochladen:

• Die Version der Plattform-Pakete. React, Vite, Tailwind und die Radix-Komponenten kommen immer in der Version der Plattform, weil das SDK und die fertigen Komponenten darauf aufbauen. Eine andere Version hier ändert nichts an der veröffentlichten App.
• Die Build-Konfiguration. vite.config.ts, index.html und tsconfig gehören der Plattform und werden bei jeder Veröffentlichung zurückgesetzt. Eine postcss.config.js, eine tailwind.config.js oder eine @plugin-Zeile in einer CSS-Datei laufen im Build nicht.
• Dateien, die kein Text sind. Der Code der App ist UTF-8-Text, auf dem Server wie im Build. Ein Bild, eine Schrift oder eine Audiodatei in public/ bleibt zu Hause, und deploy nennt sie; laden Sie sie im Studio hoch (Marke oder der Speicher der App) und verweisen Sie per URL darauf. Ein Vektorlogo kann als .svg im Code bleiben.
• Pakete, die nur auf einem Server funktionieren, etwa Datenbanktreiber oder Bibliotheken, die einen geheimen Schlüssel brauchen. Die App läuft im Browser der Besucher; dieser Code gehört in eine Backend-Funktion.

Build-Plugins kommen aus einer Liste. Ein Plugin führt Code im Build aus, deshalb schaltet die Plattform nur die ein, die sie geprüft hat: für Tailwind @tailwindcss/typography (lange Texte), tailwind-scrollbar, tailwindcss-safe-area (die Aussparung des Handys) und tailwindcss-motion (Animationen); für Vite vite-plugin-svgr (SVG als Komponente), vite-plugin-node-polyfills, @mdx-js/rollup (Seiten in MDX), vite-plugin-wasm und vite-plugin-glsl. Um eines einzuschalten, genügt es, das Paket zu installieren. Die Plattform registriert das Plugin mit ihrer eigenen Konfiguration, und dev macht auf Ihrem Rechner dasselbe: Was Sie lokal sehen, geht so auch online.

Was sie absichtlich nicht tut

Sie löscht nicht. Weder bei pull noch bei deploy. Eine Datei, die aus Ihrem Ordner verschwunden ist, wird gemeldet, nie aus der App entfernt. Ihre Kopie kann gegenüber dem Server veraltet sein (die KI könnte die App inzwischen im Studio bearbeitet haben), und dort wegen einer Abwesenheit hier zu löschen zerstört Arbeit, um deren Verwaltung uns niemand gebeten hat.

Sie überschreibt nicht, was Sie bearbeitet haben. dev baut den Arbeitsbereich einmal auf; bei späteren Läufen vergleicht es und warnt, wenn die Vorlage sich geändert hat, statt darüberzugehen. Das Neuaufbauen ist Ihre Entscheidung (--reset), und es sagt Ihnen, dass dabei Ihre Änderungen verloren gehen.

Sie sendet nicht, was nicht Ihnen gehört. deploy schickt nur, was Sie geändert haben. Die Komponenten der Plattform, das SDK und das Gerüst der App bleiben, wo sie sind.

Sie hält keine Integrations-Zugangsdaten. fab.connectors.json und fab.integrations.json sind nur lesbar: sie sagen, was das Projekt verbunden hat, damit ein Assistent weiß, dass es existiert und welche Operationen er rufen kann, und nie die Zugangsdaten selbst. Verbinden und Erneuern passiert auf der Plattform.

Mit Claude Code und anderen Assistenten

Der MCP-Server nutzt die Zugangsberechtigung, die login bereits abgelegt hat. Er fragt nie nach einem Geheimnis und zeigt nie eines.

{ "mcpServers": { "fabapp": { "command": "npx", "args": ["-y", "@fabappai/cli", "mcp"] } } }

Dieser Block passt für die meisten Clients. Was sich unterscheidet, ist der Ort:

Der Befehl ist unser Teil und ändert sich nicht. Der Ort ist die Entscheidung des jeweiligen Clients und wandert von Version zu Version: Wenn diese Tabelle der Dokumentation Ihres Clients widerspricht, hat die Dokumentation recht.

Das wichtigste Werkzeug ist fabapp_read_definition: ohne das Schema zur Hand antwortet eine falsche Modell-ID mit 404 und ein erfundenes Feld mit 422. Es ist das Erste, was ein Agent aufrufen sollte.

Was der Assistent sieht, hängt von der erteilten Berechtigung ab: Eine Nur-Lese-Credential bekommt die Schreibwerkzeuge nicht. Und fabapp_write_definition weigert sich zu laufen, bevor fabapp_docs im selben Gespräch aufgerufen wurde, denn ein Schema ohne den Vertrag erfindet Feldtypen und Zugriffsregeln, und beides scheitert lautlos.

Verbundene Rechner sehen und widerrufen

Öffnen Sie im Panel Profil und gehen Sie zu Schlüssel und CLI. Der Bildschirm listet jeden autorisierten Rechner mit dem Namen, den er gemeldet hat, der erhaltenen Berechtigung und der letzten Nutzung.

Der Widerruf wirkt sofort und serverweit: der widerrufene Rechner hört beim nächsten Aufruf auf zu funktionieren, auch wenn die Zugangsberechtigung noch auf seiner Festplatte liegt. Umgekehrt gilt das nicht: logout auf einem Rechner vergisst die Berechtigung dort, und sie bleibt auf dem Server gültig, bis sie hier widerrufen wird. Wenn ein Notebook verschwindet, klärt das dieser Bildschirm, nicht logout.

Wenn etwas nicht funktioniert

„Ihr Plan enthält die Kommandozeile nicht.“ Die Anmeldung stellt erst ab Builder eine Berechtigung aus. Der Bildschirm Schlüssel und CLI nennt den nötigen Plan.

Der Code im Browser stimmt nicht mit dem im Terminal überein. Autorisieren Sie nicht. Schließen Sie die Seite und führen Sie login erneut aus: beide Codes stammen aus derselben Anfrage und weichen nur ab, wenn Sie auf eine Autorisierung schauen, die nicht Ihre ist.

push beschwert sich über eine Datei, die die App nicht überschreiben kann. Es sagt, welche. Das ist besser, als mit einer 200 zu speichern und nichts zu ändern.

Eine andere API. FABAPP_API_URL ändert die Basisadresse, standardmäßig https://api.fabapp.ai.