Ein Coding-Agent ist nur so verfügbar wie die Maschine, auf der er läuft. Starte einen langen Refactor mit Claude Code oder Codex, klapp den Laptop zu, um noch den Zug zu erwischen, und der Lauf stirbt mit deiner SSH-Sitzung. Starte zwei Agenten auf demselben Laptop, und die Lüfter drehen auf, während dein Editor ruckelt. Irgendwann ist die Frage nicht mehr „welcher Agent", sondern „wo läuft der Agent eigentlich".
Die Antwort ist meist eine von drei: auf dem Laptop lassen, auf einen Remote-Server verlagern oder die Arbeit auf beide aufteilen. Jede Wahl tauscht Bequemlichkeit gegen Zuverlässigkeit. Ein Laptop ist direkt da, aber er schläft, drosselt und trennt die Verbindung. Ein Server bleibt wach und hat mehr Kerne, bringt aber Einrichtungsaufwand mit und eine zusätzliche Ebene von „was macht er gerade überhaupt". Der Mittelweg gibt dir das Beste aus beiden Welten – und die Buchhaltung von beiden.
Dieser Artikel führt dich durch das Remote-Agent-Setup von Anfang bis Ende: den Do-it-yourself-Weg mit echten Befehlen, den Fehlerfall, der bei jedem Schritt lauert, und wo ein verbundener Computer in Sharkly den Teil wegnimmt, der immer wieder kaputtgeht. Du hast bereits Coding-Agenten. Das Problem ist, sie irgendwo dauerhaft laufen zu lassen und zu wissen, was passiert ist, wenn du mal wegschaust.
Warum du einen Agent von deinem Laptop wegbewegen solltest
Der Laptop ist der Standard, weil du dort tippst. Er ist aber auch der schlechteste Host für alles, was länger läuft als deine Aufmerksamkeitsspanne. macOS schläft beim Zuklappen des Deckels. Der Akkumodus drosselt die CPU. Firmen-VPNs brechen ab. Jedes dieser Ereignisse tötet einen Agent mitten in der Aufgabe, und der Agent ahnt nicht, dass er unterbrochen wurde; du erfährst es, wenn du das Terminal wieder öffnest und einen toten Prompt ohne Zusammenfassung vorfindest.
Ein Remote-Host behebt die physikalischen Grenzen. Eine Cloud-VM oder eine übrig gebliebene Linux-Kiste bleibt an, behält ihr Netzwerk und hat Kerne übrig für parallele Arbeit. Der Preis ist, dass der Agent jetzt irgendwo läuft, wo du ihn nicht siehst. Du SSHst dich ein, um nach ihm zu schauen, scrollst durch ein Log, um zu raten, wie weit er gekommen ist, und die Ergebnisse liegen auf dieser Kiste, bis du sie herunterkopierst.
Beides zu betreiben ist für die meisten der ehrliche Endzustand. Schnelle, interaktive Änderungen bleiben auf dem Laptop, wo du sofort Feedback bekommst, und lange oder parallele Jobs schiebst du auf den Server, wo sie eine Stunde laufen können, ohne dass du daneben sitzen musst. Der Trick ist, einen Host oder fünf wie einen einzigen Ort wirken zu lassen, statt wie eine Tabelle mit IP-Adressen.
Das DIY-Remote-Setup – und wo jeder Schritt scheitert
Der manuelle Weg ist gut bekannt. Hier die Kurzfassung, samt dem Fehlerfall, der bei jedem Schritt auftritt.
Host bereitstellen und den Agent darauf bringen:
ssh you@build-server
# install the agent's CLI, e.g. Claude Code or Codex
# authenticate it with your own subscription or API key
git clone [email protected]:your-org/your-repo.git
cd your-repo
claude
Fehlerfall: Der Agent authentifiziert sich mit deinem Konto auf einer Kiste, an die auch andere kommen könnten, und die Zugangsdaten liegen in der History und Konfiguration dieser Shell. Es gibt keine Aufzeichnung darüber, welcher Host welche Schlüssel hält.
Den Lauf über deine SSH-Sitzung hinaus am Leben halten:
tmux new -s agent
claude # start the long task
# Ctrl-b d to detach, close the laptop, reconnect later
tmux attach -t agent
Fehlerfall: tmux übersteht eine abgebrochene SSH-Verbindung, aber keinen Server-Neustart, keinen OOM-Kill und auch nicht, dass du vergisst, welche von sechs Sitzungen auf welchem von drei Servern den Lauf hält, der dir wichtig ist. Loslösen ist nicht dasselbe wie dauerhaft.
Die Ergebnisse zurückholen und sehen, was passiert ist:
scp you@build-server:~/your-repo/CHANGES.md .
ssh you@build-server 'cd your-repo && git diff'
Fehlerfall: Der Diff liegt auf der Kiste; die Begründung steckt in einem Scrollback-Puffer, der schon abgeschnitten wurde; das „Warum" ist weg. Multipliziere das mit zwei Agenten auf zwei Hosts, und du rekonstruierst den Zustand jedes Mal von Hand, wenn du nachschaust.
Keiner dieser Schritte ist schwer. Das Problem ist, dass sie sich nicht zusammensetzen lassen. Jeder neue Host und jeder neue Agent ist ein weiteres SSH-Ziel, eine weitere tmux-Sitzung, ein weiterer Ort, an dem ein Secret liegt, und ein weiteres Log, das du lesen musst, um die Frage „ist es fertig" zu beantworten.
Was ein verbundener Computer ändert
Sharkly gibt dem, was du bisher improvisiert hast, einen Namen. Ein Computer ist ein verbundenes Gerät, ein Server oder ein Container, auf dem ein Agent Arbeit ausführen kann; er stellt das Betriebssystem, die Dateien, die Zugangsdaten, den Netzwerkzugang und die Tools bereit, die der Agent braucht. Diese Definition deckt alle drei deiner Optionen ab: „Er kann ein lokaler Computer, ein Remote-Server, ein Container oder ein unterstützter Cloud-Host sein."
Du registrierst einen Host einmal, statt dich jedes Mal per SSH einzuloggen. Erzeuge auf der Zielmaschine unter Einstellungen → Computer einen einmaligen Installations-Token und führe dann aus:
sharkly computer register --install-token <install-token>
Der Token ist kurzlebig und nur einmal verwendbar, gehört also nicht in ein Image oder ein Skript. Danach läuft auf dem Computer ein lokaler Hintergrunddienst. Er registriert den Host, erkennt, welche Agent-Tools installiert sind, und meldet jedes als Runtime, sendet Heartbeats, empfängt eingeplante Läufe, bereitet Verzeichnisse vor und meldet Fortschritt und Ergebnisse zurück.
Zwei Grenzen sollte man klar benennen, denn hier liegen die typischen Fehlannahmen. Erstens: Der lokale Dienst baut die Verbindung zum Server auf, deshalb braucht ein typisches Setup keinen eingehenden Port; du öffnest deine Build-Kiste nicht ins Internet. Zweitens: Wenn ein Computer als Online angezeigt wird, heißt das nur, dass sein lokaler Dienst Heartbeats sendet. Es heißt nicht, dass die Runtime eine Task ausführen kann. Wenn ein Lauf auf einem Online-Host nicht startet, prüfe den Capability-Status der Runtime, bevor du am Netzwerk herumdrehst.
Von hier an haben die früheren Fehlerfälle eine Adresse. Zugangsdaten gehören zum Host und sind auf ihn begrenzt. Ein Lauf überlebt dein Terminal, weil der lokale Dienst ihn besitzt, nicht eine tmux-Sitzung. Und der Diff, die Zusammenfassung und die Begründung landen wieder bei der Task, statt in einem Scrollback-Puffer auf einer Kiste zu liegen, in die du dich erst per SSH einloggen musst.
Laptop, Server oder beides: Wie du dich wirklich entscheidest
Mehr Hosts sind nicht automatisch besser – entscheide dich nach der Arbeit.
Nimm deinen Laptop, wenn die Aufgabe kurz und interaktiv ist und du sie beobachten willst. Registriere ihn als persönlichen Computer und aktiviere in Sharkly Desktop „Ruhezustand verhindern", damit ein kurzer Job nicht durch den Systemschlaf abgebrochen wird. Beachte, dass „Ruhezustand verhindern" in der Desktop-App nur auf dem lokalen Rechner erscheint; auf einem geteilten oder entfernten Computer ist die Option nicht verfügbar. Wenn alles, was du ausführst, in einer Kaffeepause fertig wird und nie einen zugeklappten Deckel überstehen muss, brauchst du noch keinen Server – und einen hinzuzufügen bedeutet nur Wartung, über die du dich ärgerst.
Nutze einen Remote-Server, wenn Aufgaben lange laufen, mehr Kerne brauchen oder deinem Editor nicht die Ressourcen streitig machen sollen. Ein registrierter Linux-Host oder eine Cloud-VM bleibt standardmäßig wach und gibt parallelen Agenten Platz zum Arbeiten. Hier zahlt sich auch das Limit für gleichzeitige Tasks pro Host eines Computers sowie die Sichtbarkeit für Organisation oder Space aus: Die Kiste und ihre Zugangsdaten sind zum Teilen gedacht, und Sharkly behandelt sie auch so.
Nutze beides, wenn du interaktive Änderungen lokal und schwere Läufe remote haben willst, ohne zwei mentale Modelle pflegen zu müssen. Registriere den Laptop und den Server und weise dann jede Task dem Computer und der Runtime zu, die passen. Die Worktree-Isolierung, die parallele Agenten an Kollisionen hindert, funktioniert gleich, ob die Agenten nun einen Host teilen oder über mehrere verteilt sind – „beides" kostet dich also nur die Auswahl, nicht einen zweiten Workflow.
Wo DIY nicht mehr skaliert – und was ein Task-Board hinzufügt
Das SSH-und-tmux-Setup funktioniert für einen Agent auf einem Host. Es endet in dem Moment, in dem du mehrere Agenten auf mehreren Maschinen hast, denn es gibt keine gemeinsame Antwort auf die Frage „welcher Agent ist woran, was ist fertig, was ist fehlgeschlagen und was muss ich noch prüfen". Genau diese Frage ist der ganze Grund, mehr als einen Agent gleichzeitig laufen zu lassen, und genau die kann ein Haufen Terminals nicht beantworten.
Ein Task-Board ändert die Einheit von „einer Sitzung auf einem Host" zu „einer Task mit einem Datensatz". Agenten recherchieren, führen aus, testen und berichten; Menschen geben die Richtung vor, erteilen Befugnisse und nehmen das Ergebnis ab. Ausführung, Blocker, Ergebnisse und Folgediskussionen landen wieder in der Timeline der Task, sodass das Nachschauen bei einem Remote-Lauf bedeutet, eine Task zu öffnen – und nicht, sich per SSH in eine Vermutung einzuloggen. Automatisierung endet dort, wo das Urteil des Teams gefragt ist: Der Agent übergibt dir eine Änderung mit Zusammenfassung und Belegen, und die Entscheidung über Merge und Release bleibt bei dir.
Das ist die Grenze zwischen den beiden Ansätzen. DIY lässt den Agent remote laufen. Ein Task-Board hält Kontext, Fortschritt, Blocker, Ergebnisse und menschliche Prüfung von der Anfrage bis zum Release sichtbar, egal welcher Host die Arbeit erledigt hat.
Die Checkliste, die du heute durchgehen kannst
Arbeite diese Liste auf den Hosts ab, die du verwenden willst:
- [ ] Wähle deine Hosts ehrlich: Laptop für Interaktives, Server für Langes oder Paralleles, beides, wenn du es wirklich brauchst.
- [ ] Installiere auf jedem Host eine unterstützte Agent-Runtime und authentifiziere sie mit deinem eigenen Abo oder API-Schlüssel.
- [ ] Registriere jeden Host einmal mit
sharkly computer register --install-token <token>, statt dich für jeden Lauf per SSH einzuloggen. - [ ] Stelle sicher, dass jeder Computer Online anzeigt und mindestens eine Runtime als Available gemeldet wird; online allein führt keine Task aus.
- [ ] Setze die Sichtbarkeit des Computers auf Personal für deinen Laptop, auf Organisation oder Space für einen geteilten Server.
- [ ] Aktiviere auf dem Laptop „Ruhezustand verhindern" für Läufe, die einen zugeklappten Deckel überstehen müssen.
- [ ] Weise einem Remote-Host eine kleine, langweilige Task zu und prüfe, dass das Ergebnis bei der Task landet und nicht in einem Scrollback-Puffer.
- [ ] Nutze
sharkly computer listundsharkly daemon disk-usage, um Hosts im Blick zu behalten und Speicherplatz freizugeben.
Du kannst das Remote-Setup von Hand mit SSH, tmux und Worktrees bauen, oder du registrierst deine vorhandenen Hosts als Computer und lässt den lokalen Dienst die Läufe übernehmen. Wenn du bereits mehrere Coding-Agenten über mehr als eine Maschine laufen lässt, gibt dir Sharkly einen Ort, an dem du ihre Tasks und Ergebnisse verwaltest. Verbinde einen Computer, erstelle einen Agent und gib ihm zuerst etwas Langweiliges.
