Zum Hauptinhalt springen

RPC (Remote Procedure Call)

Im offiziellen SDK werden neuere Features über automatische Codegenerierung auf Basis von api.schema.json abgebildet. In der Laravel-Version orientiert sich die Umsetzung an den entsprechend generierten Versionen anderer Sprachen.

ServerRpc

Eine an den Client gebundene RPC-Klasse.

Verbindung, Modelle, Tools und Konten

Mit ping() und connect() prüfen bzw. starten Sie die Verbindung, und mit registerExtensionLaunchProvider() registrieren Sie einen Startprovider für Erweiterungen. Modellliste, Preiseinheiten und den integrierten Katalog erhalten Sie über models(), die Liste der verfügbaren Tools über tools(). account() behandelt Kontingente, den Authentifizierungsstatus, die Liste der angemeldeten Benutzer sowie An- und Abmeldung; accounts() ruft Tokens für Microsoft Entra ID ab.

MCP, Konnektoren und Secrets

mcp() bietet Auflisten, Hinzufügen, Aktualisieren und Entfernen von MCP-Konfigurationen, Aktivierung, Erkennung, Registry-Suche sowie Installationsplanung und -anwendung. Mit connectors() können Sie Konnektor-Funktionen, Konten und den Katalog prüfen. Serverseitige Konnektor-Operationen konzentrieren sich auf das Auflisten und Aktualisieren pro Konto. Das experimentelle secrets()->addFilterValues() registriert von Ihrem Host erzeugte dynamische Secrets im Redaction-Filter der CLI. Die CLI maskiert diese Werte anschließend in Session-Logs und Exporten.
Dieser RPC ruft keine OAuth-Token ab. Das SDK speichert die Werte nicht dauerhaft und schreibt sie auch nicht in zusätzliche Logs. Registrieren Sie Werte, die Ihr Host bereits abgerufen hat.

Skills, Plugins, Agents, Instructions und Extensions

Über jede Gruppe können Sie Elemente erkennen, verfügbare Pfade abrufen, Einstellungen ändern und neu laden. commands() liefert die Liste der integrierten Befehle, hooks() die Hook-Erkennung vor dem Sessionstart. Skills und Plugins unterstützen Aktivieren/Deaktivieren und Installationsverwaltung; Agents liefern zudem Informationen zu integrierten Agents. Extensions erkennt, aktiviert und deaktiviert persistierte Erweiterungen.

Katalog und Installation

Mit catalog() suchen Sie Kandidaten, erhalten offizielle Produktempfehlungen, wählen Kandidaten aus und rufen Feeds ab. Über die APIs für Skills, Plugins und MCP prüfen Sie Installationspläne, wenden sie an, fragen ihren Status ab oder brechen sie ab. Planen und Anwenden sind getrennte Operationen. Konkrete Installationsbeispiele finden Sie in den jeweiligen Abschnitten weiter unten.

Sessions, Host und Laufzeitumgebung

sessions() behandelt die Suche nach persistierten Sessions, das Lesen von Events, das Prüfen der Größe, Löschen und Aufräumen sowie Forks. Außerdem stehen das Erstellen und Laden von Workspaces und die Fernsteuerung zur Verfügung. host() startet den Host, veröffentlicht Sessions, listet sie auf, hebt die Veröffentlichung auf, behandelt die Authentifizierung, ändert die Zulassungsrichtlinie für Sessions und beendet den Host. Diese Host-RPCs bilden die Grundlage der High-Level-AHP-Host-API (Agent Host Protocol) des SDK. runtime() behandelt den Lebenszyklus der Runtime.

Cloud-Agent-Tasks (experimental)

cloudTasks() erstellt, löscht und ruft Tasks des Cloud-Coding-Agents ab, liest Session-Logs und Replays, ändert den Freigabestatus und ermittelt die Session, die zu einer Task-ID geöffnet werden soll. Jede Methode akzeptiert den passenden Params-Typ oder ein Array und gibt ein typisiertes DTO zurück. Ist ok im Erstellungsergebnis false, finden Sie in reason und message den Grund, aus dem der Dienst die Anfrage abgelehnt hat, und in statusCode, errorMessage und errorPayloadJson die Fehlerinformationen einer ausgeführten HTTP-Anfrage.

Git, Umgebungen, Sandbox und Richtlinien

