So funktioniert sinep.dev

Erste Schritte

sinep.dev ist nur auf Einladung verfügbar. Sobald Ihr Konto angelegt ist, melden Sie sich auf sinep.dev mit dem Single Sign-on Ihres Unternehmens oder mit der E-Mail-Adresse und dem Passwort an, die Sie erhalten haben.

1. Verbinden Sie Ihre Git-Forge unter Settings → git integrations oder hinterlegen Sie einen SSH-Schlüssel in Settings.
2. Legen Sie einen Workspace aus einem Repository an. Seine virtuelle Maschine startet in wenigen Sekunden.
3. Melden Sie die Agenten-CLIs unter Settings → agents bei Ihren Konten an und starten Sie dann einen Agenten im Workspace.
4. Installieren Sie die iOS- oder Desktop-App, wenn Sie Benachrichtigungen und Widgets möchten.

Workspaces

Ein Workspace ist ein Projekt mit eigener virtueller Maschine: eine Kata-MicroVM mit eigenem Kernel, vollständigem Linux-Werkzeugkasten und ausschließlich den Dateien dieses Projekts. Agenten in einem Workspace sehen weder einen anderen Workspace noch einen anderen Nutzer noch den Host.

• Dateien, die Unterhaltungen der Agenten und Ihr Home-Verzeichnis bleiben bei Neustarts der virtuellen Maschine erhalten.
• Rootless podman steht im Workspace zur Verfügung, sodass Agenten Container-Images bauen und testen können. Einen Docker-Socket gibt es nicht.
• Jeder Workspace hat Limits für Arbeitsspeicher, CPU und Prozesse, und jedes Konto hat ein Speicherkontingent. Ein Agent in einer Endlosschleife bremst nur sich selbst aus.
• Frieren Sie einen Workspace ein, den Sie gerade nicht nutzen, um seinen Arbeitsspeicher freizugeben. Seine Dateien bleiben erhalten, und die zuvor laufenden Agenten werden beim Auftauen fortgesetzt.
• Tailscale pro Workspace (optional) ermöglicht Agenten den Zugriff auf Ihr Firmennetz über Ihr eigenes Tailnet, gesteuert durch Ihre Tailscale-ACLs.

Agenten und Terminals

Claude Code, Codex und OpenCode laufen in echten Terminals im Workspace. Jedes Terminal lebt in einer tmux-Session, sodass das Schließen des Browser-Tabs oder ein Verbindungsabbruch nichts anhält.

• Betreiben Sie so viele Agenten, wie die Ressourcen des Workspaces erlauben, jeden in einem eigenen Tab.
• Die Seite Agents zeigt jeden Agenten in jedem Workspace: ob er arbeitet, auf Sie wartet oder fertig ist.
• Anweisungen, Skills und MCP-Server, die Sie unter Settings → agents festlegen, erhalten alle Ihre Agenten.
• Über den sinep.dev MCP-Server können Agenten Dateien und Diffs in Ihrem Browser öffnen, Ihnen Entscheidungen vorlegen, Vorschau-Links senden und – wenn Sie es erlauben – Ihre Chats lesen und schreiben.

Review und git

Alles, was ein Agent ändert, erscheint im Review-Bereich, Datei für Datei, mit Hervorhebung auf Wortebene.

• Stagen Sie eine ganze Datei, einen Hunk oder eine einzelne Zeile und committen Sie dann mit einer Nachricht.
• Pushen, pullen und öffnen Sie Pull- oder Merge-Requests auf GitHub, GitLab oder Forgejo. Das läuft auf dem Server mit Ihren gespeicherten Zugangsdaten, nicht im Workspace.
• Mit Checkpoints kehren Sie zum Stand vor dem Zug eines Agenten zurück.
• Freies Bearbeiten ist jederzeit erlaubt: Sie müssen keine Änderung über einen Agenten leiten.

Pläne mit Herkunftsnachweis

Für größere Vorhaben können Sie einen Plan schreiben und ihn wie eine Migration anwenden. sinep.dev legt einen Branch an, lässt den Agenten den Plan ausführen, führt Ihre Abnahmebefehle aus und committet das Ergebnis.

• Jeder Commit hält fest, welcher Plan, welcher Agent, welches Modell und welche Session ihn erzeugt haben. Das vollständige Transkript liegt in git notes, sodass ein frischer Klon die gesamte Historie enthält.
• Ein Plan lässt sich nie deterministisch wiederholen. Ein erneuter Lauf ist ein Re-Roll: ein neuer Branch und ein neuer Eintrag, niemals ein Überschreiben.
• Schlägt etwas fehl, bleiben Branch und Arbeitsverzeichnis erhalten, damit Sie sie prüfen oder übernehmen können. Der Ziel-Branch wird nie angetastet.

