Zum Hauptinhalt springen

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']). 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 Sie trustWorkingDirectory, um das Arbeitsverzeichnis beim Erstellen einer Session als vertrauenswürdig zu markieren.
  • WorkingDirectoryTrust::Session vertraut dem Verzeichnis nur für die aktuelle Session.
  • WorkingDirectoryTrust::User speichert das Vertrauen dauerhaft, sodass auch spätere Sessions dem Verzeichnis vertrauen.
Ohne Angabe ändert das SDK den Vertrauensstatus nicht. trustWorkingDirectory ist nur beim Erstellen einer Session verfügbar. ResumeSessionConfig akzeptiert die Option nicht.

Injektionsmodus für Memory

Die Memory-Konfiguration ist experimentell.
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, wenn mode weggelassen wird.
  • MemoryMode::UserPrompt (user-prompt) fügt Memory in die generierte Benutzernachricht ein.

App-verwalteter Memory-Speicher

Übergeben Sie in MemoryConfiguration 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 enabled auf true, wenn Sie storeMemory verwenden. Andernfalls wird eine Exception ausgelöst.
  • storeMemory selbst wird nicht in der RPC-Payload übertragen. Das SDK sendet beim Erstellen oder Fortsetzen der Session nur hasMemoryStore: true.
  • In Cloud-Sessions ist die Option nicht verfügbar.
  • Die Runtime ruft keine Memories mehr ab, und vote_memory ist nicht mehr verfügbar. Stellen Sie das Abrufen gespeicherter Memories in Ihrer App bereit, zum Beispiel über systemMessage.
  • Das signal des Callbacks wird bei Timeout oder Verbindungsabbruch abgebrochen, und danach zurückgegebene Ergebnisse werden verworfen.

Berechtigungsmodus

Der Berechtigungsmodus ist experimentell.
Mit permissionMode 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.
Enthält die Antwort auf das Erstellen oder Fortsetzen das Ergebnis, erhalten Sie es mit $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

Mit autoModeRecovery: 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.
Geben Sie 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

Mit excludedManagedSettings 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.
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, 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

Die Autopilot-Optionen sind experimentell.
Mit autopilot 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.
Übergeben Sie beim Fortsetzen denselben Schlüssel 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

Die Sandbox-Konfiguration ist experimentell.
Mit sandboxConfig 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.
Mit auth und credentials erhalten Prozesse in der Sandbox Zugriff auf Zugangsdaten, ohne deren Werte offenzulegen:
  • auth aktiviert die Injektion von Zugangsdaten für git und gh.
  • credentials.envVars ordnet 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.
Sie können auch typisierte Objekte wie 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

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, 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.
Zuletzt geändert am 9. November 2026