Passer au contenu principal

SessionConfig

La classe SessionConfig permet un large éventail de réglages. Elle s’utilise ainsi : Copilot::run(prompt: '...', config: $config) ou Copilot::start(function (CopilotSession $session) { ... }, config: $config). Lorsque vous voulez juste indiquer un modèle sans passer par la classe SessionConfig, un tableau suffit : Copilot::run(prompt: '...', config: ['model' => 'auto']). L’option remoteSession a été supprimée dans le SDK officiel 1.0.26. SessionConfig et ResumeSessionConfig ne l’acceptent plus.

Racines de découverte

skillDirectories, agentDirectories, hookDirectories et instructionDirectories sont des racines de découverte uniquement, destinées aux skills, agents personnalisés, hooks de fichiers et instructions personnalisées. Elles n’accordent pas à l’agent un accès général aux fichiers. Pour ajouter des emplacements d’accès aux fichiers classiques, utilisez additionalDirectories. Vous pouvez définir des racines de découverte que enableConfigDiscovery soit activé ou non. Le SDK résout les chemins relatifs une seule fois, par rapport au workingDirectory effectif au moment où vous les définissez. Les racines ne bougent pas si le répertoire de travail change par la suite. Omettre une clé ou passer null laisse les sources de découverte par défaut inchangées. Passer [] efface uniquement les racines définies explicitement par le SDK. Les réglages de désactivation par source et les Managed Settings pour les skills, agents, hooks et instructions continuent de s’appliquer.

Confiance dans le répertoire de travail

Définissez trustWorkingDirectory pour marquer le répertoire de travail comme fiable lors de la création d’une session.
  • WorkingDirectoryTrust::Session fait confiance au répertoire pour la session en cours uniquement.
  • WorkingDirectoryTrust::User conserve la confiance afin que les sessions suivantes fassent aussi confiance au répertoire.
Si vous l’omettez, le SDK ne modifie pas l’état de confiance. trustWorkingDirectory n’est disponible qu’à la création d’une session. ResumeSessionConfig ne l’accepte pas.

Mode d’injection de la mémoire

La configuration de la mémoire est expérimentale.
MemoryConfiguration contrôle la mémoire inter-sessions. Son option mode détermine où le runtime injecte la mémoire :
  • MemoryMode::SystemPrompt (system-prompt) injecte la mémoire dans le prompt système. C’est la valeur par défaut lorsque vous omettez mode.
  • MemoryMode::UserPrompt (user-prompt) injecte la mémoire dans le message utilisateur généré.

Stockage de mémoire géré par l’application

Passez une closure comme storeMemory dans MemoryConfiguration pour recevoir dans votre application les mémoires que le runtime souhaite enregistrer et les stocker. La closure reçoit un StoredMemory (sessionId, subject, fact, citations, reason) et un MemoryStoreCallOptions dont le signal permet de vérifier l’annulation.
  • Définissez enabled sur true lorsque vous utilisez storeMemory. S’il reste à false, une exception est levée.
  • storeMemory lui-même n’est pas inclus dans le payload RPC. Le SDK envoie uniquement hasMemoryStore: true lors de la création ou de la reprise de la session.
  • Il n’est pas disponible pour les sessions cloud.
  • Le runtime ne rappelle plus les mémoires, et vote_memory n’est plus disponible. Assurez le rappel des mémoires enregistrées depuis votre application, par exemple via systemMessage.
  • Le signal du callback est annulé en cas de délai dépassé ou de déconnexion, et tout résultat renvoyé ensuite est ignoré.

Mode de permissions

Le mode de permissions est une fonctionnalité expérimentale.
Spécifiez permissionMode pour transmettre un mode de permissions au runtime lors de la création ou de la reprise d’une session. Si vous l’omettez, la valeur par défaut du runtime s’applique. Vous pouvez passer un enum PermissionMode ou une chaîne, et ResumeSessionConfig accepte la même option. Les sessions cloud ne le prennent pas en charge.
  • PermissionMode::Manual (manual) traite les demandes de permission avec le flux d’approbation normal.
  • PermissionMode::Assisted (assisted) ajoute une recommandation de sécurité du LLM aux demandes de permission. Les clients peuvent approuver automatiquement les demandes jugées acceptables.
  • PermissionMode::AllowAll (allow-all) approuve automatiquement les demandes de permission pour les outils, chemins et URL.
Lorsque la réponse de création ou de reprise inclut le résultat, vous pouvez l’obtenir avec $session->permissionModeResult(). success indique si le mode a été appliqué, et mode est le mode de permissions résultant. La méthode renvoie null lorsque la réponse n’inclut pas de résultat.

Récupération du mode automatique

