Mein Agent-Setup: Projekte auf ihren Rechnern, Steuerung im Browser

Ich möchte einen Coding-Agenten von einem anderen Rechner aus steuern können, ohne dafür meine Entwicklungsumgebung auf diesem Gerät nachzubauen. Mein Ansatz trennt deshalb die Oberfläche, das Repository und die Ausführung der Anwendung. Der Browser gibt den Auftrag, der zuständige Rechner bearbeitet den Code und dessen Entwicklungsumgebung prüft das Ergebnis.

Key Takeaways (TL;DR)

• Speicherort festlegen: Bestimme das maßgebliche Repository und halte Änderungen in dieser Arbeitskopie.
• Bestehende Abläufe anbinden: Ergänze die Agentensteuerung um einen funktionierenden Entwicklungsprozess und prüfe jede Übergabe.
• Ergebnisse am richtigen Stand prüfen: Starte die Validierung erst, wenn die Änderungen vollständig in der Laufzeitumgebung angekommen sind.
• Remote-Zugriff bewusst einrichten: Trenne die Erreichbarkeit einer Oberfläche von der Berechtigung, ihre Inhalte zu sehen.
• Parallelität vollständig isolieren: Trenne neben den Arbeitsverzeichnissen auch Laufzeit, Synchronisation und veränderliche Daten.

Mein Ausgangspunkt sind zwei Rechner mit unterschiedlichen Aufgaben

Beruflich arbeite ich auf einem Windows-Laptop mit WSL2. Das Git-Repository liegt im Linux-Dateisystem dieser Distribution, während die Anwendung in Docker läuft. Die Dateien gelangen über unseren bestehenden FTP-/SFTP-Sync in den Entwicklungscontainer. Diese Konstruktion passt zu einem Team, in dem auch direkt unter Windows gearbeitet wird und Bind Mounts im bisherigen Ablauf Probleme verursacht haben.

Privat nutze ich einen Laptop mit CachyOS. Dort liegen die privaten Repositories und eine native Linux-Entwicklungsumgebung. Die Trennung zwischen Arbeitsgerät und Privatgerät ist für den Aufbau entscheidend: Ein zusätzlicher Browserzugriff soll keinen zweiten Klon sämtlicher Arbeitsprojekte erfordern.

Der folgende Aufbau beschreibt diese Ausgangsarchitektur und die Schritte, mit denen du ein ähnliches System einrichtest. Remote-Zugriff, eine dauerhafte VM und zusätzliche Ausführungsmaschinen sind dabei ausdrücklich Ausbaustufen. Die Pfade, Projektnamen und Skripte in den Beispielen sind illustrative Vorlagen; passe sie an deine Umgebung an. Die verlinkten Produktanleitungen wurden für diesen Beitrag am 13. Oktober 2026 geprüft.

Bestandteil	Arbeitsgerät	Privatgerät
Betriebssystem	Windows mit WSL2	CachyOS, grundsätzlich auch anderes Linux
Maßgeblicher Quellcode	Repository im WSL-Dateisystem	Lokales Linux-Repository
Agent im Tutorial	Cursor Agent CLI in WSL2	Ein unterstützter Provider, etwa Claude Code oder Codex
Steuerung	bb in derselben WSL2-Distribution	Eigene private bb-Instanz
Anwendung und Prüfungen	Bestehender Docker-Container	Projektspezifische lokale oder Docker-Runtime
Dateiübertragung	Bestehender FTP-/SFTP-Sync	Entsprechend dem privaten Projekt

bb steuert die Arbeit, Docker führt die Anwendung aus

bb ist in diesem Aufbau die Oberfläche für Projekte, Threads und Agenten. Cursor ist der Coding-Agent, der Dateien liest, Änderungen vorschlägt oder ausführt und Werkzeuge benutzt. Git hält den Änderungsstand fest; Docker stellt die Laufzeit bereit. Diese Zuständigkeiten bleiben auch dann getrennt, wenn du alles aus demselben Browser bedienst.

Die Arbeit läuft auf dem Gerät, dem das Projekt zugeordnet ist. Ein Browser auf dem CachyOS-Laptop kann später die Arbeitsinstanz öffnen, ohne selbst den Cursor-Agenten dieses Arbeitsprojekts auszuführen. Das vereinfacht den Wechsel des Bediengeräts, während Build-Werkzeuge und Zugangsdaten am vorgesehenen Ausführungsort bleiben.

Für den Arbeitsrechner gilt damit eine konkrete Regel: Änderungen entstehen im WSL-Repository. Eine direkt im Container bearbeitete Datei ist zunächst nur dort verändert und fehlt im Git-Diff deiner Arbeitskopie. Selbst ein funktionierender Fix wäre dann noch kein nachvollziehbarer Beitrag zum Projekt.

Darin steckt auch die praktische Bedeutung von Agent = Model + Harness: Die Qualität hängt an den Werkzeugen und Rückmeldungen rund um das Modell. In meinem Aufbau gehört die Übertragung in die Runtime zu diesem Ablauf. Ein Agent, der die falsche Kopie prüft, kann ein korrektes Testergebnis zum falschen Code liefern.

Schritt 1: Prüfe die vorhandene WSL-Umgebung

