SessionConfig
Con la classeSessionConfig puoi effettuare varie configurazioni.
Si usa come Copilot::run(prompt: '...', config: $config) o Copilot::start(function (CopilotSession $session) { ... }, config: $config).
Quando la classe SessionConfig sarebbe eccessiva, ad esempio se vuoi solo specificare il modello, puoi anche passare un array. Copilot::run(prompt: '...', config: ['model' => 'auto'])
Root di discovery
skillDirectories, agentDirectories, hookDirectories e instructionDirectories sono root di sola discovery per skill, agenti personalizzati, hook su file e istruzioni personalizzate.
Non concedono all’agente un accesso generale ai file.
Per aggiungere posizioni con accesso ai file ordinario, usa additionalDirectories.
Puoi impostare le root di discovery indipendentemente dal fatto che enableConfigDiscovery sia abilitato o meno.
L’SDK risolve i percorsi relativi una sola volta, rispetto alla workingDirectory effettiva nel momento in cui li imposti.
Le root non si spostano se la working directory cambia in seguito.
Omettere una chiave o passare null lascia invariate le sorgenti di discovery predefinite.
Passare [] rimuove solo le root impostate esplicitamente dall’SDK.
Le impostazioni di disabilitazione per singola sorgente e le Managed Settings per skill, agenti, hook e istruzioni continuano ad applicarsi.
Al momento della ripresa di una sessione si usa la classe ResumeSessionConfig. È quasi identica a SessionConfig, ma con qualche differenza. In ResumeSessionConfig specifichi solo i parametri che vuoi cambiare. Gli altri vengono ereditati dalle impostazioni dell’avvio della sessione originale.
L’SDK invia le stesse opzioni di sessione sia nel payload RPC di creazione sia in quello di ripresa.
Questo include provider e modelli BYOK, memoria, enableMcpApps, interactiveUser, enableGitHubCacheStore, root di discovery e handler come onMcpAuthRequest, onExitPlanModeRequest e onAutoModeSwitchRequest.
Alla ripresa, passali in ResumeSessionConfig o in un array con le stesse chiavi.
Le closure e gli oggetti provider non vengono salvati, quindi forniscili di nuovo a ogni ripresa.
Provider di canvas
Dichiara i canvas concanvases e gestisci le richieste di apertura e di azione con un canvasHandler.
Il runtime chiama il tuo handler tramite reverse RPC quando l’agente apre un canvas o invoca una delle sue azioni.
Imposta requestCanvasRenderer: true per aderire come renderer, così il runtime espone al modello gli strumenti agente per i canvas su questa connessione.
È disattivato di default, così i chiamanti dell’SDK che non possono visualizzare i canvas non ne vengono influenzati.
requestExtensions: trueaderisce alla superficie delle estensioni. Il runtime collega quindi gli strumenti di gestione delle estensioni alle sessioni su questa connessione. Disattivato di default.extensionInfo: new ExtensionInfo(source: 'github-app', name: 'my-extension')imposta un ID estensione stabile per i provider di canvas su questa connessione. Il runtime usa${source}:${name}al posto dell’ID per connessione. Puoi passare anche un array.
canvases e canvasHandler.
Il canvasHandler viene eseguito solo all’interno del processo PHP. L’SDK invia nel payload RPC solo i metadati della dichiarazione.
ResumeSessionConfig accetta anche openCanvases, uno snapshot dei canvas aperti al momento dell’interruzione della sessione.
Il runtime lo usa per ripristinare lo stato dei canvas, quindi non devi riaprirli.
Ottieni i canvas attualmente aperti con $session->openCanvases(). L’SDK mantiene questo elenco sincronizzato con gli eventi session.canvas.opened e session.canvas.closed.
Provider di filesystem della sessione
Callback per skill e filesystem
UsaskillProvider per caricare le skill da una sorgente gestita dall’applicazione.
Le callback appartengono a quella sessione e non vengono serializzate verso il runtime di Copilot.
Le sessioni cloud non supportano provider di skill personalizzati.
SkillProviderCallOptions::$signal espone il token di annullamento della callback.
L’annullamento è cooperativo. Le tue callback devono osservare il segnale e annullare autonomamente il lavoro in sospeso.
Invece dell’array di callback puoi implementare Revolution\Copilot\Contracts\SkillProvider.
sessionFsProvider usa la stessa configurazione a livello di sessione.
Le callback testuali sono readFile(path) e writeFile(path, content, mode).
Per supportare i file binari, fornisci sia readFileBytes(path) sia writeFileBytes(path, bytes, mode), oppure implementa SessionFsBinaryProvider.
Queste callback ricevono e restituiscono i byte originali. L’SDK gestisce la codifica base64 sul canale JSON-RPC.
Limita l’accesso al filesystem ai percorsi che la tua applicazione intende esporre.
Delegare tutto lo stato della sessione con sessionFs
Imposta l’opzione client sessionFs (alias session_fs) per spostare l’intero stato della sessione di Copilot CLI, inclusi i file di stato della sessione e il database SQLite per sessione, nel tuo storage.
Quando la imposti, ogni configurazione di sessione deve fornire una factory createSessionFsProvider.
L’SDK chiama la factory sia per createSession() sia per resumeSession(), dopo che l’ID sessione è noto e prima che la richiesta venga inviata al runtime.
Copilot, imposta session_fs in config/copilot.php.
initialCwd, sessionStatePath e conventions (posix o windows) sono obbligatori.
Campi mancanti o un valore di conventions non valido lanciano una InvalidArgumentException.
createSessionFsProvider è una Closure. Funziona anche con gli array, fromArray() e toArray() su SessionConfig e ResumeSessionConfig.
Il provider restituito può essere un oggetto o un array di callable. Ogni capability opzionale ha la propria interfaccia:
Se il provider non soddisfa le capability dichiarate, l’SDK lancia una
InvalidArgumentException.
Chiamare un’operazione che il provider non supporta restituisce un errore UNKNOWN.
I provider segnalano i fallimenti lanciando eccezioni. Un’eccezione con code uguale a ENOENT (o errno 2) diventa ENOENT. Qualsiasi altra diventa UNKNOWN.
Lancia SessionFsSqliteTransactionFailure da transaction() per riportare un errorClass (busyOrLocked, fatal o postCommitAmbiguous).
Senza l’opzione client sessionFs, l’SDK non chiama mai createSessionFsProvider e il sessionFsProvider esistente (readFile e writeFile) continua a funzionare.
Modalità empty per app multi-tenant
Imposta ilmode del client su empty per disabilitare, di default, le funzionalità che dipendono dall’ambiente host di Copilot CLI o dallo stato condiviso tra sessioni.
Il default è copilot-cli, che mantiene il comportamento esistente.
In modalità empty devi impostare una destinazione di persistenza: base_directory, session_fs o l’url di un server esterno.
availableTools.
Usa ToolSet per costruire filtri di strumenti qualificati per sorgente (builtin:, custom:, mcp:).
BuiltInTools::Isolated consente solo gli strumenti integrati confinati a una singola sessione, senza accesso al filesystem dell’host, all’ambiente, alla rete o ad altre sessioni.
/^[a-zA-Z0-9_-]+$/ oppure essere il carattere jolly *. In caso contrario ToolSet lancia una InvalidArgumentException.
La modalità empty applica default sicuri a telemetria della sessione, archiviazione persistente dei token OAuth MCP, recupero e cache degli embedding, discovery delle istruzioni, hook su file, operazioni git sull’host, session store, GitHub cache store, skill, memoria e modalità sperimentale.
Le opzioni di sessione impostate esplicitamente hanno la precedenza su questi default.
systemMessage in modalità replace viene usato così com’è. Le altre modalità rimuovono la sezione environment_context.
L’SDK imposta inoltre COPILOT_DISABLE_KEYTAR=1 per il processo CLI.
GitHub cache store
ImpostaenableGitHubCacheStore: true per richiedere il GitHub cache store in sola lettura.
La CLI registra lo strumento github_sql solo quando il suo feature flag GITHUB_CACHE_STORE è abilitato.
Per le informazioni più recenti fai riferimento al repository GitHub.