Cindy: Open-Source-Agent für Desktop und Handy – was bleibt wirklich lokal?

Was ist Cindy?

Cindy ist eine gemeinsame Arbeitsoberfläche für Agenten, Projektdateien, Browser, wiederverwendbare Skills und verbundene Werkzeuge. Die aktuelle README nennt Claude Code, Codex und Pi als Harnesses. Ein Harness organisiert Modellaufrufe, Kontext und Werkzeugausführung. Das Sprachmodell ist eine separate Wahl; nicht jede Kombination aus Harness, Provider und Autorisierung ist automatisch verfügbar.

Der mögliche Nutzen: Du verwaltest Aufgaben und Ergebnisse an einem Ort, statt Kontext zwischen verschiedenen Agentenoberflächen zu kopieren. Beim Harnesswechsel wird Enginekontext übergeben oder neu aufgebaut. Cindy macht daraus keine identischen internen Agentenzustände. Das passt zur breiteren Entwicklung zum Universal-Work-Agent, ist aber kein Nachweis besserer Arbeitsergebnisse.

Merkmal	Einordnung
Öffentlicher Code	Desktop- und Mobilclients samt gemeinsamen Paketen, nicht der Backenddienst
Stack	TypeScript, Electron auf dem Desktop, Expo/React Native mobil
Lizenz	Grundsätzlich Apache-2.0; gesonderte Materialien und Fremdkomponenten behalten eigene Bedingungen
Stabile Desktopversion	v0.1.115 vom 23.10.2026
GitHub-Reichweite	Rund 7.700 Stars im Repository-Snapshot vom 28.10.2026, kein Qualitätsbeleg

Grundlage ist eine Dokumenten- und statische Quellcodeanalyse am main-Commit 2ef024d7, ergänzt um ausgewählte Releasevergleiche. Abrufstand: 28.10.2026. Es gab keine Installation, Anmeldung, Agentenläufe oder Netzwerkaufzeichnung. Aktuelle Dokumentation, Desktoprelease, Betas und mobile Appstände sind getrennte Belege; gelesener Quellcode beweist nicht die Zusammensetzung ausgelieferter Apps.

Wie startest du lokal, und was bedeutet „lokal“?

Der dokumentierte Einstieg beginnt beim offiziellen Download, nicht beim Sourcebuild:

Plattform	Öffentliches Angebot	Wichtige Grenze
macOS	Desktopapp für Apple Silicon und Intel	Nicht mit der iOS-App auf einem Mac verwechseln
Windows	Desktopapp für x64	Kein pauschales ARM-Versprechen
Linux	x64-DEB sowie Arch-/Omarchy-Anleitung	Sandbox, Keyring und Sitzungsdienste beachten
iPhone/iPad	App-Store-App	Steuerungsoberfläche für erreichbare Computer
Android	Offizielles APK, zusätzlich deutsches Play-Listing	Mobile Updatewege separat betrachten

Die Plattformangaben stammen aus der Downloadseite, der releasegebundenen Linux-Anleitung und den deutschen Apple- und Google-Listings. Sie belegen das Angebot, keinen erfolgreichen Installationstest.

Für einen kontrollierten Anfang überspringst du auf dem Desktop die Anmeldung über „Skip Sign-In“, wählst einen unterstützten Harness und konfigurierst bewusst den Modellanbieter. Beginne mit synthetischen Dateien in einem leeren Arbeitsverzeichnis und begrenzten Rechten. Das Verzeichnis allein ist keine Betriebssystem-Sandbox. Remotezugriff und Cloud-Begleiter kommen erst nach einer separaten Entscheidung hinzu.

Entscheidend ist die Trennung der Betriebsmodi:

Betriebsmodus	Was kann lokal bleiben?	Welche externe Abhängigkeit bleibt?
Ohne Cindy-Konto, Cloudmodell	Agentenausführung und Projektverzeichnis	Ausgewählter Kontext geht an den Modellanbieter
Ohne Cindy-Konto, lokales Modell	Zusätzlich die Inferenz am lokalen Endpoint	Kein pauschaler Nachweis netzlosen Clientbetriebs
Mit Konto, eigener Provider	Lokale Ausführung und eigene Modellroute	Cindy-Kontodienste und gegebenenfalls Remote-/Syncdienste
Zugriff vom Handy	Ausführung auf dem erreichbaren Computer	Kontodienst und geräteübergreifender Transport
Cloud-Begleiter	Ausführung und vollständige Laufprotokolle als Primärzustand auf dem Hauptrechner	Gesprächsschicht, Memory, eigene Skilltexte und Anhänge in Cindy-Diensten

Die Grenzen ergeben sich aus README, Privacy Policy und Cloud-Begleiter-Regeln. Eigene API-Schlüssel, kurz BYOK, ändern die Route und Abrechnung, nicht automatisch den Ausführungsort des Modells. Lokale Modelle bezeichnet die Website ausdrücklich als Beta; ihre Nutzbarkeit hängt von Hardware, Modell und Runtime ab.

Was passiert beim Zugriff vom Handy?

Für Remotezugriff müssen die beteiligten Geräte laut README mit demselben Konto angemeldet und der ausführende Computer online sowie passend freigeschaltet sein. Das Teilen eines Modellproviders braucht dessen eigene Remote-Freigabe; die vollständige Desktopsteuerung zusätzliche Berechtigungen.

Die mobile App wird damit zur Bedien- und Freigabeoberfläche, nicht zum Beleg für On-Device-Inferenz. Ist dein Laptop ausgeschaltet, setzt das Telefon seine Arbeit nicht automatisch in einer Cloudmaschine fort. Bei Cloud-Begleitern beschreibt die Dokumentation einen bewusst auszulösenden Wechsel auf einen anderen geeigneten Computer, keine automatische Cloudfortsetzung.

Auch der Transport ist nicht mit „alles direkt“ erledigt. Die Verbindungsdokumentation beschreibt Signalisierung über Device Link, direkte beziehungsweise TURN-vermittelte Verbindungen und Objektspeicher-Fallbacks für Dateiübertragungen. Das ist kein vollständiger Festplattensync, aber ebenso wenig ein genereller Nachweis ausschließlich direkter oder durchgehend Ende-zu-Ende-verschlüsselter Datenwege. Lokale Caches auf dem Telefon sind ebenfalls möglich.

Für unterwegs gilt daher dieselbe Grenze wie beim AI-Coding vom Handy: Eine erreichbare Freigabetaste ersetzt keinen gründlichen Review.

Welche Daten synchronisieren Cloud-Begleiter?

Cloud-Begleiter sind eine zusätzliche Speicherebene, nicht bloß ein anderer Name für Remote-Dateizugriff. Die Produktregeln zur Datenzuordnung unterscheiden:

• In die Cloud gelangen Profil, SOUL-/USER-Angaben, sichtbare Einzelgespräche, Memory-Dateien und eigene SKILL.md-Texte. Fähigkeitsreferenzen und Modellpräferenzen bilden eine weitere Konfigurationsebene.
• Auf dem Hauptrechner liegen Arbeitsverzeichnisse, Modellverbindungen, Zugangsdaten und vollständige Tool-/Laufprotokolle als Primärzustand. MCP-Konfigurationen und Credentials werden nicht als Companion-Konfigurationspaket mitgenommen.
• Nutzeranhänge sowie bestimmte in Antworten referenzierte Ergebnisdateien und erzeugte Medien werden über Anhangskanäle hochgeladen.

Gerade der letzte Punkt verhindert die bequeme Aussage, sämtliche Projektdateien blieben exklusiv lokal. Dateityp- und Pfadfilter begrenzen den speziellen Upload von Antwortartefakten. Sie sind keine systemweite Sperre gegen die Übertragung von Code oder Geheimnissen über Modellkontext, Anhänge oder andere Werkzeuge.

