Wie Claude einen osFoundry-Graph auf deinem Desktop startet und auf das Ergebnis wartet

Am Ende startet ein Claude-Chat einen deiner gespeicherten osFoundry-Graphs, also die mehrstufigen Agentenprogramme, die verzweigen, parallel auffächern und Fehlversuche wiederholen. Der Run läuft auf deinem eigenen Desktop, nicht in Claude und nicht auf einem Server. Claude bekommt sofort ein Ticket zurück, fragt den Stand ab, während der Desktop arbeitet, und antwortet mit dem Ergebnis des Graphs. Überlegst du es dir mittendrin anders, kann Claude den Run abbrechen.

Wer macht was

	Claude	osFoundry
Login	Dein Claude-Konto, unverändert	Die Verbindung, die du freigegeben hast, einem Projekt hinzugefügt
Was es sieht	Name, Beschreibung, Slug, Version und Status jeder geteilten Graph-Session	Das Programm des Graphs, seine Agenten und deine Dateien bleiben auf dem Desktop
Welche Graphs	Wählt aus list_graph_sessions	Nur Sessions, die du für dieses Projekt in der Desktop-App angehakt hast
Wo es läuft	Nirgends. Claude stellt nur in die Warteschlange und liest	Auf deinem Desktop, der den wartenden Run abholt und lokal ausführt
Warten	Ruft get_graph_run auf, bis der Status endgültig ist	Meldet ein begrenztes Ergebnis, wenn der Run endet
Freigaben	Claudes eigene Tool-Abfrage vor run_graph_session	Tools, die jedes Mal fragen sollen, werden im Run abgelehnt; niemand ist da, um zu klicken

Einrichtung