Über git() erhalten Sie Informationen zu Branches, Arbeitsverzeichnissen und Git-Remotes; mit gitHubRepository() und gitHubOwners() können Sie GitHub-Repositorys und -Besitzer erkunden. environments() behandelt Mission-Control-Umgebungen, sandbox() und sandboxProxyCa() die Sandbox-Unterstützung und die Proxy-CA, contentExclusion() die Prüfung von Ausschlussrichtlinien und managedSettings() sowie userSettings() die Einstellungen. Mit settings() entfernen Sie einzelne Schlüssel aus einer Einstellungsdatei und maskieren Werte für die Anzeige. gitHubRepository()->getById() ermittelt Owner und Name aus einer GitHub-Repository-ID, und lookupBranchPullRequest() durchsucht die angegebenen Repositorys in Prioritätsreihenfolge nach einem Pull Request vom angegebenen Head-Owner und Branch. Beide übernehmen authInfo unverändert. Das Ergebnis von getById() enthält Owner und Name in repository oder null, wenn das Repository nicht gefunden wird. Der status der Pull-Request-Suche ist found, no-token, no-pr oder lookup-failed. Unbekannte Werte bleiben als Strings erhalten und lösen daher keine Exception aus. pullRequest ist ein assoziatives Array, wenn ein Pull Request gefunden wurde, andernfalls null.
gitHubFetch() bietet authentifizierte GitHub-API-Anfragen und benannte Operationen, gitHubRelease() die Suche nach Releases, Snapshots, Asset-Downloads und Fortschrittsabfragen. Bei Fetch wählt sessionId die Authentifizierung einer Session aus. Ohne Angabe wird die Authentifizierung des Prozesses verwendet. Geben Sie authOwnerId an, um eine vom Host verwaltete Authentifizierungsbindung zu verwenden. Bei Release wählt authInfo von der Runtime verwaltete Anmeldedaten aus, und öffentliche Releases können anonym gesucht und heruntergeladen werden. Löschen Sie den heruntergeladenen path nach der Verwendung selbst. allocateRequestId(), request() und executeOperation() von Fetch sowie abandonRequest(), getSnapshot() und downloadAsset() von Release können nicht aus Extensions aufgerufen werden. Das Laravel SDK stellt derzeit das cancel-RPC keiner der beiden Gruppen bereit, daher können Sie laufende Operationen nicht über das SDK abbrechen. abandonRequest() verwirft eine nicht verwendete Release-Request-ID und stoppt keine laufende Operation.

Lokale Modelle, HTTP-Inferenz und Dateisystem

azureMl() bietet Katalog, Auflösung und Download lokaler Modelle sowie Statusabfrage, Abbruch und Löschen. llmInference() ist eine experimentelle API, die HTTP-Anfragen der Modellschicht an die Clientseite weiterleitet. sessionFs() registriert einen Dateisystem-/SQLite-Callback-Provider für Sessions.

Netzwerk-Callbacks (experimental)

network()->setProvider() teilt der Runtime die auf dem Client registrierten Callbacks für Proxy-Auflösung und Kerberos-Authentifizierung mit. Normalerweise registriert die Option network des Client sie automatisch, sodass Sie dieses RPC nicht direkt aufrufen müssen. Die Callback-Felder von NetworkSetProviderRequest geben an, dass der entsprechende Handler registriert ist. Das RPC gibt keinen Wert zurück. Die Runtime muss das RPC network.setProvider unterstützen. Andernfalls löst der Client beim Start eine Exception aus, die Sie auffordert, die Runtime zu aktualisieren. Details finden Sie unter Authentifizierung.
scope ist standardmäßig connection. runtime deckt zusätzlich die gemeinsame Hintergrundkommunikation ab, allerdings kann sich nur eine Verbindung gleichzeitig mit diesem Scope registrieren.

Interne und experimentelle RPCs

Die folgenden RPCs sind im offiziellen SDK als intern markiert, Laravel stellt sie jedoch als @experimental bereit. Sie können sich künftig ändern oder entfernt werden, und die Aufruferbeschränkungen der Runtime gelten weiterhin. Damit können Sie Einträge der Agent-Registry anlegen, auflisten und entfernen, eine Authentifizierungs-URL im Browser öffnen, abgelaufene große Tool-Ausgaben bereinigen und Warnungen zu Sandbox-Pfadfreigaben abrufen. Listenergebnisse enthalten keine Verbindungsanmeldedaten.

