Skip to main content

SessionConfig

Con la clase SessionConfig puedes configurar múltiples opciones. Se usa como Copilot::run(prompt: '...', config: $config) o Copilot::start(function (CopilotSession $session) { ... }, config: $config). Cuando solo quieres indicar el modelo y no vale la pena usar la clase SessionConfig, puedes pasarla como array: Copilot::run(prompt: '...', config: ['model' => 'auto']).

Raíces de descubrimiento

skillDirectories, agentDirectories, hookDirectories e instructionDirectories son raíces solo de descubrimiento para skills, agentes personalizados, hooks de archivo e instrucciones personalizadas. No otorgan al agente acceso general a archivos. Para añadir ubicaciones con acceso normal a archivos, usa additionalDirectories. Puedes configurar las raíces de descubrimiento tanto si enableConfigDiscovery está habilitado como si no. El SDK resuelve las rutas relativas una sola vez, respecto al workingDirectory efectivo en el momento en que las configuras. Las raíces no se mueven aunque el working directory cambie después. Omitir una clave o pasar null deja sin cambios las fuentes de descubrimiento por defecto. Pasar [] borra solo las raíces que el SDK configuró explícitamente. Siguen aplicándose los ajustes de deshabilitación por fuente y los Managed Settings para skills, agentes, hooks e instrucciones. Al reanudar sesión se usa la clase ResumeSessionConfig. Es casi igual a SessionConfig, con pequeñas diferencias. En ResumeSessionConfig indicas solo las opciones que quieres cambiar; el resto hereda la configuración del inicio de la sesión. El SDK envía las mismas opciones de sesión tanto en el payload RPC de creación como en el de reanudación. Esto incluye los proveedores y modelos BYOK, la memoria, enableMcpApps, interactiveUser, enableGitHubCacheStore, las raíces de descubrimiento y handlers como onMcpAuthRequest, onExitPlanModeRequest y onAutoModeSwitchRequest. Al reanudar, pásalos en ResumeSessionConfig o en un array con las mismas claves. Los closures y los objetos proveedor no se persisten, así que debes volver a indicarlos en cada reanudación.

Proveedores de canvas

El soporte de canvas es experimental.
Declara los canvases con canvases y procesa las solicitudes de apertura y de acciones con un canvasHandler. El runtime llama a tu handler mediante reverse RPC cuando el agente abre un canvas o invoca una de sus acciones. Configura requestCanvasRenderer: true para registrarte como renderer, de modo que el runtime exponga al modelo las herramientas de agente de canvas en esta conexión. Está desactivado por defecto para que los clientes del SDK que no pueden mostrar canvases no se vean afectados.
Opciones relacionadas:
  • requestExtensions: true activa la superficie de extensiones. El runtime conecta entonces las herramientas de gestión de extensiones a las sesiones de esta conexión. Desactivado por defecto.
  • extensionInfo: new ExtensionInfo(source: 'github-app', name: 'my-extension') establece un ID de extensión estable para los proveedores de canvas de esta conexión. El runtime usa ${source}:${name} en lugar del ID por conexión. También puedes pasar un array.
Al reanudar, vuelve a pasar canvases y canvasHandler. El canvasHandler solo se ejecuta dentro del proceso PHP. El SDK envía en el payload RPC únicamente los metadatos de la declaración. ResumeSessionConfig también acepta openCanvases, una instantánea de los canvases que estaban abiertos cuando se detuvo la sesión. El runtime la usa para restaurar el estado de los canvases, así que no necesitas volver a abrirlos. Obtén los canvases abiertos actualmente con $session->openCanvases(). El SDK mantiene esta lista sincronizada con los eventos session.canvas.opened y session.canvas.closed.

Proveedores de sistema de archivos de sesión

Callbacks de skills y sistema de archivos