Vorausgesetzt ist, dass der Claude-Connector schon existiert (Schlüssel-Icon → Connected → Add assistant, danach https://api.osfoundry.io/api/v1/external-mcp in Claude als benutzerdefinierter Connector hinzugefügt).

1. Eine gespeicherte Graph-Session auf dem Desktop haben

Graphs leben auf dem Gerät. Du schreibst oder bearbeitest sie über Maestro, einen Agenten oder osStudio, und jeder gespeicherte bekommt eine Session-ID, die aus gs_ plus 32 Hex-Zeichen besteht. Der Graph-Bildschirm der Desktop-App listet sie auf. Einen Graph, den du nur im Browser gesehen hast, kannst du nicht teilen, weil der Browser ihn nicht ausführen kann.

Beispiel: Der Graph-Bildschirm der Desktop-App mit gespeicherten Graph-Sessions

2. Die Claude-Verbindung einem Projekt hinzufügen

Unter Schlüssel-Icon → Connected wählst du die Claude-Verbindung. Unter Projects suchst du ein Projekt aus und klickst auf Add to project (zum Projekt hinzufügen). Nur in diesem Projekt sucht Claude nach Graphs.

Beispiel: Der Bereich Projects einer Claude-Verbindung, mit einem hinzugefügten Projekt

3. Die Graph-Session in dieses Projekt teilen

Weiter unten im selben Connected-Tab, nur in der Desktop-App, gibt es den Bereich Share desktop Graph sessions (Desktop-Graph-Sessions teilen). Dort steht jedes Projekt, das dir gehört, mit den auf diesem Gerät gespeicherten Graph-Sessions als Checkboxen:

Share desktop Graph sessions
Choose the saved Graph sessions to share with each project, then enable that project.
Your desktop must be open and signed in.

Launch plan · workspace                      [ Share selected Graphs ]
  [x] Weekly KPI digest
  [ ] Release notes draft

Beispiel: Share desktop Graph sessions mit einer angehakten Session für ein Projekt

Hake zuerst die Sessions an und klick dann auf Share selected Graphs. Ist nichts angehakt, hält dich die App mit "Choose at least one Graph session for this project first." auf. Ein Projekt zu teilen teilt nicht jeden Graph auf dem Gerät. Jede Session ist eine eigene Entscheidung, pro Projekt.

4. Den Desktop offen lassen

Die Desktop-App prüft das Projekt alle 20 Sekunden auf wartende Runs, und sofort, wenn du änderst, was geteilt ist. Ist die App geschlossen, wartet Claudes Anfrage in der Warteschlange, bis sie wieder geöffnet wird.

5. Claude fragen

In osFoundry, run the Weekly KPI digest Graph in the Launch plan project
for week 2026-W45, and tell me the three biggest changes.

Ein echter Run

Projekt, Graph und Zahlen unten sind Beispieldaten. Die Tool- und Argumentnamen sind die, die der Live-Server in tools/list auflistet. In Claude Code erscheinen dieselben Tools als mcp__osfoundry__run_graph_session und so weiter.

Beispiel

Claude → list_granted_resources {}
       ← projects: Launch plan
Claude → list_graph_sessions {"project_id": "<Launch plan>"}
       ← Weekly KPI digest  (gs_3f…, weekly-kpi-digest v3, ready)
         Release notes draft fehlt: Es wurde nie angehakt
Claude → run_graph_session {"graph_session_id": "gs_3f…",
                            "arguments": {"week": "2026-W45"},
                            "idempotency_key": "kpi-2026-w45-a"}
       [Claude bittet dich, diesen Tool-Aufruf zu erlauben → Allow]
       ← command_id "8c1e…", status queued
Claude → get_graph_run {"command_id": "8c1e…"}
       ← queued            (der Desktop hat noch nicht abgefragt)
Claude → get_graph_run {"command_id": "8c1e…"}
       ← running
Claude → get_graph_run {"command_id": "8c1e…"}
       ← completed
         result: {"execution_id": "GR-0007L", "status": "completed",
                  "result": {...}, "total_tokens": 18412, "reported_cost": 0.07}

Claude: Woche 45: Anmeldungen +18 %, Trial-zu-Paid sinkt von 9.1 % auf 7.4 %,
        und die Support-Tickets haben sich nach dem Release am Dienstag verdoppelt.

Dass das erste get_graph_run queued meldet, ist keine Verzögerung auf Claudes Seite. Nichts wird auf deinen Desktop gepusht. Der Desktop fragt den Server nach Arbeit, und bis zur nächsten Abfrage wartet der Run einfach. Sobald er abgeholt ist, führt der Desktop den Graph mit demselben Befehl aus, den auch der Graph-Bildschirm nutzt, und schickt das Ergebnis zurück. Was Claude zuletzt liest, ist dieses zurückgeschickte Ergebnis, kein Live-Stream.

Der Run wird auf dem Desktop außerdem unter dem Projekt Launch plan abgelegt. Projektkontext und die Suche im Chatverlauf nutzen im Run dieses Projekt und nichts darüber hinaus.

Zum Stoppen ruft Claude cancel_graph_run mit derselben command_id auf. Ein Run, der noch wartet, wird direkt abgebrochen und startet nie. Ein laufender bekommt eine Abbruchanfrage, die der Desktop alle 3 Sekunden prüft und an den laufenden Graph weitergibt.

Wo die Grenze liegt

Der Graph verlässt das Gerät nicht. list_graph_sessions liefert nur Metadaten: Name, Beschreibung, Slug, Version und Status. Claude sieht nie das Skript, die Agenten, die es aufruft, oder die Dateien, die sie anfassen. Deshalb übergibt Claude arguments auch, ohne ein Schema zu sehen. Beschreib die Eingaben in der Beschreibung des Graphs, wenn Claude sie gut ausfüllen soll.

Die Ausführung ist Sache des Desktops, weil die Agenten des Graphs, lokale Modelle, Ordner und Freigabeeinstellungen alle dort liegen. Der Server hält nur die Warteschlange und das Endergebnis. Ist der Desktop offline, warten die Runs auf ihn. Claude kann sie nirgendwo anders hinschicken.

Im Run schaut niemand zu. Tools, die jedes Mal fragen sollen, werden abgelehnt statt nachzufragen, denn eine Abfrage, die niemand beantwortet, würde den Run minutenlang aufhalten und dann trotzdem scheitern. Tools, die nicht fragen, laufen normal. Hängt ein Graph an einem Tool, das du von Hand freigibst, starte diesen Graph selbst über den Graph-Bildschirm.

Was zurückkommt, ist begrenzt. Das Ergebnis besteht aus Run-ID, Status, Ergebnis, Token-Anzahl und gemeldeten Kosten, und das nur, wenn es in 100,000 Zeichen JSON passt. Ein größeres Ergebnis kommt als ID und Status mit result_truncated: true zurück, der vollständige Eintrag bleibt im Run-Verlauf auf dem Desktop. Fehler werden bei 2,000 Zeichen abgeschnitten.

Nur der Agent, der einen Run gestartet hat, kann ihn lesen oder abbrechen. Eine andere Verbindung, die dieselbe command_id abfragt, bekommt "Graph run not found or access removed", dieselbe Antwort wie bei einer ID, die es nicht gibt.

Das Teilen lässt sich jederzeit rückgängig machen, bevor der Run startet. Nimmst du den Haken bei der Session weg oder klickst auf Stop sharing (Teilen beenden), während ein Run wartet, prüft der Desktop vor dem Ausführen erneut und bricht ihn mit "Graph session is no longer shared with this project" ab.

Als Nächstes

Teile einen kleinen Graph, lass Claude ihn starten, klick dann auf Stop sharing, solange er noch wartet, und sieh zu, wie Claude den Abbruch meldet. Wie osFoundry Arbeit überhaupt auf Agenten verteilt, steht auf der Seite zur Maestro-Orchestrierung, die Liste der Verbindungen selbst auf der Connected-Seite.