RPC (Remote Procedure Call)
Dans le SDK officiel, les nouveautés récentes s’appuient sur une génération de code automatique à partir deapi.schema.json. La version Laravel s’inspire des versions générées dans d’autres langages pour proposer une implémentation similaire.
ServerRpc
Classe RPC associée au Client.Connexion, modèles, outils et compte
ping() et connect() permettent de vérifier et d’établir la connexion, et registerExtensionLaunchProvider() enregistre un provider de lancement d’extensions. La liste des modèles, les unités de prix et le catalogue intégré s’obtiennent via models(), et la liste des outils disponibles via tools(). account() gère le quota, l’état d’authentification, la liste des utilisateurs connectés ainsi que la connexion et la déconnexion, tandis que accounts() permet d’obtenir des tokens Microsoft Entra ID.
MCP et connecteurs
mcp() permet de lister, ajouter, mettre à jour et supprimer la configuration MCP, de l’activer, de détecter des serveurs, de rechercher dans le registre, ainsi que de planifier et d’appliquer des installations. connectors() permet de consulter les fonctionnalités des connecteurs, les comptes et le catalogue. Côté serveur, les opérations sur les connecteurs portent principalement sur la consultation et la mise à jour par compte.
Skills, Plugins, Agents, Instructions et Extensions
Chaque groupe permet d’effectuer la découverte, d’obtenir les chemins disponibles, de modifier la configuration et de recharger.commands() fournit la liste des commandes intégrées, et hooks() la découverte des hooks avant le démarrage d’une session. Les Skills et les Plugins prennent en charge l’activation, la désactivation et la gestion des installations ; les Agents permettent aussi d’obtenir les informations sur les agents intégrés. Les Extensions permettent de découvrir, d’activer et de désactiver les extensions persistées.
Catalogue et installation
catalog() permet de rechercher des candidats, de les sélectionner et d’obtenir des flux ; les API Skills, Plugins et MCP permettent de vérifier un plan d’installation, de l’appliquer, d’en consulter l’état ou de l’annuler. La planification et l’application sont des opérations distinctes. Pour des exemples concrets d’installation, consultez les sections correspondantes plus bas.
Sessions, hôte et environnement d’exécution
sessions() gère la recherche des sessions persistées, la lecture des événements, la vérification de la taille, la suppression et le nettoyage, ainsi que le fork. La création et le chargement de Workspaces ainsi que le contrôle à distance sont également disponibles. host() permet de démarrer un hôte, de publier, lister et retirer la publication de sessions, et de détruire l’hôte ; runtime() gère le cycle de vie du runtime.
Git, environnements, sandbox et politiques
git() permet d’obtenir les informations sur les branches, le répertoire de travail et les remotes Git, et gitHubRepository() et gitHubOwners() permettent d’explorer les dépôts et propriétaires GitHub. environments() gère les environnements Mission Control, sandbox() et sandboxProxyCa() la prise en charge du sandbox et la Proxy CA, contentExclusion() la validation des politiques d’exclusion, et managedSettings() et userSettings() les paramètres.
Modèles locaux, inférence HTTP et système de fichiers
azureMl() fournit le catalogue, la résolution et le téléchargement de modèles locaux, ainsi que la vérification de l’état, l’annulation et la suppression. llmInference() est une API expérimentale qui relaie côté client les requêtes HTTP de la couche modèle. sessionFs() enregistre un provider de callbacks système de fichiers / SQLite pour la session.
Exemple d’appel de base
Exemples d’utilisation par fonctionnalité
Voici des exemples d’appels représentatifs pour les fonctionnalités ci-dessus.Candidats Agent Plugin du catalogue
En requérantagent-plugin-discovery dans catalog.search et en indiquant plugin dans les kinds recherchés, vous obtenez des candidats Agent Plugin. Pour recevoir, en plus du format standard application/vnd.github.copilot-plugin, les formats application/vnd.anthropic.claude-plugin+json et application/agent-plugin+json, requérez agent-plugin-formats en plus de agent-plugin-discovery.
agent-plugin-confirmed-installation est une capability qui retourne l’installabilité et un plan à examiner ; elle se requiert également avec agent-plugin-discovery. Lorsqu’elle est accordée, les candidats incluent installability, dont la valeur est installable, install-data-unavailable, feature-disabled ou not-installable-kind. installPlan n’est inclus que lorsque installability vaut installable. Le plan est une donnée de vérification ; ce RPC catalog n’exécute jamais d’installation.
Les sources du plan contiennent, par ordre de priorité, des candidats materialization, marketplace et repository. Pour un Marketplace, le nom et le dépôt sont enregistrés ; pour un Repository direct, le dépôt et un chemin optionnel. Dans un plan ne comportant que materialization, pluginName est omis et components est vide. Vérifiez le nom et le contenu réellement installé dans la revue retournée par plugins.planInstall().
Pour un candidat sélectionné, plugins.planInstall() permet de créer un plan validé sans effet de bord. plugins.applyInstall() demande une confirmation explicite à l’utilisateur et applique le plan si celui-ci l’autorise. Le plugin est enregistré à l’état désactivé après application.
Les mcpServers de la revue indiquent le nom des serveurs déclarés par les fichiers validés, le transport et, pour les serveurs distants, l’hôte. Ce n’est pas une garantie de sécurité : l’utilisateur doit examiner le contenu avant de confirmer explicitement. La description d’un plugin installé provient du manifest. verifiedSource indique le dépôt GitHub et le commit figé ; il n’existe que pour les installations directes figées sur un commit. iconUrl est un contenu externe non fiable : n’envoyez ni informations d’authentification ni identifiants GitHub lors de sa récupération. Les identifiants eux-mêmes ne sont jamais retournés comme motif de refus.
Pour un résultat d’installation network-failure, vous pouvez consulter CatalogNetworkFailureReason, le statusCode HTTP, un retryAfterSeconds optionnel et un message affichable en toute sécurité.
catalog.planInstallFromReference(). Le outcome->kind du résultat vaut plugin-install-planned, skill-install-planned ou refused. Passez un plan de plugin à plugins.applyInstall() et un plan de skill à skills.applyInstall().
contentExclusion
Avant de créer une session, vous pouvez valider le JSON des politiques d’exclusion de contenu.policiesJson est transmis au CLI tel quel, sous forme de chaîne JSON non analysée. Si l’analyse JSON ou la validation du schéma échoue, une erreur RPC du CLI (JsonRpcException) est levée.
Il s’agit d’un RPC à portée serveur qui valide les politiques elles-mêmes. Pour vérifier des chemins du répertoire de travail d’une session par rapport aux politiques d’exclusion effectives, utilisez contentExclusion()->checkPaths() à portée session.
managedSettings (experimental : paramètres gérés)
Permet de lire les paramètres gérés, de résoudre les politiques, d’obtenir le schéma, de valider, de prévisualiser une composition et de vider le cache.Cycle de vie du Runtime et du Host (experimental)
host.unpublishSession() retire une application publication d’un hôte en cours d’exécution que vous possédez. Le retrait de la publication ne supprime ni n’arrête l’historique de la session d’origine, le worktree ou le travail en cours. Si la session n’est déjà plus publiée, unpublished vaut false ; les publications autres qu’application provoquent une erreur.
host.dispose() détruit le listener d’hôte indiqué par hostId.
Client::stop() appelle runtime.shutdown après avoir déconnecté les sessions et avant de fermer la connexion JSON-RPC et le processus. Il attend jusqu’à 10 secondes la fin du nettoyage du runtime ; en cas d’échec, l’erreur est incluse dans la valeur de retour et le reste de l’arrêt se poursuit. Pour une connexion à un runtime externe, comme avec cli_url, ce RPC n’est pas appelé afin de ne pas arrêter un runtime partagé.
SessionRpc
Classe RPC associée à une Session. Elle permet notamment d’utiliser le Plan Mode, absent de l’ancien SDK.Modèle, mode, nom et plan
model() permet de consulter et de changer le modèle courant, et de configurer le reasoning effort, l’Auto tier et les modèles autorisés. mode() gère le mode, name() le nom de la session, et plan() la lecture et l’écriture du contenu du plan et des todos SQLite.
Workspace, instructions et LSP
workspaces() permet de lister, lire, écrire, déplacer et supprimer des fichiers, ainsi que de manipuler des répertoires. instructions() permet d’obtenir, recharger et découvrir les instructions, et lsp() d’initialiser la configuration des serveurs de langage.
Agents, Fleet et tâches en arrière-plan
agent() permet de lister, sélectionner et recharger les agents, et fleet() de démarrer une Fleet. tasks() gère l’enregistrement d’agents en arrière-plan et de tâches possédées par le client, la consultation et la mise à jour de la progression, la migration, l’envoi de messages, l’annulation et la suppression.
MCP, Plugins, Extensions et Workflow
mcp() gère la liste, le démarrage, l’arrêt et le rechargement des serveurs, les outils, prompts et ressources, OAuth, le sampling et la mise à jour des en-têtes dynamiques. plugins() et extensions() gèrent l’état au sein de la session, et customizations() recharge les personnalisations. workflow() permet d’exécuter et de consulter des workflows, et diagnostics() et connectors() d’obtenir des informations de diagnostic et les connecteurs.
Tools, Permissions, Commands et UI
tools() et permissions() gèrent les réponses aux requêtes en attente reçues via des événements ainsi que la configuration. commands() fournit la liste des commandes, leur exécution et la réponse aux événements, et ui() la réponse aux demandes de saisie utilisateur, d’elicitation, d’approbation de plan, etc. completions() obtient des suggestions de saisie.
Comptes, authentification et providers
accounts() gère l’énumération des comptes / providers / comptes connectés via enumerate(), get() et set(), ainsi que la connexion interactive via begin(), advance() et cancel(). gitHubAuth() gère l’état d’authentification et les identifiants de la session, provider() et providers() la destination de connexion des modèles et les adaptateurs de providers, et connectors() les connexions de connecteurs de la session.
Historique, file d’attente, logs et utilisation
history() permet de compacter, d’interrompre, de résumer pour un transfert et de tronquer la conversation, et queue() d’insérer, déplacer, modifier, supprimer et envoyer immédiatement des éléments en attente. log(), eventLog(), usage(), quota() et limitPrediction() gèrent les logs, les événements, l’utilisation et les informations de limites. schedule() permet de consulter et d’arrêter les prompts planifiés.
Cycle de vie, distant et intégration avec l’hôte
sendMessages() exécute plusieurs messages en un seul tour, et suspend() et shutdown() arrêtent la session. interruptMainTurn() contrôle le tour principal et cancelAllBackgroundAgents() les agents en arrière-plan, de manière indépendante. remote() et visibility() gèrent la publication distante et l’état de partage, sandbox() le sandbox de la session, managedSettings() les paramètres gérés à portée session, contentExclusion() l’évaluation des chemins, metadata() les métadonnées possédées par le client et canvas() l’intégration Canvas.
debug (experimental)
debug()->collectLogs() collecte les logs d’événements, les logs de processus et les logs shell de la session dans une archive .tgz ou un répertoire. Par défaut, les informations sensibles des logs sont expurgées. additionalEntries permet d’ajouter des fichiers ou des répertoires, et redaction accepte plain-text, events-jsonl ou none. Avec none, aucune expurgation n’est effectuée : faites attention au contenu que vous ajoutez.
DebugCollectLogsDestination::directory('/tmp/copilot-debug'), la sortie est écrite dans un répertoire de staging. include permet d’indiquer individuellement les logs et les chemins de référence à collecter, et les entries et skippedEntries du résultat permettent de vérifier ce qui a été collecté. Les chemins de destination et des entrées supplémentaires sont des chemins côté serveur CLI. Dans la configuration standard où le CLI est lancé via stdio, il s’agit du même hôte que l’application ; mais si vous vous connectez en TCP à un serveur CLI sur un autre hôte, indiquez des chemins côté serveur et non ceux de la machine appelante.
contentExclusion (experimental)
Vous pouvez vérifier si des chemins absolus locaux situés dans le répertoire de travail de la session sont soumis aux politiques d’exclusion de contenu. Appelez-le avant de lire ou de joindre le contenu d’un fichier.checkPaths() n’accepte que des chemins absolus, qui doivent se trouver dans le répertoire de travail de la session. checks est retourné dans le même ordre que l’entrée, et les chemins dupliqués sont conservés tels quels. Si le chemin, le système de fichiers ou l’évaluation des politiques n’est pas pris en charge ou indisponible, available: false et un checks vide sont retournés. Dans ce cas, isExcluded() retourne toujours true : traitez donc tous les chemins comme exclus. Même avec available: true, un chemin absent du résultat est, par prudence, considéré comme exclu.
MCP Apps (experimental)
Les RPC MCP Apps s’appellent via$session->rpc()->mcp()->apps(). Pour listTools() et callTool(), le nom du serveur MCP appelant originServerName est obligatoire. Le résultat de callTool() est retourné sous forme de résultat MCP libre.
readResource() retourne des données de ressource telles que du HTML. Le SDK n’effectue ni rendu navigateur ni manipulation d’iframe : le rendu du contenu obtenu relève de l’application appelante.
Exemples d’utilisation par fonctionnalité
Voici des exemples d’appels représentatifs pour les fonctionnalités ci-dessus.remote (experimental : prise en charge des sessions distantes)
sandbox (experimental : contrôle du sandbox)
$request['sandboxPathGrant'] est présent, appelez ce RPC avec le requestId de la demande en attente concernée. Comme ce RPC répond lui-même à la demande de permission, retournez PermissionDecision::noResult() en cas de succès afin de ne pas envoyer la réponse habituelle.
metadata (experimental : métadonnées possédées par le client)
Session canvas
Les RPC Canvas s’appellent via$session->rpc()->canvas(). list() retourne la
liste dans canvases de CanvasList, et listOpen() dans openCanvases de
CanvasListOpenResult. open() retourne un OpenCanvasInstance, et
l’invocation d’une action retourne un CanvasActionInvokeResult. close() ne
retourne aucune valeur.
canvas.open / canvas.close /
canvas.action.invoke) est traité par le canvasHandler de SessionConfig /
ResumeSessionConfig. Le rendu du Canvas relève de l’UI de l’hôte.
workflow
Les RPC expérimentales ajoutées avec la série Copilot CLI 1.0.89, comme les workflows, les connecteurs et les diagnostics, sont également disponibles depuisSessionRpc. Ces payloads de protocole variables se passent sous forme de tableaux compatibles JSON, et les réponses sont également retournées sous forme de tableaux. Le sessionId courant est ajouté automatiquement à chaque appel.
workflow() appelle les RPC de bas niveau fournies par le CLI. Une API de haut niveau permettant, comme dans le SDK Node.js, d’enregistrer et d’exécuter des closures PHP en tant que workflows n’a pas été ajoutée lors de cette synchronisation. Ces nouveaux groupes RPC dépendent de la version du CLI et sont expérimentaux : ne les utilisez qu’avec un CLI compatible.
Types de callbacks SessionFS
Pour les opérations de système de fichiers à la portée d’une session, des types de callback (Request/Result) sont définis. Ce sont les types de requête/réponse utilisés lorsque le Copilot CLI rappelle le client.SessionFsStatResult / SessionFsReaddirResult / SessionFsReaddirWithTypesResult possèdent un error optionnel (SessionFsError) utilisé en cas d’échec.
Handler SessionFs
En plus desessionFs.readFile / readFileBytes / writeFile / writeFileBytes, le Client répartit les requêtes appendFile, exists, stat, mkdir, readdir, readdirWithTypes, rm, rename, sqliteQuery, sqliteTransaction et sqliteExists vers le provider de la Session. Les échecs d’opérations sur les fichiers sont retournés sous forme d’error ENOENT (ENOENT ou errno 2) / UNKNOWN. exists retourne false en cas d’exception, et stat retourne des valeurs nulles accompagnées d’un error en cas d’échec. Les opérations non prises en charge par le provider produisent une erreur UNKNOWN (une erreur JSON-RPC pour les opérations SQLite). Les exceptions de sqliteQuery/sqliteExists sont retournées sous forme d’erreurs JSON-RPC, et les échecs de sqliteTransaction sous forme d’error dans le résultat (avec errorClass).
Les interfaces côté provider (SessionFsFilesystemProvider, SessionFsSqliteCapableProvider, SessionFsSqliteProvider, SessionFsSqliteTransactionProvider) ont été ajoutées en tant qu’interfaces distinctes afin de ne pas casser l’ancienne SessionFsProvider (2 méthodes).
Types de callbacks SQLite
Pour activer la prise en charge de SQLite, passez
SessionFsSetProviderCapabilities(sqlite: true) dans capabilities de SessionFsSetProviderRequest.
sessionFs (ou session_fs dans config/copilot.php), Client::start() envoie sessionFs.setProvider une seule fois. La session nécessite createSessionFsProvider (voir SessionConfig).
L’enum SessionFsSqliteQueryType (src/Enums/) représente le type de requête :
Exec: DDL / instructions multiples (aucun résultat)Query: SELECT (retourne des lignes)Run: INSERT/UPDATE/DELETE (retourne rowsAffected)
src/Types/Rpc/.
Passer les arguments sous forme de tableau
Les arguments et les valeurs de retour utilisent des classes dédiées, mais les arguments peuvent aussi être fournis sous forme de tableau.Tests
Le mock viaCopilot::fake() n’est pas utilisable ici ; utilisez Copilot::expects('client') ou Copilot::expects('start') pour créer les mocks.
Pour les dernières informations, consultez le dépôt GitHub.