Weitere Wege beschreibt die Privacy Policy, Abschnitte II.3–6: Direkte Providerverbindungen können ohne XD AI Gateway laufen; Gatewayanfragen können Kontext über XD weiterleiten. Integrationen können OAuth-Broker verwenden. Die Policy sieht außerdem Cloud-Konvertierung bestimmter Dokumentformate vor. Ein aktiver Standardpfad dafür wurde in der statischen Prüfung nicht bestätigt; unmittelbare Löschung nach Konvertierung bleibt Anbieterangabe.

Was erfassen Analytics, Heartbeat und Diagnose?

Diese Kanäle besitzen unterschiedliche Schalter. Die README zur Telemetrie nennt TapDB in offiziellen Builds: Gerätekennungen, System-/Appversion sowie Start- und Aktivitätsereignisse, nach Anmeldung mit Konto-ID verknüpft. Aggregierte Auswertung macht die Erfassung nicht anonym. Die geprüften Cindy-Aufrufe belegen weder einen Keylogger noch einen Chat-Leak; daraus folgt aber keine Aussage über andere Übertragungswege.

Auf dem Desktop liegt der Schalter unter Settings → About → Usage statistics, mobil unter Usage statistics in Settings. Die Statistikpräferenz ist standardmäßig an, davor liegt eine technische Privacy-Zustimmungsschranke. Policyannahme und Altbestandsmigration können diese setzen. Desktop Local Mode schließt das TapDB-Gate.

Mobil stoppt das Ausschalten Cindy-ausgelöste Reports und entkoppelt das Konto. Ein bereits gestartetes natives SDK lässt sich laut Adaptercode nicht entinitialisieren. Deshalb die App anschließend vollständig beenden und neu starten, damit es nicht erneut initialisiert wird.

Welche mobile SSO-Ausnahme bleibt?

Der untersuchte Code enthält einen bedingten Sonderpfad: Enterprise-SSO umgeht die Policyannahme. Fehlt ein gespeicherter Consentdatensatz, kann die beim Neustart wiederhergestellte Anmeldung eine Migration auslösen, die consent: true schreibt. Installationsalter und ursprünglicher Anmeldeweg werden dabei nicht geprüft. Mit eingeschalteter Statistik, TapDB-Konfiguration und verfügbarem Native-Modul kann danach Reporting initialisiert werden.

Belegt wird die Kette durch SSO-Einstieg, Loginwiederherstellung und Consentmigration. Die Kette ist auch im Mobilequellcode am Desktop-Release-Tag v0.1.115 nachvollziehbar. Das belegt weder die Bytegleichheit noch das Netzwerkverhalten der aktuellen iOS- oder Android-Store-App. Die README-Warnung dokumentiert den Zustand, sie behebt ihn nicht.

Ein expliziter Opt-out, ein vorhandener negativer Zustimmungsdatensatz oder fehlende SDK-Konfiguration verhindern diesen beschriebenen Start. Das ist ein statischer Kontrollflussbefund, keine gemessene Übertragung eines aktuellen Store-Binaries und kein Rechtsverstoßnachweis.

Warum stoppen eigene Schlüssel den Heartbeat nicht?

Der Desktop-Heartbeatcode prüft angemeldeten Cloudmodus, nicht BYOK, lokalen Modellprovider oder Statistikschalter. Ohne Anmeldung im lokalen Modus sendet dieser Pfad keine Cloudheartbeats. Wer angemeldet bleibt, ist nicht allein durch eigene Schlüssel oder lokale Inferenz ausgenommen. Die pauschalere BYOK-Ausnahme in der Policy ist durch dieses Gate nicht gedeckt.

Diagnoseuploads bleiben nochmals separat: Native Desktop-Crashdumps bleiben lokal; Logs können manuell oder über einen gesonderten, standardmäßig ausgeschalteten automatischen Crash-Logupload übertragen werden. „Analytics aus“ bedeutet deshalb nicht „sämtliche Netzwerkpfade aus“.

Reicht Open Source für vollständiges Selfhosting?

