Skip to main content

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 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

Mit catalog() 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

Ü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.

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

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.

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.
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. 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

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.

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. 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)

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: 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.
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 19. Oktober 2026