RPC (Remote Procedure Call)
Im offiziellen SDK werden neuere Features über automatische Codegenerierung auf Basis vonapi.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
Mitping() 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.
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
Mitcatalog() 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
Übergit() 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
Anwendungsbeispiele nach Funktion
Im Folgenden finden Sie typische Aufrufbeispiele für die oben genannten Funktionen.Agent-Plugin-Katalogkandidaten
Wenn Sie beicatalog.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.
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.
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
Mitmodel() 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.
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
Mitagent() 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)
Mitdebug()->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.
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)
sandbox (experimental: Sandbox-Steuerung)
$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.
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 überSessionRpc 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 nebensessionFs.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.
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)
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
DaCopilot::fake() hier nicht als Mock funktioniert, verwenden Sie stattdessen Copilot::expects('client') oder Copilot::expects('start').
Aktuelle Informationen finden Sie im GitHub-Repository.