Starte auf dem Arbeitslaptop in Windows PowerShell mit den folgenden Befehlen. Sie zeigen die Distributionen und öffnen anschließend die gewählte Umgebung. Ersetze Ubuntu durch den tatsächlichen Namen deiner Distribution.

wsl -l -v
wsl -d Ubuntu

Falls WSL noch fehlt, kannst du Ubuntu zunächst mit wsl --install -d Ubuntu in einer administrativen PowerShell installieren. Für einen bestehenden Arbeitsplatz verwendest du die bereits genutzte Distribution. Danach führst du die Linux-Befehle dieses Tutorials in deren Shell aus.

Prüfe dort den Werkzeugstand und dein Repository. Der Beispielpfad ist ein Platzhalter für einen vorhandenen Projektordner; git status darf natürlich bereits eigene Änderungen anzeigen. Notiere diesen Ausgangsstand, damit du spätere Agentenänderungen unterscheiden kannst.

cat /etc/os-release
git --version
node --version
npm --version
docker version
docker ps
cd ~/projects/kundenportal
git status --short

bb nennt aktuell Node.js 22.19 als Mindestversion und führt unter anderem Node 24 als getestete LTS-Linie auf. Für dieses Tutorial ist Node 24 eine passende Basis; eine bereits unterstützte Installation kannst du weiterverwenden. Falls ein Upgrade nötig ist, nutze den vorhandenen Versionsmanager. Der dokumentierte WSL-Weg hält bb, Node, Git und die Provider-CLIs innerhalb derselben Distribution. bb: Plattformunterstützung.

Verwendest du Docker Desktop, prüfe dessen Integration unter Settings → Resources → WSL Integration für genau diese Distribution. Bei einer anderen funktionierenden Docker-Installation entfällt dieser Desktop-Schritt. Entscheidend ist, dass die Docker-Kommandos aus WSL deine bestehenden Entwicklungscontainer erreichen. Docker: WSL-Integration.

Schritt 2: Installiere den Cursor-Agenten in WSL2

Die Cursor-GUI auf Windows und die Agent CLI innerhalb von WSL2 erfüllen unterschiedliche Aufgaben. Für die bb-Instanz in Linux brauchst du den dort erreichbaren Provider. Installiere ihn deshalb in derselben Shell, in der später auch bb läuft.

Die folgende Installation entspricht dem offiziellen Cursor-Weg für Linux und WSL. Der PATH-Eintrag wird nur ergänzt, falls er noch fehlt; die Vorlage setzt Bash voraus. Cursor: CLI-Installation.

curl https://cursor.com/install -fsS | bash

if ! [[ ":$PATH:" == *":$HOME/.local/bin:"* ]]; then
    echo 'export PATH="$HOME/.local/bin:$PATH"' >> ~/.bashrc
    export PATH="$HOME/.local/bin:$PATH"
fi

agent --version
agent login
agent status

Die Anmeldung verwendet deinen Cursor-Account. Falls sich aus WSL kein Browser öffnet, kannst du mit NO_OPEN_BROWSER=1 agent login die Login-URL ausgeben und selbst öffnen. Zugangsdaten gehören in die vom Provider vorgesehene lokale Speicherung. Cursor: CLI-Authentifizierung.

Starte anschließend agent im Projektverzeichnis und gib ihm zunächst eine Analyseaufgabe. So prüfst du unabhängig von bb, ob der Provider das Repository und dessen Struktur erreicht. Eine mögliche Anweisung lautet:

Analysiere dieses Repository und ändere keine Dateien.
Erkläre die Architektur, den Entwicklungsstart und die Prüfkommandos.
Unterscheide die WSL-Arbeitskopie vom Docker-Laufzeitverzeichnis.
Markiere unklare Punkte, statt einen fehlenden Sync-Ablauf zu erfinden.

Kontrolliere danach erneut git status --short. Eine Aufforderung, nichts zu ändern, ist eine Verhaltensanweisung und keine technische Sandbox. Nutze zusätzlich die vorhandenen Freigaben des Providers, bevor du ihm größere Aufgaben gibst.

Schritt 3: Starte bb neben deinem bestehenden Workflow

Der erste Start braucht weder eine globale Installation noch einen Autostart. Führe in WSL2 den dokumentierten Paketaufruf aus und öffne die ausgegebene Adresse im Windows-Browser. Standardmäßig ist das http://localhost:38886. bb: Paketinstallation.

npx bb-app@latest

Falls npm 12 oder neuer die Installationsskripte der nativen Abhängigkeiten blockiert, dokumentiert bb diesen gezielten Aufruf. Verwende ihn für diesen Fall, statt die Skriptprüfung pauschal abzuschalten. Er erlaubt die drei von bb benannten Pakete. bb: Native Abhängigkeiten.

npx --allow-scripts=better-sqlite3,node-pty,@parcel/watcher bb-app@latest

Windows kann einen in WSL laufenden Netzwerkdienst im üblichen lokalen Aufbau über localhost erreichen. Das ist jedoch noch kein Zugriff vom privaten Laptop aus. Die Weiterleitung zwischen Windows und WSL und die spätere Verbindung über dein Netzwerk sind zwei verschiedene Strecken. Microsoft: Netzwerkzugriff auf WSL.