Einfaches Aufrufbeispiel

Auch Funktionen, die ursprünglich bereits im SDK enthalten waren, wurden in der automatisch generierten Version erneut hinzugefügt.

Anwendungsbeispiele nach Funktion

Im Folgenden finden Sie typische Aufrufbeispiele für die oben genannten Funktionen.

Agent-Plugin-Katalogkandidaten

Wenn Sie bei catalog.search die Capability agent-plugin-discovery anfordern und in den zu durchsuchenden kinds den Wert plugin angeben, erhalten Sie Agent-Plugin-Kandidaten. Um neben dem Standardformat application/vnd.github.copilot-plugin auch application/vnd.anthropic.claude-plugin+json und application/agent-plugin+json zu empfangen, fordern Sie zusätzlich zu agent-plugin-discovery auch agent-plugin-formats an. agent-plugin-confirmed-installation ist eine Capability, die die Installierbarkeit und einen Plan zur Überprüfung zurückgibt; auch sie wird zusammen mit agent-plugin-discovery angefordert. Wenn sie erlaubt ist, enthalten Kandidaten installability mit einem der Werte installable, install-data-unavailable, feature-disabled oder not-installable-kind. installPlan ist nur enthalten, wenn installability den Wert installable hat. Der Plan dient lediglich der Überprüfung; dieser Catalog-RPC führt niemals eine Installation aus. Die sources des Plans enthalten Kandidaten in der Prioritätsreihenfolge materialization, marketplace, repository. Für Marketplace werden Name und Repository erfasst, für ein direktes Repository das Repository und ein optionaler Pfad. In einem Plan, der nur aus materialization besteht, wird pluginName weggelassen und components ist leer. Prüfen Sie Namen und tatsächlich installierte Inhalte in der von plugins.planInstall() zurückgegebenen Review. Für ausgewählte Kandidaten können Sie mit plugins.planInstall() einen nebenwirkungsfreien, validierten Plan erstellen. plugins.applyInstall() fordert vom Benutzer eine ausdrückliche Bestätigung an und wendet den Plan an, wenn sie erteilt wird. Nach der Anwendung wird das Plugin im deaktivierten Zustand registriert. Die mcpServers der Review zeigen die von den validierten Dateien deklarierten Servernamen, den Transport und bei Remote-Servern den Host. Dies ist keine Sicherheitsgarantie; der Benutzer sollte den Inhalt prüfen, bevor er ausdrücklich bestätigt. Die description installierter Plugins stammt aus dem Manifest. verifiedSource gibt das GitHub-Repository und einen festen Commit an und ist nur bei direkten, an einen Commit gebundenen Installationen vorhanden. iconUrl ist externer, nicht vertrauenswürdiger Inhalt; senden Sie beim Abrufen keine Authentifizierungsdaten oder GitHub-Anmeldeinformationen. Anmeldeinformationen selbst werden nicht als Ablehnungsgrund zurückgegeben. Bei network-failure im Installationsergebnis können Sie CatalogNetworkFailureReason, den HTTP-statusCode, ein optionales retryAfterSeconds und eine sicher anzeigbare message prüfen.
Um aus einer Materialisation Reference von Agent Finder zu planen, verwenden Sie catalog.planInstallFromReference(). Das outcome->kind des Ergebnisses ist entweder plugin-install-planned, skill-install-planned oder refused. Übergeben Sie Plugin-Pläne an plugins.applyInstall() und Skill-Pläne an skills.applyInstall().

contentExclusion

Vor dem Erstellen einer Session können Sie das JSON einer Content-Exclusion-Richtlinie validieren.
policiesJson wird als ungeparster JSON-String an die CLI übergeben. Schlägt das Parsen des JSON oder die Schemavalidierung fehl, tritt ein RPC-Fehler der CLI (JsonRpcException) auf. Dies ist ein RPC im Server-Scope, der die Richtlinie selbst validiert. Um Pfade im Arbeitsverzeichnis einer Session gegen die tatsächlichen Ausschlussrichtlinien zu prüfen, verwenden Sie das Session-bezogene contentExclusion()->checkPaths().

managedSettings (experimental: verwaltete Einstellungen)