Entscheidungen und Hinweise

Ein Agent, der Sie braucht, hält nicht an und wartet in einem Terminal, das Sie gerade nicht ansehen. Er legt eine Entscheidung an: eine Frage, den Kontext und zwei bis fünf Optionen mit seiner Empfehlung. Dann arbeitet er an dem weiter, was nicht von der Antwort abhängt.

• Antworten Sie auf der Seite Agents, über eine Push-Benachrichtigung oder auf dem iOS-Sperrbildschirm. Die Antwort wird direkt in den Agenten eingegeben.
• Interventionen sind Aufgaben, die nur ein Mensch erledigen kann, etwa sich irgendwo anmelden oder einen DNS-Eintrag hinzufügen. Sie markieren sie als erledigt, und der Agent prüft das und macht weiter.
• Hinweise teilen Ihnen mit, was ein Agent getan hat und was Sie wissen sollten, etwa ein Deploy – ohne etwas zu fragen.
• Soll jemand ohne Konto entscheiden, teilen Sie einen Link zu einer einzelnen Entscheidung. Die Person sieht nur diese Frage.
• Agenten fragen nie über eine Entscheidung nach einem Passwort oder Schlüssel. Secrets gehören an ihren Platz, etwa unter Settings → workspace credentials.

Der Assistent

Der Assistent ist Ihr eigener Agent in einem eigenen Workspace, eingerichtet unter Agents → assistant. Er kann Ihre Agenten in anderen Workspaces sehen und in sie schreiben – was gewöhnliche Agenten nie können.

• Bitten Sie ihn, eine Aufgabe zu starten: Er startet einen Agenten auf eigenem Branch und eigenem Checkout.
• Er wartet auf die Agenten, denen er Arbeit gegeben hat, und meldet ihre Ergebnisse – oder sagt Ihnen, wenn einer feststeckt.
• Wenn Sie es erlauben, kann er Entscheidungen im Rahmen Ihrer eigenen Regeln beantworten. Sie sehen trotzdem jede Antwort.
• Nachrichten aus Chats oder von anderen Agenten erreichen ihn als Daten gekennzeichnet. Er handelt nur auf Ihr Wort und nach Ihren Regeln.

Jobs

Ein Job ist eine von Ihnen verfasste Nachricht, die in den Assistenten, in alle Ihre Agenten, in die Agenten eines Workspaces oder in einen einzelnen Agenten eingegeben wird. Er läuft, sobald einer seiner Auslöser greift.

• Zeitplan: ein cron-Ausdruck in Ihrer Zeitzone, höchstens alle fünf Minuten.
• Webhook: Ein externer Dienst ruft die geheime URL des Jobs auf. Mitgesendeter Text wird nur angehängt, wenn Sie das erlaubt haben, und als Daten von außen gekennzeichnet.
• Chat: Eine ungelesene Nachricht entspricht Ihrer Regel, etwa eine Direktnachricht, eine Erwähnung, ein Stichwort, ein Absender oder eine in Alltagssprache formulierte Bedingung. Nachrichten, die zusammen eintreffen, werden in einem Lauf zugestellt.
• Inzyde: ein Ereignis in Ihrer Inzyde-Organisation, etwa eine angelegte oder abgeschlossene Aufgabe.

Ein Auslöser bestimmt nur, wann ein Job läuft. Ziel und Nachricht legen immer Sie fest, und jeder Job ist in seiner Ausführungshäufigkeit begrenzt.

Chats

Verbinden Sie Ihre Chat-Konten unter Settings → chats und lesen Sie alle in einem Posteingang: Matrix (einschließlich verschlüsselter Räume), Slack, Microsoft Teams, Signal, Telegram, WhatsApp Business und Gmail. Pro Dienst lassen sich mehrere Konten verbinden.

• Über die sinep.dev MCP-Tools können Agenten eine Unterhaltung finden, lesen und in Ihrem Namen beantworten. E-Mails werden nie an Agenten weitergegeben.
• Antwortvorschläge: Für die Unterhaltungen Ihrer Wahl entwirft sinep eine Antwort oder Reaktion und wartet auf Ihren Klick.
• Handeln ohne Rückfrage ist ein separater Schalter pro Unterhaltung, mit strengen Grenzen, was und wie oft.
• Nachrichten werden stets als Worte anderer Menschen behandelt, nie als Anweisungen.