Füge als erstes Projekt ein überschaubares Testrepository hinzu und verwende dessen Linux-Pfad, etwa /home/deinname/projects/testprojekt. Wähle Cursor als Provider. Für diese erste Phase soll der Thread im vorhandenen Checkout arbeiten; verwende noch keinen zusätzlichen Worktree, dessen Pfad dein Sync nicht kennt.

Prüfe zunächst wieder nur die Architektur. Danach kannst du den Agenten eine eindeutig benannte Testdatei anlegen lassen, beispielsweise bb-setup-probe.txt mit dem Inhalt bb setup probe. Mit git status --short und cat bb-setup-probe.txt kontrollierst du, ob sie im erwarteten Repository liegt. Entferne anschließend genau diese selbst angelegte Datei.

Wenn du die bb-Telemetrie deaktivieren möchtest, findest du die Einstellung unter Settings → General → Privacy & diagnostics → Share anonymous usage data. Für Firmenrechner ist das eine sinnvolle bewusste Entscheidung beim Einrichten. Die aktuelle Dokumentation beschreibt außerdem BB_TELEMETRY=false als Abschaltung über die Umgebung. bb: Telemetrie konfigurieren.

Schritt 4: Beweise, dass Agentenänderungen wirklich synchronisiert werden

Hier liegt die wichtigste Besonderheit meines Setups. Ein Sync, der auf das Speichern innerhalb der IDE reagiert, muss nicht automatisch auf eine Dateiänderung durch einen CLI-Agenten reagieren. Und ein Watcher, der nur bei geöffneter IDE läuft, kann seine Arbeit einstellen, sobald du ausschließlich über bb arbeitest.

Teste deshalb die gesamte Strecke bei geschlossenem Editor. Lass im synchronisierten Projektpfad eine harmlose Textdatei entstehen und prüfe sie anschließend im Entwicklungscontainer. Im folgenden Bash-Beispiel steht kundenportal-dev für deinen tatsächlichen Container; /app muss dem realen Zielverzeichnis entsprechen.

# Im WSL-Repository, nur wenn die Probe noch nicht existiert:
test ! -e bb-sync-probe.txt &&
    printf '%s\n' 'bb sync probe' > bb-sync-probe.txt

# Nach Abschluss des bestehenden Syncs:
sha256sum bb-sync-probe.txt
docker exec kundenportal-dev sha256sum /app/bb-sync-probe.txt
docker exec kundenportal-dev cat /app/bb-sync-probe.txt

Die beiden Prüfsummen müssen übereinstimmen. Anschließend entfernst du die selbst erzeugte Probe im Repository und kontrollierst, ob der Sync sie auch im Ziel entfernt. Prüfe außerdem Umbenennungen und Änderungen an mehreren Dateien, bevor du den Ablauf für echte Aufgaben verwendest.

Wenn dein bestehender Mechanismus dafür einen expliziten Upload oder eine laufende IDE braucht, dokumentiere diesen Schritt. Für unbeaufsichtigte Agentenarbeit brauchst du entweder einen eigenständigen Watcher oder einen aufrufbaren Übertragungsbefehl. bb übernimmt diese Aufgabe nicht automatisch, nur weil es dein Repository kennt.

FTP und SFTP bezeichnen unterschiedliche Protokolle. Der Aufbau verwendet zunächst die vorhandene Teamlösung; bei einer neuen Übertragung über Netzwerkgrenzen würde ich SFTP über SSH verwenden. Die Verbindung zum bb-Server verschlüsselt nicht automatisch eine separate Dateiübertragung zum Entwicklungscontainer.

Schritt 5: Mache Synchronisation zu einem Teil der Validierung

Ein Testlauf beginnt erst, wenn die Runtime den aktuellen Stand enthält. Eine feste Wartezeit wie sleep 2 bestätigt keine abgeschlossene Übertragung. Bei einem langsamen Upload, einer gelöschten Datei oder einem unterbrochenen Watcher wäre das Ergebnis zufällig vom Timing abhängig.

Der belastbare Ablauf lautet: lokal ändern, vollständig synchronisieren, im Container prüfen und das Ergebnis zurück an den Agenten geben. Der Sync-Befehl muss bei Fehlern fehlschlagen und bei Erfolg erst nach Abschluss der relevanten Übertragung zurückkehren. Kann dein Werkzeug das nicht, brauchst du eine zusätzliche Bestätigung des Zielstands; die Prüfsumme der Testdatei allein bestätigt noch keinen vollständigen Projekttransfer.

So könnte ein eigener Prüf-Wrapper für ein Node-Projekt mit Bash und Docker CLI aussehen. tools/sync-to-dev.sh ist hier ein anzulegender projektspezifischer Adapter, kein mit bb geliefertes Skript. Er muss euren tatsächlichen Sync anstoßen und auf dessen Abschluss warten. Die pnpm-Kommandos setzt dieses Beispiel im Container voraus.

#!/usr/bin/env bash
set -euo pipefail

project_root="$(cd "$(dirname "${BASH_SOURCE[0]}")/.." && pwd)"
cd "$project_root"

sync_script="$project_root/tools/sync-to-dev.sh"
if [[ ! -x "$sync_script" ]]; then
    printf '%s\n' 'Ein ausführbarer Sync-Adapter fehlt.' >&2
    exit 1
fi