Nein. Die README zum Repositoryumfang schließt den Backenddienst ausdrücklich aus. Ein Clientclone liefert keine vollständig selbst hostbare Entsprechung des Cindy-Cloudsystems. Daraus folgt nicht, dass jede Backendkomponente nachgewiesen proprietär wäre.

Team und Enterprise stehen im öffentlichen Angebot auf Warteliste, einschließlich eines eigenen oder verwalteten Enterprise-Gateways. Ein Gateway ist nicht automatisch der gesamte Backendstack. Auch Kosten gehören getrennt: Der Client ist kostenlos, Providergebühren und Limits gelten weiter, Cindy-Modellservice ist separat bezahlt. Lokale Inferenz benötigt eigene Hardware und Betrieb.

Für Teams ist zudem global kein EU-Hostingbeleg. Die Cloud-Begleiter-Regeln beschreiben regionale Trennung von Companiondaten. Die umfassendere Privacy Policy nennt XD Entertainment Pte. Ltd. in Singapur sowie mögliche Drittlandtransfers einschließlich China und Schutzmaßnahmen im EWR-Anhang. Unterschiedliche Geltungsbereiche ergeben keine allgemeine EU-only-Zusage.

Vor vertraulichen Teamdaten musst du Providerroute, Syncumfang, Verträge, Aufbewahrung, Löschung und Transfers konkret klären. Der technische Consentbegriff ist dabei keine juristische Freigabe: Die Anbieterpolicy nennt für TapSDK berechtigte Interessen, nicht pauschal Einwilligung.

Welche Einschränkungen bleiben ungeprüft?

Die Analyse bestätigt Dokumentations- und Codegrenzen, nicht mobile Zuverlässigkeit, Agentenqualität oder serverseitige Löschung. Ohne laufende App bleiben tatsächliche Netzwerkpayloads und ausgelieferte SDK-Konfigurationen offen. Es handelt sich weder um ein Sicherheitsaudit noch um Rechtsberatung.

Ein externer Hands-on von Mehdi Rahmani vom 05.08.2026 berichtet über einen Linux-Container-Sourcebuild am Commit 6238a82c: Ein Codex-Dateifix gelang, daneben traten Setup-, Renderer- und Sandboxprobleme auf. Das ist historische, umgebungsspezifische Erfahrung, kein Beleg gegen heutige Installer und keine Empfehlung, Schutzmechanismen abzuschalten. Eine breite unabhängige aktuelle Testbasis liegt dieser Einordnung nicht zugrunde.

Wie vergleichst du lokalen und geräteübergreifenden Betrieb?

Ein sinnvoller Prüfplan beginnt klein. Der folgende Vergleich wurde nicht ausgeführt; es gibt keine Ergebnisse:

1. Lege drei synthetische Projektnotizen an. Aufgabe: ausdrücklich offene Punkte samt Quelldatei und wörtlichem Beleg in bericht.md sammeln. Halte die korrekte Erwartung vorher separat fest.
2. Führe Arm A ohne Cindy-Anmeldung am Desktop aus. Verwende einen ausdrücklich lokalen Modellendpoint und begrenzte Rechte.
3. Wiederhole Arm B auf frischer Datenkopie vom Telefon aus am selben Desktop. Harness, Modell, Ausgangsdaten und Rechte bleiben gleich; Konto und Netzwerkzugriff sind bewusste Modusunterschiede.
4. Vergleiche korrekte Aufgaben, Fehlzuordnungen, Freigabeaufwand und Netzwerkklassen. Cloud-Begleiter-Sync und mögliche Ergebnisdateiübertragung sind ein gesonderter Teilfall, keine automatisch unterstellte Eigenschaft jedes Remotezugriffs.
5. Prüfe den Desktop-offline-Fall separat. Sichtbare Cachehistorie ist nicht dasselbe wie fortgesetzte Agentenausführung.

Erst tatsächliche Nutzungsbelege erlauben Aussagen über Kosten, Laufzeit oder Bedienvorteile.