Spécifiez autoModeRecovery: true pour demander au runtime de récupérer automatiquement les requêtes actives. La valeur par défaut est false. Cette option nécessite un handler onAutoModeSwitchRequest. Sans lui, une exception est levée. Le runtime gère les nouvelles tentatives et les retours en arrière pendant la récupération, votre application n’a donc pas besoin de renvoyer le prompt.
Spécifiez autoModeRecovery à la fois lors de la création et de la reprise. Si le runtime ne signale pas capabilities.ui.autoModeRecovery comme true, la session est détachée et une exception est levée. Si vous n’utilisez pas cette option, le changement de mode existant via onAutoModeSwitchRequest pour les messages futurs reste inchangé.

Exclure des Managed Settings

Utilisez excludedManagedSettings pour lister les chemins de réglages que le runtime doit retirer des Managed Settings qu’il récupère. Cela n’affecte pas les réglages que vous injectez directement avec managedSettings. Pour conserver l’exclusion après une reprise, passez de nouveau excludedManagedSettings dans ResumeSessionConfig.
Pour reprendre une session, utilisez la classe ResumeSessionConfig. Elle ressemble beaucoup à SessionConfig avec quelques différences. ResumeSessionConfig ne spécifie que les champs à changer ; les autres sont hérités de la configuration initiale. Le SDK envoie les mêmes options de session dans les payloads RPC de création et de reprise. Cela inclut les fournisseurs et modèles BYOK, la mémoire, enableMcpApps, interactiveUser, autopilot, sandboxConfig, excludedManagedSettings, les racines de découverte et les gestionnaires tels que onMcpAuthRequest, onExitPlanModeRequest et onAutoModeSwitchRequest. Lors d’une reprise, passez-les dans ResumeSessionConfig ou dans un tableau avec les mêmes clés. Les closures et objets fournisseurs ne sont pas persistés : fournissez-les à nouveau à chaque reprise.

Continuation Autopilot

Les options Autopilot sont expérimentales.
Utilisez autopilot pour définir la politique de continuation automatique du mode Autopilot. Cela ne modifie pas le mode de la session lui-même. Les nouvelles sessions SDK activent la continuation automatique par défaut, avec maxContinues fixé à 5. Définissez maxContinues à 0 pour désactiver la continuation automatique normale.
Lors d’une reprise, passez la même clé autopilot dans ResumeSessionConfig ou dans un tableau. Une reprise à chaud (warm resume) conserve la valeur actuelle de tout champ omis. Après un redémarrage du runtime (cold resume), passez de nouveau les réglages.

Configuration du sandbox

La configuration du sandbox est expérimentale.
Utilisez sandboxConfig pour configurer le sandbox de la CLI pour une session. Le SDK la transmet dans les requêtes de création et de reprise. Pour rester compatible avec le code existant, le SDK accepte aussi sandbox comme alias. Si vous définissez les deux, un sandboxConfig non null l’emporte.
Utilisez auth et credentials pour donner aux processus du sandbox accès à des identifiants sans exposer leurs valeurs :
  • auth active l’injection d’identifiants pour git et gh.
  • credentials.envVars associe un nom de variable d’environnement aux hôtes HTTPS (injectHosts) autorisés à recevoir sa valeur masquée. Ne placez pas la valeur de l’identifiant elle-même dans la configuration.
Vous pouvez aussi utiliser des objets typés tels que SandboxConfig, SandboxConfigAuth, SandboxCredentialsConfig, SandboxMaskedEnvVar, SandboxConfigUserPolicyExperimental et SandboxConfigUserPolicyExperimentalSeatbelt du namespace Revolution\Copilot\Types\Rpc. Les règles réseau d’autorisation et de blocage dépendent des fonctionnalités et de la version du sandbox de la CLI.

Fournisseurs de canvas

La prise en charge des canvas est expérimentale.
Déclarez les canvas avec canvases et traitez les requêtes d’ouverture et d’action avec un canvasHandler. Le runtime appelle votre gestionnaire via RPC inverse lorsque l’agent ouvre un canvas ou invoque l’une de ses actions. Définissez requestCanvasRenderer: true pour vous déclarer comme renderer : le runtime expose alors au modèle les outils d’agent liés aux canvas pour cette connexion. Cette option est désactivée par défaut afin que les appelants du SDK incapables d’afficher des canvas ne soient pas affectés.
Options associées :
  • requestExtensions: true active la surface d’extensions. Le runtime branche alors les outils de gestion des extensions dans les sessions de cette connexion. Désactivé par défaut.
  • extensionInfo: new ExtensionInfo(source: 'github-app', name: 'my-extension') définit un ID d’extension stable pour les fournisseurs de canvas de cette connexion. Le runtime utilise ${source}:${name} au lieu de l’ID propre à chaque connexion. Un tableau est également accepté.
Lors d’une reprise, passez à nouveau canvases et canvasHandler. Le canvasHandler s’exécute uniquement dans le processus PHP. Le SDK n’envoie que les métadonnées de déclaration dans le payload RPC. ResumeSessionConfig accepte aussi openCanvases, un instantané des canvas ouverts au moment de l’arrêt de la session. Le runtime s’en sert pour réhydrater l’état des canvas, sans que vous ayez à les rouvrir. Récupérez les canvas actuellement ouverts avec $session->openCanvases(). Le SDK maintient cette liste synchronisée avec les événements session.canvas.opened et session.canvas.closed.