"$sync_script"

docker exec -w /app kundenportal-dev pnpm lint
docker exec -w /app kundenportal-dev pnpm typecheck
docker exec -w /app kundenportal-dev pnpm test
docker exec -w /app kundenportal-dev pnpm build

Lege die Vorlage beispielsweise als tools/validate-dev.sh ab und mache beide Skripte ausführbar. Der Vorteil ist ein einziger klarer Aufruf für den Agenten: ./tools/validate-dev.sh. Das Skript bricht bei einem fehlgeschlagenen Transfer oder einer fehlgeschlagenen Prüfung ab, bevor weitere Schritte den Fehler verdecken.

Für ein Symfony-Projekt sähe die Prüfung anders aus. PHPStan und PHPUnit müssten mit den vorhandenen Konfigurationen im passenden PHP-Container laufen. Übernimm deshalb die existierenden Projektkommandos und halte fest, welche Prüfungen auf dem Host und welche in Docker stattfinden.

Bei Abhängigkeitsänderungen reicht die Übertragung von package.json oder composer.lock allein möglicherweise nicht aus. Die Runtime muss ihre Abhängigkeiten mit dem vorgesehenen Paketmanager aktualisieren; bei Änderungen am Image kann ein Rebuild nötig werden. Auch diese Schritte gehören in den dokumentierten Projektablauf.

Schritt 6: Gib dem Agenten die wenigen Regeln, die hier zählen

Der Provider muss den Speicherort, die Übertragung und den Prüfaufruf kennen. Dafür reicht zunächst eine kurze Regeldatei im Repository. Cursor unterstützt AGENTS.md als einfache Projektanweisung; komplexere oder gezielt begrenzte Regeln kannst du später in .cursor/rules abbilden. Cursor: Projektregeln.

Eine eigene Vorlage für dieses Setup könnte so aussehen. Trage den Prüfaufruf erst ein, wenn der Wrapper und sein Sync-Adapter tatsächlich funktionieren. Eine Beschreibung eines noch nicht existierenden Werkzeugs hilft dem Agenten nicht weiter.

# Entwicklungsumgebung

- Das Git-Repository in WSL2 enthält den maßgeblichen Quellcode.
- Bearbeite Quelldateien ausschließlich in dieser Arbeitskopie.
- Docker enthält eine über FTP/SFTP synchronisierte Laufzeitkopie.
- Ersetze den vorhandenen Sync nicht und führe keine Bind Mounts ein.
- Verwende ./tools/validate-dev.sh für Übertragung und Validierung.
- Melde Sync-Fehler und fehlgeschlagene Prüfungen ausdrücklich.
- Erzeuge für dieses Projekt vorerst keine zusätzlichen Worktrees.
- Ändere keine Zugangsdaten und lies keine Secrets ohne Aufgabenbezug.
- Commit, Push und Deployment benötigen einen ausdrücklichen Auftrag.

Solche Anweisungen beschreiben das erwartete Verhalten. Technische Einschränkungen entstehen über Rechte, Provider-Freigaben und isolierte Umgebungen. Wenn etwa der Agent Zugriff auf den Docker-Socket hat, besitzt er weitreichende Möglichkeiten auf dem Docker-Host; ein Satz in AGENTS.md schränkt diesen Zugriff nicht technisch ein.

Halte die Datei knapp und ergänze Regeln aus konkreten Problemen. Die Überlegung hinter dem Missverständnis um AGENTS.md ist hier nützlich: Mehr Anweisungen sind noch kein Beleg für bessere Ergebnisse. Ein funktionierender Prüfaufruf liefert dagegen eine überprüfbare Rückmeldung.

Referenzcode und klare Aufgaben verbessern den Arbeitskontext

Neben dem Projekt kannst du ein Verzeichnis für lokal ausgecheckte Frameworks und Bibliotheken anlegen, beispielsweise ~/references. Dort findet der Agent Implementierungen und Tests zu APIs, deren Verhalten im Projekt unklar ist. Ein kleiner, gezielt ausgewählter Bestand ist dafür hilfreicher als eine Sammlung aller möglicherweise relevanten Repositories.

Die Quellen müssen zur tatsächlich verwendeten Version passen. Der aktuelle Hauptbranch einer Bibliothek kann Funktionen enthalten, die dein Lockfile noch gar nicht kennt. Notiere deshalb pro Referenz den Release-Tag oder Commit und fordere den Agenten auf, zunächst die Projektversion zu prüfen. Dokumentation, Quellcode und Tests beantworten dabei unterschiedliche Fragen; eine Implementierung ersetzt keine Beschreibung des öffentlichen API-Vertrags.

Die Prüfwerkzeuge bleiben davon unabhängig. Ein Referenzordner liefert Hinweise auf übliche Nutzungsmuster, während Typechecker, Linter und Tests Rückmeldungen zum eigenen Code geben. Übernimm für das bestehende Projekt seine Konventionen und ergänze eine maschinell prüfbare Regel, wenn ein konkret wiederkehrender Fehler sie rechtfertigt.

Für die Agentenarbeit würde ich außerdem pro Thread eine begrenzte Aufgabe mit Abnahmekriterien formulieren. Bei einem hypothetischen Checkout-Fehler könnte der Auftrag etwa lauten: Ursache erklären, einen reproduzierenden Test ergänzen, den kleinsten passenden Fix umsetzen und den Prüf-Wrapper ausführen. Ein komplettes Refactoring nebenbei gehört dann nicht zum Auftrag.

