SessionConfig
Die KlasseSessionConfig ermöglicht vielfältige Einstellungen.
Sie wird wie folgt verwendet: Copilot::run(prompt: '...', config: $config) oder Copilot::start(function (CopilotSession $session) { ... }, config: $config).
Wenn Sie – etwa nur ein Modell setzen wollen – die Klasse SessionConfig gar nicht benötigen, ist auch die Angabe als Array möglich: Copilot::run(prompt: '...', config: ['model' => 'auto']).
Die Option remoteSession wurde im offiziellen SDK 1.0.26 entfernt. SessionConfig und ResumeSessionConfig akzeptieren sie nicht mehr.
Discovery-Roots
skillDirectories, agentDirectories, hookDirectories und instructionDirectories sind reine Discovery-Roots für Skills, Custom-Agenten, Datei-Hooks und benutzerdefinierte Instruktionen.
Sie gewähren dem Agenten keinen allgemeinen Dateizugriff.
Um reguläre Orte für den Dateizugriff hinzuzufügen, verwenden Sie additionalDirectories.
Discovery-Roots lassen sich unabhängig davon setzen, ob enableConfigDiscovery aktiviert ist.
Das SDK löst relative Pfade einmalig auf, und zwar relativ zu dem workingDirectory, das beim Setzen gilt.
Die Roots verschieben sich nicht, wenn sich das Arbeitsverzeichnis später ändert.
Wird ein Schlüssel weggelassen oder null übergeben, bleiben die Standard-Discovery-Quellen unverändert.
Die Übergabe von [] entfernt nur die Roots, die das SDK explizit gesetzt hat.
Deaktivierungseinstellungen pro Quelle sowie Managed Settings für Skills, Agenten, Hooks und Instruktionen gelten weiterhin.
Vertrauen in das Arbeitsverzeichnis
Setzen SietrustWorkingDirectory, um das Arbeitsverzeichnis beim Erstellen einer Session als vertrauenswürdig zu markieren.
WorkingDirectoryTrust::Sessionvertraut dem Verzeichnis nur für die aktuelle Session.WorkingDirectoryTrust::Userspeichert das Vertrauen dauerhaft, sodass auch spätere Sessions dem Verzeichnis vertrauen.
trustWorkingDirectory ist nur beim Erstellen einer Session verfügbar. ResumeSessionConfig akzeptiert die Option nicht.
Injektionsmodus für Memory
MemoryConfiguration steuert das sessionübergreifende Memory.
Die Option mode legt fest, wo die Runtime Memory einfügt:
MemoryMode::SystemPrompt(system-prompt) fügt Memory in den System-Prompt ein. Das ist der Standard, wennmodeweggelassen wird.MemoryMode::UserPrompt(user-prompt) fügt Memory in die generierte Benutzernachricht ein.
App-verwalteter Memory-Speicher
Übergeben Sie inMemoryConfiguration eine Closure als storeMemory, um die Memories, die die Runtime speichern möchte, in Ihrer App entgegenzunehmen und zu speichern. Die Closure erhält ein StoredMemory (sessionId, subject, fact, citations, reason) und MemoryStoreCallOptions mit einem signal, über das Sie einen Abbruch prüfen können.
- Setzen Sie
enabledauftrue, wenn SiestoreMemoryverwenden. Andernfalls wird eine Exception ausgelöst. storeMemoryselbst wird nicht in der RPC-Payload übertragen. Das SDK sendet beim Erstellen oder Fortsetzen der Session nurhasMemoryStore: true.- In Cloud-Sessions ist die Option nicht verfügbar.
- Die Runtime ruft keine Memories mehr ab, und
vote_memoryist nicht mehr verfügbar. Stellen Sie das Abrufen gespeicherter Memories in Ihrer App bereit, zum Beispiel übersystemMessage. - Das
signaldes Callbacks wird bei Timeout oder Verbindungsabbruch abgebrochen, und danach zurückgegebene Ergebnisse werden verworfen.
Berechtigungsmodus
MitpermissionMode teilen Sie der Runtime beim Erstellen oder Fortsetzen einer Session einen Berechtigungsmodus mit. Wenn Sie die Option weglassen, gilt der Standard der Runtime. Sie können ein PermissionMode-Enum oder einen String angeben, und ResumeSessionConfig akzeptiert dieselbe Option. Cloud-Sessions unterstützen sie nicht.
PermissionMode::Manual(manual) verarbeitet Berechtigungsanfragen mit dem normalen Genehmigungsablauf.PermissionMode::Assisted(assisted) ergänzt Berechtigungsanfragen um eine Sicherheitsempfehlung des LLM. Clients können als unbedenklich eingestufte Anfragen automatisch genehmigen.PermissionMode::AllowAll(allow-all) genehmigt Berechtigungsanfragen für Tools, Pfade und URLs automatisch.
$session->permissionModeResult(). success gibt an, ob der Modus angewendet wurde, und mode ist der resultierende Berechtigungsmodus. Enthält die Antwort kein Ergebnis, wird null zurückgegeben.
Wiederherstellung im Auto-Modus
MitautoModeRecovery: true bitten Sie die Runtime, aktive Requests automatisch wiederherzustellen. Der Standardwert ist false. Diese Option erfordert einen onAutoModeSwitchRequest-Handler. Ohne ihn wird eine Exception ausgelöst. Wiederholungen und Rücksprünge bei der Wiederherstellung übernimmt die Runtime, daher muss Ihre App den Prompt nicht erneut senden.
autoModeRecovery sowohl beim Erstellen als auch beim Fortsetzen an. Meldet die Runtime capabilities.ui.autoModeRecovery nicht als true, wird die Session getrennt und eine Exception ausgelöst. Wenn Sie diese Option nicht verwenden, bleibt das bisherige Umschalten durch onAutoModeSwitchRequest für künftige Nachrichten unverändert.
Managed Settings ausschließen
MitexcludedManagedSettings listen Sie Einstellungspfade auf, die die Runtime aus den abgerufenen Managed Settings entfernen soll.
Einstellungen, die Sie direkt mit managedSettings injizieren, sind davon nicht betroffen.
Damit der Ausschluss nach dem Fortsetzen erhalten bleibt, übergeben Sie excludedManagedSettings erneut in ResumeSessionConfig.
ResumeSessionConfig. Sie ist fast identisch mit SessionConfig, weist aber geringfügige Unterschiede auf. In ResumeSessionConfig geben Sie nur die Optionen an, die Sie ändern möchten. Alle übrigen Einstellungen der ursprünglich gestarteten Session werden übernommen.
Das SDK sendet dieselben Session-Optionen sowohl im Create- als auch im Resume-RPC-Payload.
Dazu gehören BYOK-Provider und -Modelle, Memory, enableMcpApps, interactiveUser, autopilot, sandboxConfig, excludedManagedSettings, Discovery-Roots sowie Handler wie onMcpAuthRequest, onExitPlanModeRequest und onAutoModeSwitchRequest.
Übergeben Sie sie beim Fortsetzen in ResumeSessionConfig oder in einem Array mit denselben Schlüsseln.
Closures und Provider-Objekte werden nicht persistiert. Geben Sie sie daher bei jedem Fortsetzen erneut an.
Autopilot-Fortsetzung
Mitautopilot legen Sie die Richtlinie für die automatische Fortsetzung im Autopilot-Modus fest.
Der Session-Modus selbst wird dadurch nicht geändert.
Neue SDK-Sessions aktivieren die automatische Fortsetzung standardmäßig, wobei maxContinues auf 5 gesetzt ist.
Setzen Sie maxContinues auf 0, um die reguläre automatische Fortsetzung zu deaktivieren.
autopilot in ResumeSessionConfig oder in einem Array.
Bei einem Warm Resume bleibt der aktuelle Wert aller weggelassenen Felder erhalten.
Nach einem Neustart der Runtime (Cold Resume) übergeben Sie die Einstellungen erneut.
Sandbox-Konfiguration
MitsandboxConfig konfigurieren Sie die CLI-Sandbox für eine Session.
Das SDK leitet sie sowohl im Create- als auch im Resume-Request weiter.
Aus Kompatibilitätsgründen mit bestehendem Code akzeptiert das SDK außerdem sandbox als Alias.
Wenn beide gesetzt sind, hat ein sandboxConfig ungleich null Vorrang.
auth und credentials erhalten Prozesse in der Sandbox Zugriff auf Zugangsdaten, ohne deren Werte offenzulegen:
authaktiviert die Injektion von Zugangsdaten fürgitundgh.credentials.envVarsordnet einem Umgebungsvariablennamen die HTTPS-Hosts (injectHosts) zu, die seinen maskierten Wert erhalten dürfen. Tragen Sie den Wert der Zugangsdaten selbst nicht in die Konfiguration ein.
SandboxConfig, SandboxConfigAuth, SandboxCredentialsConfig, SandboxMaskedEnvVar, SandboxConfigUserPolicyExperimental und SandboxConfigUserPolicyExperimentalSeatbelt aus dem Namespace Revolution\Copilot\Types\Rpc verwenden.
Netzwerkregeln zum Erlauben und Blockieren hängen von den Funktionen und der Version der CLI-Sandbox ab.
Canvas-Provider
Deklarieren Sie Canvases mitcanvases und verarbeiten Sie Open- und Action-Requests mit einem canvasHandler.
Die Runtime ruft Ihren Handler per Reverse-RPC auf, wenn der Agent ein Canvas öffnet oder eine seiner Actions ausführt.
Setzen Sie requestCanvasRenderer: true, um sich als Renderer anzumelden. Die Runtime stellt dem Modell dann für diese Verbindung Canvas-Agent-Tools bereit.
Standardmäßig ist dies deaktiviert, damit SDK-Aufrufer, die keine Canvases anzeigen können, nicht beeinträchtigt werden.
requestExtensions: truemeldet sich für die Extension-Oberfläche an. Die Runtime bindet dann Tools zur Extension-Verwaltung in die Sessions dieser Verbindung ein. Standardmäßig deaktiviert.extensionInfo: new ExtensionInfo(source: 'github-app', name: 'my-extension')legt eine stabile Extension-ID für Canvas-Provider auf dieser Verbindung fest. Die Runtime verwendet${source}:${name}anstelle der verbindungsspezifischen ID. Auch als Array angebbar.
canvases und canvasHandler erneut.
Der canvasHandler läuft nur innerhalb des PHP-Prozesses. Das SDK sendet im RPC-Payload nur die Metadaten der Deklaration.
ResumeSessionConfig akzeptiert außerdem openCanvases, einen Snapshot der Canvases, die beim Beenden der Session geöffnet waren.
Die Runtime stellt damit den Canvas-Zustand wieder her, sodass Sie sie nicht erneut öffnen müssen.
Die aktuell geöffneten Canvases erhalten Sie mit $session->openCanvases(). Das SDK hält diese Liste mit den Events session.canvas.opened und session.canvas.closed synchron.
Session-Dateisystem-Provider
Skill- und Dateisystem-Callbacks
MitskillProvider laden Sie Skills aus einer anwendungseigenen Quelle.
Die Callbacks gehören zur jeweiligen Session und werden nicht an die Copilot-Runtime serialisiert.
Cloud-Sessions unterstützen keine benutzerdefinierten Skill-Provider.
SkillProviderCallOptions::$signal stellt das Cancellation-Token des Callbacks bereit.
Der Abbruch ist kooperativ. Ihre Callbacks sollten das Signal beobachten und laufende Arbeit selbst abbrechen.
Anstelle des Callback-Arrays können Sie auch Revolution\Copilot\Contracts\SkillProvider implementieren.
sessionFsProvider verwendet dieselbe sessionbezogene Konfiguration.
Die Text-Callbacks sind readFile(path) und writeFile(path, content, mode).
Für Binärdateien stellen Sie sowohl readFileBytes(path) als auch writeFileBytes(path, bytes, mode) bereit oder implementieren SessionFsBinaryProvider.
Diese Callbacks erhalten und liefern die Original-Bytes. Das SDK übernimmt die Base64-Kodierung auf der JSON-RPC-Leitung.
Beschränken Sie den Dateisystemzugriff auf die Pfade, die Ihre Anwendung bewusst freigeben möchte.
Gesamten Session-Zustand mit sessionFs delegieren
Setzen Sie die Client-Option sessionFs (Alias session_fs), um den gesamten Session-Zustand der Copilot CLI – einschließlich der Session-State-Dateien und der SQLite-Datenbank pro Session – in Ihren eigenen Speicher zu verlagern.
Ist sie gesetzt, muss jede Session-Konfiguration eine createSessionFsProvider-Factory bereitstellen.
Das SDK ruft die Factory sowohl für createSession() als auch für resumeSession() auf, nachdem die Session-ID bekannt ist und bevor der Request an die Runtime gesendet wird.
Copilot-Facade setzen Sie session_fs in config/copilot.php.
initialCwd, sessionStatePath und conventions (posix oder windows) sind Pflichtangaben.
Fehlende Felder oder ein ungültiger conventions-Wert lösen eine InvalidArgumentException aus.
createSessionFsProvider ist eine Closure. Sie funktioniert auch mit Arrays, fromArray() und toArray() von SessionConfig und ResumeSessionConfig.
Der zurückgegebene Provider kann ein Objekt oder ein Array von Callables sein. Jede optionale Fähigkeit hat ein eigenes Interface:
Erfüllt der Provider die deklarierten Fähigkeiten nicht, löst das SDK eine
InvalidArgumentException aus.
Der Aufruf einer Operation, die der Provider nicht unterstützt, liefert einen UNKNOWN-Fehler.
Provider signalisieren Fehler durch das Werfen von Exceptions. Eine Exception mit dem code ENOENT (oder errno 2) wird zu ENOENT, alles andere zu UNKNOWN.
Werfen Sie SessionFsSqliteTransactionFailure aus transaction(), um eine errorClass (busyOrLocked, fatal oder postCommitAmbiguous) zu melden.
Ohne die Client-Option sessionFs ruft das SDK createSessionFsProvider nie auf, und der bestehende sessionFsProvider (readFile und writeFile) funktioniert weiterhin.
Empty-Modus für Multi-Tenant-Anwendungen
Setzen Sie den Client-mode auf empty, um Funktionen, die von der Host-Umgebung der Copilot CLI oder von sessionübergreifendem Zustand abhängen, standardmäßig zu deaktivieren.
Der Standard ist copilot-cli, wodurch das bisherige Verhalten erhalten bleibt.
Im Empty-Modus müssen Sie ein Persistenzziel festlegen: base_directory, session_fs oder eine externe Server-url.
availableTools setzen.
Mit ToolSet erstellen Sie quellenqualifizierte Tool-Filter (builtin:, custom:, mcp:).
BuiltInTools::Isolated erlaubt nur Built-in-Tools, die auf eine einzelne Session beschränkt sind – ohne Zugriff auf das Host-Dateisystem, die Umgebung, das Netzwerk oder andere Sessions.
/^[a-zA-Z0-9_-]+$/ entsprechen oder die Wildcard * sein. Andernfalls löst ToolSet eine InvalidArgumentException aus.
Der Empty-Modus wendet sichere Standardwerte an für Session-Telemetrie, persistente Speicherung von MCP-OAuth-Tokens, Embedding-Retrieval und -Cache, Instruktions-Discovery, Datei-Hooks, Git-Operationen auf dem Host, den Session Store, Skills, Memory und den experimentellen Modus.
Explizit gesetzte Session-Optionen haben Vorrang vor diesen Standardwerten.
Der GitHub Cache Store ist weder ein Standardwert des Empty-Modus noch eine Session-Option. Das SDK sendet enableGitHubCacheStore nicht mehr in Requests zum Erstellen oder Fortsetzen einer Session und ignoriert den Schlüssel, falls er noch in einer Array-Konfiguration vorhanden ist.
systemMessage im replace-Modus wird unverändert verwendet. Bei anderen Modi wird der Abschnitt environment_context entfernt.
Außerdem setzt das SDK COPILOT_DISABLE_KEYTAR=1 für den CLI-Prozess.
Details zur Cloud-Ausführung finden Sie unter Cloud Sessions, zu Plugin Directories unter Plugin Directories.
Aktuelle Informationen finden Sie im GitHub-Repository.