Fournisseurs de système de fichiers de session

Callbacks de skills et de système de fichiers

Utilisez skillProvider pour charger des skills depuis une source gérée par l’application. Les callbacks appartiennent à cette session et ne sont pas sérialisés vers le runtime Copilot. Les cloud sessions ne prennent pas en charge les fournisseurs de skills personnalisés.
SkillProviderCallOptions::$signal expose le jeton d’annulation du callback. L’annulation est coopérative : vos callbacks doivent observer le signal et annuler eux-mêmes le travail en cours. Au lieu du tableau de callbacks, vous pouvez implémenter Revolution\Copilot\Contracts\SkillProvider. sessionFsProvider utilise la même configuration à portée de session. Les callbacks texte sont readFile(path) et writeFile(path, content, mode). Pour prendre en charge les fichiers binaires, fournissez à la fois readFileBytes(path) et writeFileBytes(path, bytes, mode), ou implémentez SessionFsBinaryProvider. Ces callbacks reçoivent et renvoient les octets d’origine. Le SDK gère l’encodage base64 sur le fil JSON-RPC. Limitez l’accès au système de fichiers aux chemins que votre application entend exposer.

Déléguer tout l’état de session avec sessionFs

Définissez l’option client sessionFs (alias session_fs) pour déplacer l’intégralité de l’état de session de Copilot CLI, y compris les fichiers d’état de session et la base SQLite propre à chaque session, vers votre propre stockage. Lorsque vous la définissez, chaque configuration de session doit fournir une factory createSessionFsProvider. Le SDK appelle la factory pour createSession() comme pour resumeSession(), une fois l’ID de session connu et avant l’envoi de la requête au runtime.
Avec la façade Copilot, définissez session_fs dans config/copilot.php. initialCwd, sessionStatePath et conventions (posix ou windows) sont obligatoires. Un champ manquant ou une valeur conventions invalide lève une InvalidArgumentException. createSessionFsProvider est une Closure. Elle fonctionne aussi avec les tableaux, fromArray() et toArray() de SessionConfig et ResumeSessionConfig. Le fournisseur renvoyé peut être un objet ou un tableau de callables. Chaque capacité optionnelle a sa propre interface : Si le fournisseur ne satisfait pas les capacités déclarées, le SDK lève une InvalidArgumentException. Appeler une opération non prise en charge par le fournisseur renvoie une erreur UNKNOWN. Les fournisseurs signalent les échecs en levant une exception. Une exception dont le code est ENOENT (ou errno 2) devient ENOENT ; toute autre devient UNKNOWN. Levez SessionFsSqliteTransactionFailure depuis transaction() pour signaler un errorClass (busyOrLocked, fatal ou postCommitAmbiguous). Sans l’option client sessionFs, le SDK n’appelle jamais createSessionFsProvider, et le sessionFsProvider existant (readFile et writeFile) continue de fonctionner.

Mode empty pour les applications multi-locataires

Définissez le mode du client sur empty pour désactiver par défaut les fonctionnalités qui dépendent de l’environnement hôte de Copilot CLI ou d’un état partagé entre sessions. La valeur par défaut est copilot-cli, qui conserve le comportement existant. En mode empty, vous devez définir une cible de persistance : base_directory, session_fs ou l’url d’un serveur externe.
En mode empty, chaque session doit définir availableTools. Utilisez ToolSet pour construire des filtres d’outils qualifiés par source (builtin:, custom:, mcp:). BuiltInTools::Isolated n’autorise que les outils intégrés confinés à une seule session, sans accès au système de fichiers de l’hôte, à l’environnement, au réseau ni aux autres sessions.
Les noms d’outils doivent correspondre à /^[a-zA-Z0-9_-]+$/ ou être le joker *. Sinon, ToolSet lève une InvalidArgumentException. Le mode empty applique des valeurs par défaut sûres à la télémétrie de session, au stockage persistant des tokens OAuth MCP, à la récupération et au cache d’embeddings, à la découverte des instructions, aux hooks de fichiers, aux opérations git de l’hôte, au session store, aux skills, à la mémoire et au mode expérimental. Les options de session définies explicitement priment sur ces valeurs par défaut. Le GitHub cache store n’est ni une valeur par défaut du mode empty ni une option de session. Le SDK n’envoie plus enableGitHubCacheStore dans les requêtes de création ou de reprise de session, et ignore la clé si elle subsiste dans une configuration sous forme de tableau. Un systemMessage en mode replace est utilisé tel quel ; les autres modes suppriment la section environment_context. Le SDK définit également COPILOT_DISABLE_KEYTAR=1 pour le processus CLI. Pour l’exécution dans le cloud, voir Cloud Sessions ; pour les Plugin Directories, voir Plugin Directories.
Pour les dernières informations, consultez le dépôt GitHub.
Dernière modification le 9 novembre 2026