Lange Sitzungen brauchen eine brauchbare Übergabe: Ziel, betroffene Dateien, getroffene Entscheidungen, offene Fragen und zuletzt ausgeführte Prüfungen. Halte diese Informationen knapp fest, statt vollständige Build-Logs dauerhaft in jeden neuen Kontext zu übernehmen. Nach einem Neustart prüft der nächste Lauf den aktuellen Git-Stand und behandelt alte Fertigmeldungen als zu überprüfende Angaben.

Auf CachyOS entsteht die private Instanz nach demselben Prinzip

Auf dem privaten Linux-Laptop entfällt die Grenze zwischen Windows und WSL. Prüfe dort Git, eine unterstützte Node-Version und die benötigte Runtime, melde den vorgesehenen Provider lokal an und starte bb ebenfalls mit npx bb-app@latest. Als Projektpfad verwendest du dein privates Linux-Repository, etwa /home/deinname/projects/sideproject.

Wenn du Cursor auch privat verwenden möchtest, kannst du die Linux-Installation aus Schritt 2 wiederholen. Für einen bereits installierten anderen Provider prüfst du dessen lokale Anmeldung und Auswahl in bb. Der Testablauf bleibt gleich: zunächst analysieren, dann eine kleine Änderung im richtigen Checkout nachweisen und schließlich die privaten Projektprüfungen ausführen.

Diese Instanz hat ihren eigenen Zustand und ist zunächst unabhängig von der Arbeitsinstanz. Ein Browser-Lesezeichen pro Server und getrennte Browserprofile helfen, Projekte und Accounts eindeutig zuzuordnen. Die lokale Adresse localhost:38886 bezeichnet dabei immer den Rechner, auf dem dieser Browser läuft; für den Arbeitslaptop verwendest du später dessen ausdrücklich eingerichtete Remote-Adresse.

Schritt 7: Richte den Remote-Zugriff über einen bewussten Zugangsweg ein

Jetzt sollte die lokale Kette funktionieren: Windows-Browser, bb in WSL, Cursor, Repository, Sync und Docker-Prüfungen. Erst danach lohnt sich der Zugriff vom CachyOS-Laptop. Du kannst dafür einen verwalteten Zugang über bb connect oder einen eigenen privaten Netzwerkzugang über Tailscale wählen.

bb connect stellt die Oberfläche über deinen Account bereit

Der dokumentierte Weg führt über Settings → bb connect. Melde dich an, bestätige die Anmeldung, wähle deine Adresse und aktiviere den Remote-Zugriff. Öffne diese Adresse anschließend auf dem zweiten Gerät mit dem berechtigten Account. Der Dienst vermittelt die Verbindung zu deiner laufenden Instanz. bb: Von unterwegs arbeiten.

Der Arbeitsrechner bleibt der Ort der Dateibearbeitung und Befehlsausführung. bb connect ist jedoch ein zusätzlicher Dienst im Transportweg. Wähle diesen Zugang für Arbeitsinhalte nur, wenn er zum zugelassenen Arbeitsmodell passt; die technische Erreichbarkeit entscheidet diese Frage nicht.

Tailscale verbindet deine Geräte in einem privaten Netzwerk

Für einen eigenen Netzwerkweg installierst du Tailscale auf dem Servergerät und dem Bediengerät und meldest beide im vorgesehenen Tailnet an. Die offizielle Downloadseite führt die plattformspezifischen Installationswege auf. Für CachyOS verwendest du die zu seiner Arch-Basis passende Anleitung und prüfst anschließend, ob der Dienst läuft und beide Geräte im Netzwerk sichtbar sind.

Tailscale Serve kann einen lokalen HTTP-Dienst per HTTPS innerhalb des Tailnets verfügbar machen. Diese Funktion passt zur bb-Instanz, die zunächst nur an Loopback lauscht. Die Zugriffsregeln des Tailnets bestimmen, welche Geräte und Identitäten den Dienst erreichen dürfen. Tailscale: Serve.

Auf einem Linux-Host, auf dem Tailscale und bb dieselbe Loopback-Adresse erreichen, dokumentiert bb folgenden Aufruf. Ersetze die Beispieladresse durch die tatsächlich von Tailscale ausgegebene HTTPS-Adresse. Falls Serve dich zur Aktivierung von HTTPS auffordert, schließe diesen Einrichtungsschritt zuerst ab. bb: Zugriff von mehreren Geräten.

tailscale serve --bg --https=443 http://127.0.0.1:38886
npx bb-app config set BB_APP_URL https://agentbox.example-tailnet.ts.net
tailscale serve status

Bei Windows plus WSL musst du vorher klären, wo Tailscale läuft. Läuft es unter Windows, prüfst du dort zuerst, ob http://127.0.0.1:38886 die WSL-Instanz erreicht. Erst dann richtest du Tailscale Serve auf Windows für genau dieses Ziel ein; BB_APP_URL konfigurierst du weiterhin in WSL. Läuft Tailscale innerhalb der Distribution, braucht diese ihren eigenen funktionierenden Dienst und eine Verbindung zum Tailnet.