Liest verwaltete Einstellungen, löst Richtlinien auf, ruft das Schema ab, validiert, erstellt eine Vorschau der Zusammensetzung und verwirft den Cache.

settings (experimental: Operationen an Einstellungsdateien)

Entfernen Sie einen bestimmten Schlüssel aus einer Einstellungsdatei und ersetzen Sie geheime Werte für die Anzeige. removeRawKey() entfernt Schlüssel unverändert, auch solche, die keine kanonischen Einstellungspfade sind, etwa Schlüssel, die nicht geladen werden konnten. Kann die Datei nicht geparst werden, überschreibt die CLI sie nicht und status ist invalid. redactValueForDisplay() ersetzt geheime Werte anhand der mit basePath angegebenen Position im Einstellungsbaum durch Platzhalter, sodass Sie den Wert Benutzern anzeigen oder in Logs schreiben können.

Lebenszyklus von Runtime und Host (experimental)

host.unpublishSession() zieht eine Application-Publication von einem eigenen, laufenden Host zurück. Das Zurückziehen der Veröffentlichung löscht oder stoppt weder den ursprünglichen Session-Verlauf noch Worktrees oder laufende Arbeiten. Ist die Session bereits nicht veröffentlicht, ist unpublished gleich false; andere Publications als application führen zu einem Fehler.
host.dispose() beendet den Host-Listener mit der angegebenen hostId.
host.setSessionCreationPolicy() legt fest, ob ein laufender Host neue Remote-Sessions annimmt. Die Änderung trennt keine bestehenden Clients und gilt nur für spätere Zulassungen.
Bei einer vom SDK gestarteten stdio-Runtime ruft Client::stop() nach dem Trennen der Sessions und vor dem Schließen der JSON-RPC-Verbindung und des Prozesses runtime.shutdown auf. Das Trennen der Sessions (session.detach) teilt sich über alle Sessions hinweg eine gemeinsame Frist von 10 Sekunden. Ein Trennvorgang, der die Frist überschreitet, wird als Fehler in den Rückgabewert aufgenommen, und der Stoppvorgang wird fortgesetzt. Außerdem wird bis zu 10 Sekunden auf den Abschluss der Runtime-Bereinigung gewartet; bei einem Fehler wird dieser in den Rückgabewert aufgenommen und der restliche Stoppvorgang fortgesetzt. Bei Verbindungen zu externen Runtimes wie cli_url wird dieser RPC nicht aufgerufen, damit die gemeinsam genutzte Runtime nicht beendet wird. Wenn die CLI die zugehörige Anfrage nicht ermitteln kann und einen JSON-RPC-Fehler mit id: null zurückgibt, schlagen alle laufenden Anfragen mit einer JsonRpcException fehl. Die Exception enthält eine Diagnosemeldung, aus der zitierte Werte entfernt wurden und deren Länge begrenzt ist. Die Verbindung bleibt geöffnet. Da die CLI die Anfrage möglicherweise bereits verarbeitet hat, wiederholen Sie sie nicht automatisch, ohne sicherzustellen, dass dies unbedenklich ist. Das SDK weist ausgehende Anfragen mit mehr als 127 Verschachtelungsebenen, die die CLI nicht lesen kann, bereits vor dem Senden zurück. Zu tief verschachtelte Handler-Antworten ersetzt es durch einen JSON-RPC-Fehler.

SessionRpc

Eine an die Session gebundene RPC-Klasse. Damit ist auch die Nutzung des Planmodus möglich, die mit früheren SDK-Versionen nicht möglich war.

Modell, Modus, Name und Plan

Mit model() prüfen und wechseln Sie das aktuelle Modell und legen reasoning effort, Auto-Tier und erlaubte Modelle fest. mode() behandelt den Modus, name() den Session-Namen und plan() das Lesen und Schreiben des Plantexts und der SQLite-Todos.

Workspace, Instructions und LSP

workspaces() bietet Auflisten, Lesen, Schreiben, Verschieben und Löschen von Dateien sowie Verzeichnisoperationen. Mit instructions() rufen Sie Instructions ab, laden sie neu und erkennen sie; mit lsp() initialisieren Sie die Language-Server-Konfiguration.

Autopilot-Ziel