FAQ: Häufig gestellte Fragen zu Cindy

Kannst du Cindy ohne Konto nutzen?

Ja. Laut README erlaubt „Skip Sign-In“ lokale Agenten auf dem Desktop; servergestützte Funktionen fehlen dann. Das ist kein Anschluss an einen eigenen Cindy-Server.

Funktioniert Cindy vollständig offline?

Das ist hier nicht nachgewiesen. Ein lokaler Modellendpoint entfernt die externe Inferenzroute, aber nicht automatisch jede andere Netzwerkabhängigkeit.

Läuft der Agent lokal auf dem Handy?

Die dokumentierte mobile Rolle steuert Agenten auf einem erreichbaren Computer. Daraus folgt keine lokale Modellberechnung auf dem Telefon.

Bedeutet ein eigener API-Key, dass Cindy keine Daten bekommt?

Nein. Eine direkte Providerroute kann das XD AI Gateway umgehen; angemeldete Kontodienste, Remotezugriff und Sync sind getrennte Ebenen.

Kannst du das vollständige System selbst hosten?

Nicht allein mit dem öffentlichen Clientrepository. Der Backenddienst ist darin nicht enthalten; ein angekündigtes Enterprise-Gateway ersetzt diesen fehlenden Komplettstack nicht.

Ist Cindy kostenlos?

Der Client ja. Modellverbrauch, Providerabos, optionale Cindy-Dienste und eigener Hardwarebetrieb sind davon zu unterscheiden.

Schaltet Usage statistics alle Übertragungen ab?

Nein. Heartbeat, Modellanfragen, Cloudfunktionen und Diagnosewege sind separat. Mobil bleibt nach dem Opt-out zusätzlich der vollständige App-Neustart relevant.

Fazit

Cindy ist für dich interessant, wenn du bestehende Agenten und Modelle über eine gemeinsame Desktop-/Mobiloberfläche koordinieren willst. Prüfe das zunächst mit einem synthetischen Projekt und klar getrennten Freigaben für Modellroute, Fernzugriff und Cloud-Begleiter. Wer vollständige Backendhoheit oder strikt netzlosen Betrieb verlangt, bekommt beides nicht allein durch den offenen Clientcode.

Den größeren Zusammenhang erklären der Universal-Work-Agent und die Chancen und Reviewgrenzen beim AI-Coding vom Handy.

Quellen

Primärquellen

• Cindy README am untersuchten Commit: Harnesses, Lizenzumfang, Anmeldung, Backendgrenze und Telemetrie.
• GitHub-Repository und Desktoprelease v0.1.115: Reichweitensnapshot und stabiler Versionsanker.
• Produktwebsite, Downloads und Preismodell: Plattformen, lokale Modelle, Betriebsbedingungen und Enterprise-Warteliste.
• Privacy Policy einschließlich EWR-Anhang: Provider-/Gatewayrouten, Integrationen, Diagnose, Betreiber und Transfers.
• Cloud-Begleiter: Produktregeln: Datenspeicherung, Skilltexte, Anhänge und Gerätewechsel.
• Filter für Antwortartefakte: auf diesen Uploadpfad begrenzte Dateityp- und Pfadprüfung.
• Remoteverbindungen und Dateitransport: direkte Wege, Relay und Fallbacks.
• Mobiler Consentstore, AuthContext und TapDB-Adapter: Initialisierung, Migration und Opt-out-Grenze; SSO- und Releaseanker stehen direkt am Befund.
• Desktop-Heartbeat: Accountgate statt Providerprüfung.
• Native Desktop-Crashdumps und Freigabe für Loguploads: lokale Dumps und gesonderte Uploadwege.

Historischer externer Praxistest

• Mehdi Rahmani: Cindy im Linux-Container-Sourcebuild: fremder, datierter Hands-on; keine Replikation durch diese Recherche.

Quellenabruf: 28.10.2026. Anbieterangaben, statische Codebefunde und historische Fremderfahrung wurden getrennt bewertet.