Die Tailscale-Adresse von Windows macht einen nur intern erreichbaren WSL-Dienst nicht automatisch auf demselben Port erreichbar. Prüfe deshalb den vollständigen Weg vom zweiten Gerät bis zur Oberfläche. Microsoft beschreibt die Unterschiede zwischen lokalem WSL-Zugriff, NAT und Mirrored Networking in der WSL-Netzwerkdokumentation.

Für bb gehört die Zugriffsgrenze unmittelbar zur Einrichtung: Die Dokumentation beschreibt die direkte Server-API als unauthentifiziert und mit Zugriff auf Befehle und Dateien. Halte den Dienst hinter dem vorgesehenen privaten Zugang; verwende für dieses Setup weder eine öffentliche Portfreigabe noch Tailscale Funnel. bb: Grenzen des direkten Netzwerkzugriffs.

Der Browserzugriff ersetzt das zweite Repository, aber keine laufende Maschine

Du kannst vom privaten Laptop aus Aufgaben starten, Rückfragen beantworten und Änderungen ansehen, während der Arbeitslaptop die Befehle ausführt. Das erspart einen weiteren Projektklon und eine zweite Installation der Arbeitsruntime. Im Büro bleibt das Repository dort, wo du es ohnehin verwendest.

Der Ausführungsrechner braucht dafür Strom, Netzwerk und laufende Dienste. Sleep, ein geschlossenes Laptop-Display oder ein beendeter bb-Prozess können diese Verfügbarkeit unterbrechen. Ein Keep-Awake-Werkzeug verhindert je nach Konfiguration Leerlaufschlaf, ersetzt aber keine Prüfung des tatsächlichen Deckel- und Energiesparverhaltens. bb: Rechner erreichbar halten.

Teste den Remote-Zugang deshalb auch nach einem Neustart. Prüfe, ob WSL, bb, der Sync und die Container wieder gestartet sind, bevor du eine Aufgabe als unbeaufsichtigt ausführbar behandelst. Eine funktionierende Browsersitzung allein bestätigt noch nicht, dass auch der Datei-Watcher läuft.

Wenn du selbst Dateien bearbeiten möchtest, bleibt die IDE nützlich. Ein erlaubter Remote-Editor oder Remote Desktop ergänzt die Agentenoberfläche für interaktives Debugging, manuelle Änderungen und lokale Spezialwerkzeuge. Dafür muss dieselbe Arbeitskopie verwendet werden, und während einer Agentenänderung sollten sich die Schreibzugriffe nicht überschneiden.

Die Trennung spart Einrichtung und schafft klare Zuständigkeiten

Der erste Vorteil ist die Kontinuität der Arbeitsumgebung. Ob du vor dem Windows-Laptop sitzt oder seine bb-Oberfläche von einem anderen Gerät bedienst: Das Projekt verwendet denselben Dateipfad, dieselbe Runtime und denselben Sync. Fehler lassen sich an einem konkreten Ausführungsort untersuchen.

Der zweite Vorteil ist die Trennung privater und beruflicher Projekte. Zwei eigenständige Instanzen haben getrennte Threads, Einstellungen und angebundene Maschinen. Ein Browser kann beide öffnen, etwa in unterschiedlichen Profilen, ohne dass die Arbeitsmaschine dem privaten Server beitreten muss.

Der dritte Vorteil ist die Nachvollziehbarkeit. Die Änderung entsteht in Git, die Übertragung bestätigt ihren Zielstand und die Validierung liefert Ausgaben zu diesem Stand. Ein Diff, ein Prüfprotokoll und die bekannten Container-Kommandos sind wesentlich hilfreicher als eine reine Fertigmeldung des Agenten.

Der vierte Vorteil ist ein schrittweiser Ausbau. Du kannst zunächst ein Projekt mit einem Agenten bearbeiten und erst bei einem konkreten Engpass zusätzliche Kapazität schaffen. Ein neuer Rechner braucht dann einen klaren Zweck, etwa einen langen Build oder eine isolierte Testumgebung.

Ein Browserzugriff bedeutet allerdings keine vollständig lokale KI-Verarbeitung. Die Repository-Dateien können auf dem Arbeitsgerät bleiben, während der Agent ausgewählten Code und andere Kontextdaten an seinen Modellanbieter sendet. Angezeigte Inhalte erreichen außerdem den Browser des Bediengeräts. Auch bb beschreibt den gewählten KI-Provider als Teil des Datenwegs. bb: Datenschutz und Datenfluss.

Für berufliche Projekte gehören deshalb zugelassene Provider, Remote-Zugangswege und Bediengeräte zu den Voraussetzungen. Zugangsdaten bleiben in der vorgesehenen Speicherung auf den jeweiligen Hosts. Die Aussage, das Repository werde nicht auf den Privatlaptop geklont, ist eine konkrete Eigenschaft dieses Aufbaus; sie beantwortet nicht jede Frage zur Verarbeitung der Inhalte.

Eine einzelne IDE wäre einfacher und kann völlig ausreichen

Das stärkste Gegenargument ist der zusätzliche Betriebsaufwand. bb, ein CLI-Provider und ein Remote-Zugang erzeugen weitere Dienste, deren Erreichbarkeit du prüfen musst. Mit WSL2, einem Sync-Watcher und Docker gibt es ohnehin schon mehrere Stellen, an denen eine Aufgabe hängen bleiben kann.

