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 und Konnektoren
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.
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 und wählen Sie 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 und beendet den Host; runtime() behandelt den Lebenszyklus der Runtime.
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.
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.
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.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.
Client::stop() nach dem Trennen der Sessions und vor dem Schließen der JSON-RPC-Verbindung und des Prozesses runtime.shutdown auf. Es 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.
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.
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. 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, 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: clientseitige Metadaten)
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.