Skip to main content

SessionConfig

Die Klasse SessionConfig 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']).

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. Beim Fortsetzen einer Session verwenden Sie die Klasse 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, enableGitHubCacheStore, 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.

Canvas-Provider

Die Canvas-Unterstützung ist experimentell.
Deklarieren Sie Canvases mit canvases 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.
Verwandte Optionen:
  • requestExtensions: true meldet 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.
Übergeben Sie beim Fortsetzen 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

Mit skillProvider 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.
Mit der 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.
Jede Session im Empty-Modus muss 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.
Tool-Namen müssen /^[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, den GitHub Cache Store, Skills, Memory und den experimentellen Modus. Explizit gesetzte Session-Optionen haben Vorrang vor diesen Standardwerten. 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.

GitHub Cache Store

Setzen Sie enableGitHubCacheStore: true, um den schreibgeschützten GitHub Cache Store anzufordern. Die CLI registriert das Tool github_sql nur, wenn ihr Feature-Flag GITHUB_CACHE_STORE aktiviert ist.
Details zur Cloud-Ausführung finden Sie unter Cloud Sessions, zu Plugin Directories unter Plugin Directories.
Aktuelle Informationen finden Sie im GitHub-Repository.
Zuletzt geändert am 19. Oktober 2026