Wenn du ausschließlich an einem Rechner und einem Projekt arbeitest, kann die vorhandene IDE die bessere Wahl sein. Mein Aufbau wird interessant, sobald Bediengerät und Ausführungsort auseinanderfallen oder mehrere Maschinen unterschiedliche Aufgaben übernehmen sollen. Der zusätzliche Aufwand muss sich an diesem Bedarf messen lassen.

Die SFTP-Strecke ist ebenfalls eine bewusste Abwägung. Ein zuverlässiger Bind Mount wäre in einer neuen homogenen Linux-Umgebung einfacher, weil die zusätzliche Dateikopie entfällt. In meiner vorhandenen Teamumgebung zählt jedoch die funktionierende Integration. Deshalb wird der bestehende Transfer geprüft und angebunden, bevor eine neue Agentenoberfläche Anlass für einen Umbau wird.

Später trennt jeder Worktree auch seine Laufzeit

Für den Einstieg arbeite ich mit einem aktiven schreibenden Agenten pro Checkout. bb kann für parallele Aufgaben eigene Git Worktrees anlegen, aber deren getrennte Verzeichnisse lösen nur die Isolation des Quellcodes. Der bestehende Sync kennt diese neuen Pfade möglicherweise noch gar nicht. bb: Worktrees und Setup-Skripte.

Sobald mehrere Aufgaben im selben Projekt gleichzeitig laufen, braucht jede davon eine passende Umgebung. Dazu gehören ein eigener Sync-Pfad, ein eigener Container oder Compose-Stack und eindeutige Ports. Auch Datenbanken, Upload-Verzeichnisse, Caches und andere veränderliche Zustände müssen entsprechend getrennt werden.

Zwei Worktrees, die beide nach container:/app übertragen werden, ergeben keine zwei unabhängigen Entwicklungsumgebungen. Sie ergeben zwei unterschiedliche Quellstände an einem wechselnden Testziel. Das ist eine Parallelisierung, die du spätestens beim ersten widersprüchlichen Testergebnis wieder zurückbauen musst.

bb sieht Setup- und Teardown-Skripte für verwaltete Worktrees vor. Darin kannst du später projektspezifisch einen Stack erzeugen, das Sync-Ziel konfigurieren und nach Abschluss die zugehörigen Ressourcen aufräumen. Der erste Abnahmetest dafür ist einfach: Eine Änderung in Umgebung A darf den Dateistand und die Testdaten von B nicht verändern. bb: Worktree-Lebenszyklus.

Eine dauerhafte VM löst die Abhängigkeit vom Laptop

Die nächste Ausbaustufe wäre für private Projekte ein Rechner, der unabhängig vom Laptop läuft. Das kann eine Linux-VM auf einem Homeserver, ein kleiner dedizierter Rechner oder ein VPS sein. Die Entscheidung hängt an Erreichbarkeit, Ressourcen, Kosten und dem gewünschten Ort der Daten.

Dabei gibt es zwei Rollen. Eine Server-VM hält die bb-Oberfläche und den zentralen Zustand dieser Instanz verfügbar. Eine Ausführungs-VM übernimmt die Agentenarbeit und die Projektumgebung. Liegt der bb-Server dauerhaft auf einer VM, das Projekt aber weiterhin auf einem schlafenden Laptop, bleibt die betreffende Aufgabe trotzdem vom Laptop abhängig.

Variante	Sinnvoller Einsatz	Zu betreibende Teile
VM auf dem Homeserver	Private Projekte mit Daten und Builds im eigenen Netz	Hypervisor, Speicher, Netzwerk, Backups
VPS	Von zuhause unabhängige Erreichbarkeit und private Hintergrundaufgaben	Anbieteraccount, laufende Kosten, Updates, Zugangsschutz
Dedizierter Linux-Rechner	Dauerhafte lokale Build- und Agent-Kapazität	Hardware, Strom, Betriebssystem, Backups
Verwaltete Firmen-VM	Arbeitsprojekte in einer vorgesehenen Firmenumgebung	Betriebliche Freigaben, Identitäten, Netzregeln, Runtime

Für eine neue VM würde ich zunächst einen eigenen Benutzer, SSH-Zugang und den vorgesehenen privaten Netzwerkweg einrichten. Danach folgen eine unterstützte Node-Version, Git, der gewählte Provider und das Testrepository. Erst wenn ein lokaler Agentenlauf funktioniert, installierst du bb beziehungsweise bindest die Maschine an einen vorhandenen Server an.

Die Runtime muss dort reproduzierbar aufgebaut werden. Versionsdateien, Lockfiles und Compose-Konfigurationen helfen dabei; Zugangsdaten provisionierst du getrennt. Für private Projekte muss eine frische VM die besondere SFTP-Strecke des Arbeitslaptops nicht übernehmen. Ihre Dateianbindung sollte zur dortigen Umgebung passen.

Zum dauerhaften Betrieb gehören Dienststart nach dem Boot, erreichbare Logs, Updates und eine Wiederherstellungsprobe. Git sichert nur die gepushten Commits im Remote-Repository. Uncommittete Arbeit, lokale Konfiguration und der bb-Zustand brauchen eigene Backups; vor dem Kopieren einer laufenden Datenbank musst du deren konsistente Sicherung klären.