autopilotObjective()->getState() gibt den aktuellen Zustand des Autopilot-Ziels der Session als typisiertes Objekt zurück. Wenn kein Ziel existiert, ist state gleich null. Diese API unterscheidet sich von workspaces()->autopilotObjectiveExists(), das prüft, ob im Workspace ein Ziel gespeichert ist.
Mit setStayInAutopilot() unterdrücken Sie die Anforderung, beim Abschluss oder Pausieren eines Objectives in den interaktiven Modus zurückzukehren. Die Einstellung wird im Speicher des Clients gehalten und ist standardmäßig true. Übergeben Sie false als value, um die Unterdrückung aufzuheben. Setzen Sie sie nach einer erneuten Verbindung erneut.

Agents, Fleet und Hintergrundaufgaben

Mit agent() listen Sie Agents auf, wählen sie aus und laden sie neu; mit fleet() starten Sie eine Fleet. tasks() behandelt die Registrierung von Hintergrund-Agents und clientseitigen Tasks, das Abrufen und Aktualisieren des Fortschritts, Migration, das Senden von Nachrichten, Abbruch und Löschen.

MCP, Plugins, Extensions und Workflow

mcp() behandelt das Auflisten, Starten, Stoppen und Neuladen von Servern, Tools, Prompts und Ressourcen, OAuth, Sampling sowie das Aktualisieren dynamischer Header. plugins() und extensions() verwalten den Zustand innerhalb der Session, customizations() lädt Anpassungen neu. Mit workflow() führen Sie Workflows aus und fragen sie ab; über diagnostics() und connectors() erhalten Sie Diagnoseinformationen und Konnektoren.

Tools, Permissions, Commands und UI

tools() und permissions() behandeln Antworten auf ausstehende, per Event eingegangene Anfragen sowie Einstellungen. permissions()->clearResumeEscalation() hebt die beim Fortsetzen aus dem Verlauf wiederhergestellte Berechtigungseskalation im Speicher auf und gibt ein typisiertes Erfolgsergebnis zurück. commands() bietet Befehlsliste, Ausführung und Event-Antworten, ui() Antworten auf Anfragen wie Benutzereingaben, Elicitation und Planfreigaben. completions() ruft Eingabevorschläge ab.

Accounts, Authentifizierung und Providers

accounts() behandelt das Aufzählen von Konten, Providern und angemeldeten Konten über enumerate(), get() und set() sowie die interaktive Anmeldung über begin(), advance() und cancel(). gitHubAuth() behandelt den Authentifizierungsstatus und die Anmeldeinformationen der Session, provider() und providers() Modellendpunkte und Provider-Adapter, connectors() die Konnektorverbindungen der Session.

Verlauf, Warteschlange, Logs und Nutzung

history() bietet Komprimieren (einschließlich der Komprimierungseinstellungen), Unterbrechen, Übergabezusammenfassungen und Kürzen der Unterhaltung, queue() Einfügen, Verschieben, Bearbeiten, Löschen und sofortiges Senden ausstehender Einträge. log(), eventLog(), usage(), quota() und limitPrediction() behandeln Logs, Events, Nutzung und Limitinformationen. Mit schedule() können Sie geplante Prompts prüfen und stoppen.

Lebenszyklus, Remote und Host-Integration

sendMessages() führt mehrere Nachrichten in einem Turn aus, mit suspend() und shutdown() stoppen Sie die Session. interruptMainTurn() steuert den Haupt-Turn und cancelAllBackgroundAgents() die Hintergrund-Agents separat. remote() und visibility() behandeln Remote-Veröffentlichung und Freigabestatus, sandbox() die Sandbox der Session, managedSettings() verwaltete Einstellungen im Session-Scope, contentExclusion() die Pfadprüfung, metadata() clientseitige Metadaten und canvas() die Canvas-Integration.

debug (experimental)