Vorschau-Links

Eine Web-App in einem Workspace, etwa ein Dev-Server oder eine API, erhält über das Ports-Menü einen privaten Link. Ein Agent kann Ihnen den Link auch selbst schicken.

• Links gelten eine Stunde und lassen sich jederzeit über das Ports-Menü widerrufen.
• Vorschauen werden von einer separaten Domain ausgeliefert, sodass Code in einer Vorschau niemals in Ihrem Namen auf sinep.dev handeln kann.

Zugangsdaten

Standardmäßig bleiben Git-Zugangsdaten auf dem Server, und Git-Aktionen über die Schaltflächen laufen dort. Wenn git, Cloud-CLIs oder andere Tools im Terminal funktionieren sollen, wählen Sie aus, was in Ihre Workspaces kopiert wird.

• SSH-Schlüssel und Forge-Tokens.
• Kubeconfig, AWS-Profile, Zugangsdaten für Google Cloud und Azure sowie beliebige Dateien in Ihrem Home-Verzeichnis.
• Benannte Umgebungsvariablen für Ihre eigenen Tools.

Alles, was Sie synchronisieren, ist für die Agenten in diesen Workspaces erreichbar. Findet ein Agent offen liegende Zugangsdaten in einem Repository, protokolliert er sie unter Agents → leaks, damit Sie sie austauschen können. Gespeichert werden nur Art und Fundort, nie das Secret selbst.

Apps

• Browser: Alles funktioniert in jedem modernen Browser, auf dem Desktop wie auf Tablets.
• iOS: eine Live Activity mit dem Status Ihrer Agenten, Widgets für Home- und Sperrbildschirm, Push-Benachrichtigungen, Antworten mit einem Tippen und Diktat.
• macOS, Windows und Linux: eine Desktop-App mit Benachrichtigungen. Unter macOS zusätzlich Desktop-Widgets für Agenten, Nutzung und Entscheidungen.
• Android: eine App mit dem vollständigen Cockpit, installiert über einen Download-Link, den wir Ihnen schicken.

Teams und Organisationen

• Single Sign-on: Ihre Organisation meldet ihre Mitarbeitenden über ihren eigenen OIDC-Identity-Provider oder mit lokalen Passwörtern an.
• Organisations-Admins verwalten ihre Konten, ihren Identity Provider und ihr Audit-Log.
• Teilen Sie einen Workspace mit Kollegen: Alle, die Zugriff haben, arbeiten als vollwertige Mitwirkende und sehen seine Entscheidungen.
• Limits und Kontingente: Admins können Workspaces, Arbeitsspeicher und Speicherplatz jedes Kontos begrenzen.
• Runner: Betreiben Sie die Workspaces Ihrer Organisation auf Ihrem eigenen Server mit Docker und Kata. Der Runner baut die Verbindung zu sinep.dev selbst auf; Ihr Code und Ihre Daten bleiben auf Ihrer Hardware.
• Aktivität: Jede Person sieht nur ihre eigene Übersicht erledigter Arbeit. Es gibt keine Rangliste und keine Stundenzählung.

Sicherheitsmodell

sinep.dev geht davon aus, dass der Code, den Agenten ausführen, bösartig sein kann: Pakete und Build-Skripte, die niemand gelesen hat. Die Architektur hält diesen Code in seinem Workspace.

• Eine MicroVM pro Workspace mit eigenem Kernel, die nur diesen Workspace einbindet.
• Internetzugang für Agenten – Host, interne Dienste, private und Link-Local-Adressbereiche, Cloud-Metadaten und andere Workspaces sind gesperrt.
• Git-Aktionen über die Schaltflächen laufen auf dem Server, mit deaktivierten Hooks und riskanten Konfigurationen.
• Schlüssel von Modellanbietern und Chat-Sessions bleiben auf dem Server. Kein Tool gibt sie an einen Agenten weiter.
• Workspaces, Chats und Dateien anderer Nutzer werden schlicht nicht gefunden – nicht bloß verweigert.
• Admins sehen Konten und Limits, nie den Inhalt von Workspaces.

Das gehostete sinep.dev läuft in Rechenzentren in der Europäischen Union. Für einen Sicherheitsfragebogen oder weitere Details schreiben Sie an contact@sinep.dev.

Hilfe

Sie nutzen sinep.dev und kommen nicht weiter? Schreiben Sie an support@sinep.dev. Für Preise, einen Test für Ihr Team oder einen Runner auf Ihrer eigenen Hardware nutzen Sie das Kontaktformular oder schreiben Sie an contact@sinep.dev.