Snapshots sind vor Experimenten mit neuen Tools oder Konfigurationen hilfreich. Ein Snapshot auf demselben Datenträger ist aber keine unabhängige Sicherung. Die VM sollte sich aus dokumentierter Einrichtung und getrennt gespeicherten Backups wiederherstellen lassen.

Weitere Agent-Maschinen bekommen konkrete Aufgaben im Netzwerk

Ein zusätzlicher Agent-Server kann ein Rechner sein, auf dem der Provider Prozesse startet und Werkzeuge ausführt. Dafür muss dort kein Sprachmodell lokal rechnen: Die CLI kann weiterhin einen gehosteten Modellanbieter verwenden. Ein eigener Modellserver wäre eine weitere, davon getrennte Ausbaustufe.

bb unterscheidet zwischen einem Bediengerät im Browser und einer registrierten Ausführungsmaschine mit Host-Daemon. Für zusätzliche Maschinen öffnest du auf dem zuständigen Server Settings → Machines, wählst den vorgesehenen Hinzufügen-Ablauf und führst den dort erzeugten Installationsbefehl auf dem Zielhost aus. So verwendet die Verbindung die zu deiner Instanz passende Konfiguration. bb: Zusätzliche Ausführungsmaschinen.

Der Zielrechner braucht die Projektdateien, die vorgesehenen Werkzeuge und eine eigene Provider-Anmeldung. Dass du die Oberfläche auf einem Laptop öffnest, macht ihn noch nicht zu einer Ausführungsmaschine. Umgekehrt erhalten zwei unabhängig gestartete bb-Server nicht automatisch eine gemeinsame Thread-Historie.

Für private Arbeit könnte die Aufgabenverteilung später beispielsweise so aussehen. Die gezeichnete zentrale Instanz gehört ausschließlich zum privaten Bereich. Die Arbeitsinstanz bleibt separat auf dem Arbeitsgerät oder einer dafür vorgesehenen Firmenmaschine.

Ein Build-Rechner könnte größere Testläufe übernehmen, eine Wegwerf-VM riskantere Abhängigkeitsupdates und der Laptop die interaktive Arbeit. Ob das sinnvoll ist, entscheidest du an tatsächlichen Wartezeiten und Ressourcenengpässen. Zusätzliche Agenten erhöhen außerdem den Aufwand für Review, Zusammenführung und Kostenkontrolle.

Mit weiteren Hosts wächst die Bedeutung der Zugriffsgrenzen. Eine Experimentier-VM braucht beispielsweise keinen Zugriff auf sämtliche Arbeitsprojekte oder Produktionszugänge. Ein eigener Benutzer oder eine VM kann Rechte sinnvoll begrenzen; eine breit angebundene Host-CLI mit vollem Docker-Zugriff bekommt diese Isolation nicht allein durch die Bezeichnung Agent-Server.

Die deterministischen Teile sollten dabei als Skripte bestehen bleiben: Umgebung erzeugen, synchronisieren, prüfen und aufräumen. Der Agent verwendet sie für seine Aufgabe und bewertet die Rückmeldungen. Diese Aufteilung folgt derselben Überlegung wie Code dort einzusetzen, wo der Ablauf berechenbar ist.

10 Schritte, mit denen du den Aufbau abnehmen kannst

1. Ausgangsstand festhalten: Bestimme Distribution, Repository, Container und vorhandenen Sync; notiere bereits bestehende Git-Änderungen.
2. Werkzeuge am Ausführungsort prüfen: Stelle sicher, dass Git, Node, Docker CLI und Provider innerhalb der vorgesehenen Linux-Umgebung erreichbar sind.
3. Provider separat testen: Melde die Cursor Agent CLI an und lass sie das Testrepository zunächst ausschließlich analysieren.
4. bb lokal starten: Öffne die Oberfläche, wähle den Provider und verwende den Linux-Pfad des bestehenden Checkouts.
5. Eine Änderung nachvollziehen: Lass eine eindeutig benannte Probe anlegen und kontrolliere ihren Speicherort sowie den Git-Status.
6. Sync ohne IDE prüfen: Teste mit geschlossenem Editor Änderungen, neue Dateien, Löschungen und Umbenennungen am tatsächlichen Containerziel.
7. Validierung verbindlich machen: Implementiere einen abgeschlossenen Transfer vor den vorhandenen Prüfkommandos und teste den Fehlerfall.
8. Projektregeln hinterlegen: Beschreibe Speicherort, Runtime und real existierenden Prüfaufruf knapp; kontrolliere die Provider-Freigaben.
9. Remote-Zugang abnehmen: Richte einen zugelassenen Zugangsweg ein und prüfe vom zweiten Gerät auch Neustart, Sleep-Verhalten und laufenden Sync.
10. Ausbau an einem Engpass ausrichten: Ergänze erst danach Worktrees mit eigener Runtime, eine dauerhafte VM oder weitere Maschinen mit einer konkreten Aufgabe.

Der erste entfernte Agentenlauf ist für mich erst bestanden, wenn sein Git-Diff und sein Testergebnis denselben Code beschreiben.