Mit debug()->collectLogs() können Sie Event-Logs, Prozess-Logs und Shell-Logs einer Session in einem .tgz-Archiv oder einem Verzeichnis sammeln. Vertrauliche Informationen in den Logs werden standardmäßig geschwärzt. Mit additionalEntries können Sie weitere Dateien oder Verzeichnisse hinzufügen, und für redaction können Sie plain-text, events-jsonl oder none angeben. Bei none erfolgt keine Schwärzung; achten Sie daher auf die hinzugefügten Inhalte.
Mit DebugCollectLogsDestination::directory('/tmp/copilot-debug') können Sie in ein Staging-Verzeichnis ausgeben. Mit include geben Sie einzeln an, welche Logs und Referenzpfade gesammelt werden, und anhand von entries und skippedEntries im Ergebnis prüfen Sie die gesammelten Inhalte. Die Pfade für Ziel und zusätzliche Einträge sind Pfade auf der CLI-Serverseite. In der Standardkonfiguration, in der die CLI über stdio gestartet wird, ist dies derselbe Host wie die App; wenn Sie sich jedoch per TCP mit einem CLI-Server auf einem anderen Host verbinden, geben Sie Pfade auf der Serverseite an, nicht auf dem aufrufenden Rechner.

contentExclusion (experimental)

Sie können prüfen, ob lokale absolute Pfade im Arbeitsverzeichnis der Session einer Content-Exclusion-Richtlinie unterliegen. Rufen Sie dies auf, bevor Sie Dateiinhalte lesen oder anhängen.
checkPaths() akzeptiert nur absolute Pfade, und die Pfade müssen im Arbeitsverzeichnis der Session liegen. checks wird in derselben Reihenfolge wie die Eingabe zurückgegeben; doppelte Pfade bleiben erhalten. Wenn ein Pfad, ein Dateisystem oder die Richtlinienauswertung nicht unterstützt wird bzw. nicht verfügbar ist, werden available: false und leere checks zurückgegeben. In diesem Fall gibt isExcluded() immer true zurück; behandeln Sie daher alle Pfade als ausgeschlossen. Auch bei available: true werden Pfade, die nicht im Ergebnis enthalten sind, sicherheitshalber als ausgeschlossen bewertet.

MCP Apps (experimental)

Über $session->rpc()->mcp()->apps() können Sie RPCs für MCP Apps aufrufen. Bei listTools() und callTool() ist der Name des aufrufenden MCP-Servers originServerName erforderlich. Das Ergebnis von callTool() wird als MCP-Ergebnis in freier Form zurückgegeben.
readResource() gibt Ressourcendaten wie HTML zurück. Das SDK übernimmt weder das Rendern im Browser noch iframe-Operationen; das Rendern der abgerufenen Inhalte liegt in der Verantwortung der aufrufenden Anwendung.

Anwendungsbeispiele nach Funktion

Im Folgenden finden Sie typische Aufrufbeispiele für die oben genannten Funktionen.

remote (experimental: Unterstützung für Remote-Sessions)

Details finden Sie unter Remote Sessions.

sandbox (experimental: Sandbox-Steuerung)

Rufen Sie dies im Berechtigungs-Handler auf, wenn $request['sandboxPathGrant'] vorhanden ist, und zwar mit der requestId der betreffenden ausstehenden Anfrage. Da dieser RPC selbst auf die Berechtigungsanfrage antwortet, geben Sie bei Erfolg PermissionDecision::noResult() zurück, damit keine normale Antwort gesendet wird.

metadata (experimental: Session-Informationen)

Lokale Session-Verwaltung (experimental)

Mit $session->rpc()->management() konfigurieren, listen, erstellen, benachrichtigen und schließen Sie lokale Sessions, die im selben Konfigurationsverzeichnis der Verwaltung zugestimmt haben. Registrieren Sie mit setSessionCreationHandler() einen Host-Callback, um das Reverse-RPC von create() zu empfangen. Der Callback muss die Child-Session mit newSessionId erstellen, ihre Berechtigungs- und Modellbeschränkungen beibehalten und ein SessionManagementCreateResult zurückgeben. Im folgenden Beispiel ist $sessionCreationHandler eine Closure, die ein SessionManagementCreateHostRequest empfängt, die Child-Session auf dem Host erstellt und ein SessionManagementCreateResult zurückgibt.
accepted von message() bedeutet, dass die Nachricht zur Zustellung angenommen wurde, nicht dass das Ziel geantwortet oder seine Aufgabe abgeschlossen hat. Nachdem Sie separat geprüft haben, dass eine Child-Session ihre Arbeit abgeschlossen hat, schließen Sie mit close() nur die von Ihnen erstellten Children. Der gespeicherte Verlauf wird nicht gelöscht.

Session canvas