Usa skillProvider para cargar skills desde una fuente gestionada por la aplicación. Los callbacks pertenecen a esa sesión y no se serializan hacia el runtime de Copilot. Las cloud sessions no soportan proveedores de skills personalizados.
SkillProviderCallOptions::$signal expone el token de cancelación del callback. La cancelación es cooperativa. Tus callbacks deben observar la señal y cancelar ellos mismos el trabajo pendiente. En lugar del array de callbacks, puedes implementar Revolution\Copilot\Contracts\SkillProvider. sessionFsProvider usa la misma configuración a nivel de sesión. Los callbacks de texto son readFile(path) y writeFile(path, content, mode). Para soportar archivos binarios, proporciona tanto readFileBytes(path) como writeFileBytes(path, bytes, mode), o implementa SessionFsBinaryProvider. Estos callbacks reciben y devuelven los bytes originales. El SDK se encarga de la codificación base64 en el canal JSON-RPC. Limita el acceso al sistema de archivos a las rutas que tu aplicación pretende exponer.

Delegar todo el estado de la sesión con sessionFs

Configura la opción de cliente sessionFs (alias session_fs) para trasladar todo el estado de sesión de Copilot CLI, incluidos los archivos de estado de sesión y la base de datos SQLite por sesión, a tu propio almacenamiento. Cuando la configuras, cada configuración de sesión debe proporcionar una factory createSessionFsProvider. El SDK llama a la factory tanto en createSession() como en resumeSession(), una vez conocido el session ID y antes de enviar la solicitud al runtime.
Con la facade Copilot, configura session_fs en config/copilot.php. initialCwd, sessionStatePath y conventions (posix o windows) son obligatorios. Si faltan campos o el valor de conventions no es válido, se lanza una InvalidArgumentException. createSessionFsProvider es un Closure. También funciona con arrays, fromArray() y toArray() en SessionConfig y ResumeSessionConfig. El proveedor que devuelve puede ser un objeto o un array de callables. Cada capacidad opcional tiene su propia interfaz: Si el proveedor no cumple las capacidades declaradas, el SDK lanza una InvalidArgumentException. Llamar a una operación que el proveedor no soporta devuelve un error UNKNOWN. Los proveedores indican los fallos lanzando excepciones. Una excepción cuyo code sea ENOENT (o errno 2) se convierte en ENOENT. Cualquier otra se convierte en UNKNOWN. Lanza SessionFsSqliteTransactionFailure desde transaction() para indicar un errorClass (busyOrLocked, fatal o postCommitAmbiguous). Sin la opción de cliente sessionFs, el SDK nunca llama a createSessionFsProvider, y el sessionFsProvider existente (readFile y writeFile) sigue funcionando.

Modo empty para aplicaciones multi-tenant

Configura el mode del cliente como empty para deshabilitar por defecto las funciones que dependen del entorno host de Copilot CLI o del estado compartido entre sesiones. El valor por defecto es copilot-cli, que mantiene el comportamiento existente. En el modo empty debes configurar un destino de persistencia: base_directory, session_fs o la url de un servidor externo.
Todas las sesiones en modo empty deben configurar availableTools. Usa ToolSet para construir filtros de herramientas cualificados por origen (builtin:, custom:, mcp:). BuiltInTools::Isolated permite solo herramientas integradas confinadas a una única sesión, sin acceso al sistema de archivos del host, al entorno, a la red ni a otras sesiones.
Los nombres de herramientas deben coincidir con /^[a-zA-Z0-9_-]+$/ o ser el comodín *. En caso contrario, ToolSet lanza una InvalidArgumentException. El modo empty aplica valores por defecto seguros a la telemetría de sesión, el almacenamiento persistente de tokens OAuth de MCP, la recuperación y caché de embeddings, el descubrimiento de instrucciones, los hooks de archivo, las operaciones git del host, el session store, el GitHub cache store, las skills, la memoria y el modo experimental. Las opciones de sesión que configures explícitamente tienen prioridad sobre estos valores por defecto. systemMessage en modo replace se usa tal cual. Los demás modos eliminan la sección environment_context. El SDK también establece COPILOT_DISABLE_KEYTAR=1 para el proceso de la CLI.

GitHub cache store

Configura enableGitHubCacheStore: true para solicitar el GitHub cache store de solo lectura. La CLI registra la herramienta github_sql solo cuando su feature flag GITHUB_CACHE_STORE está habilitado.
Para ejecución en cloud consulta Cloud Sessions; para Plugin Directory consulta Plugin Directories.
Consulta la información más reciente en el repositorio de GitHub.
Última modificación el 19 de octubre de 2026