Canvas-RPCs rufen Sie über $session->rpc()->canvas() auf. list() gibt die Liste in canvases von CanvasList zurück, listOpen() in openCanvases von CanvasListOpenResult. open() gibt OpenCanvasInstance zurück, und Action-Aufrufe geben CanvasActionInvokeResult zurück. close() hat keinen Rückgabewert.
Reverse-RPCs des Canvas-Providers (canvas.open / canvas.close / canvas.action.invoke) werden über canvasHandler in SessionConfig / ResumeSessionConfig verarbeitet. Das Rendern des Canvas liegt in der Verantwortung der Host-UI.

workflow

Auch die experimentellen RPC-APIs für Workflows, Konnektoren, Diagnosen usw., die mit Copilot CLI 1.0.89 hinzugekommen sind, stehen über SessionRpc zur Verfügung. Diese variablen Protokoll-Payloads werden als JSON-kompatible Arrays übergeben, und auch die Antworten werden als Arrays zurückgegeben. Jedem Aufruf wird automatisch die aktuelle sessionId hinzugefügt.
workflow() ruft die von der CLI bereitgestellten Low-Level-RPCs auf. Eine High-Level-API wie im Node.js SDK, mit der PHP-Closures als Workflows registriert und ausgeführt werden, wurde bei dieser Synchronisierung nicht hinzugefügt. Diese neuen RPC-Gruppen hängen von der CLI-Version ab und sind experimentell; verwenden Sie sie daher nur mit einer passenden CLI.

SessionFS-Callback-Typen

Für Dateisystemoperationen im Session-Scope sind Callback-Typen (Request/Result) definiert. Dies sind die Request-/Response-Typen, die verwendet werden, wenn die Copilot CLI den Client per Callback aufruft. SessionFsStatResult / SessionFsReaddirResult / SessionFsReaddirWithTypesResult haben ein optionales error (SessionFsError) für den Fehlerfall.

SessionFs-Handler

Der Client leitet neben sessionFs.readFile / readFileBytes / writeFile / writeFileBytes auch die Anfragen appendFile, exists, stat, mkdir, readdir, readdirWithTypes, rm, rename, sqliteQuery, sqliteTransaction und sqliteExists an den Provider der Session weiter. Fehler bei Dateioperationen werden als error mit ENOENT (ENOENT oder errno 2) / UNKNOWN zurückgegeben. exists gibt bei einer Exception false zurück, stat bei einem Fehler Nullwerte plus error. Vom Provider nicht unterstützte Operationen führen zu einem UNKNOWN-Fehler (bei SQLite-Operationen zu einem JSON-RPC-Fehler). Exceptions in sqliteQuery/sqliteExists werden als JSON-RPC-Fehler zurückgegeben, Fehler in sqliteTransaction als error im Ergebnis (mit errorClass). Die Provider-Interfaces (SessionFsFilesystemProvider, SessionFsSqliteCapableProvider, SessionFsSqliteProvider, SessionFsSqliteTransactionProvider) wurden als separate Interfaces hinzugefügt, um das bisherige SessionFsProvider (2 Methoden) nicht zu brechen.

SQLite-Callback-Typen

Um die SQLite-Unterstützung zu aktivieren, übergeben Sie SessionFsSetProviderCapabilities(sqlite: true) an capabilities von SessionFsSetProviderRequest.
Normalerweise rufen Sie diesen RPC nicht direkt auf: Wenn Sie die Client-Option sessionFs (oder session_fs in config/copilot.php) angeben, sendet Client::start() sessionFs.setProvider genau einmal. Sessions benötigen createSessionFsProvider (siehe SessionConfig). Das Enum SessionFsSqliteQueryType (src/Enums/) beschreibt den Abfragetyp:
  • Exec: DDL/mehrere Statements (kein Ergebnis)
  • Query: SELECT (gibt Zeilen zurück)
  • Run: INSERT/UPDATE/DELETE (gibt rowsAffected zurück)
Diese Typklassen befinden sich unter src/Types/Rpc/.

Argumente als Array angeben

Sowohl Argumente als auch Rückgabewerte nutzen dedizierte Klassen; die Argumente lassen sich jedoch auch als Array übergeben.

Testing

Da Copilot::fake() hier nicht als Mock funktioniert, verwenden Sie stattdessen Copilot::expects('client') oder Copilot::expects('start').
Aktuelle Informationen finden Sie im GitHub-Repository.
Zuletzt geändert am 9. November 2026