Formatos en disco de Devin aislado de la red

Esta documentación corresponde a las implementaciones federales de Devin. Volver a la documentación de Devin

La CLI y Desktop aislados de la red almacenan todo su estado en un pequeño conjunto de archivos con formatos documentados y estables. En esta página se indica dónde se encuentra cada archivo, cuáles debes crear tú y el esquema exacto del registro de auditoría, para que puedas reenviarlo a tu SIEM.

Ubicación de los archivos

Archivos que creas tú

Estas son las entradas machine-wide. Cada una tiene una ruta predeterminada y una variable de entorno que la anula. La variable debe estar definida en el entorno desde el que se inicia el agente (consulta Variables de entorno de la clave de API para saber cómo hacerlo en Desktop).

Archivo	Ruta predeterminada	Anulación	Formato	Documentado en
Licencia	`/etc/devin/license.devin-onprem-license`	`DEVIN_LICENSE_FILE`	Token firmado, una sola línea	Licencia
Archivo de modelos	`/etc/devin/models.json`	`DEVIN_MODELS_FILE`	JSON, `"version": 0`	Archivo de modelos
Archivo de autenticación (opcional, habilita el SSO)	`/etc/devin/auth.json`	`DEVIN_AUTH_FILE`	JSON, `"version": 0`	SSO
Paquete de CA (opcional)	ninguna	`DEVIN_CA_BUNDLE`	PEM	Red y certificados
Política machine-wide (opcional)	Linux `/etc/devin/system.json`, macOS `/Library/Application Support/Devin/system.json`	ninguna	JSON	Configuración del sistema de la CLI

Las rutas predeterminadas son las mismas en macOS y Linux. En Windows, la licencia, el archivo de modelos y el archivo de autenticación se encuentran de forma predeterminada en C:\ProgramData\Devin\ (license.devin-onprem-license, models.json, auth.json), el archivo de políticas machine-wide es C:\ProgramData\Devin\system.json y las variables de anulación son las mismas. Restringe el acceso a la carpeta antes de colocar archivos en ella. La CLI lee estos archivos, pero nunca escribe en ellos, así que puedes gestionarlos con tus herramientas de gestión de la configuración y configurarlos como de solo lectura.

Estado por usuario escrito por la CLI

La CLI sigue la estructura de directorios base de XDG tanto en macOS como en Linux (no usa ~/Library para su propio estado). Si XDG_CONFIG_HOME y XDG_DATA_HOME están definidas, se respetan.

Ruta	Contenido
`~/.config/devin/config.json`	Configuración de usuario compartida con la Devin CLI estándar (permisos, `proxy`, etc.). Nunca contiene credenciales. Consulta la referencia del archivo de configuración de la CLI.
`~/.config/devin/mcp_config.json`	Servidores MCP configurados localmente.
`~/.local/share/devin/sso_tokens.toml`	Caché de tokens de SSO escrita por `devin auth login`, con permisos exclusivos para el propietario (`0600`). `devin auth logout` la elimina.
`~/.local/share/devin/cli-federal/sessions.db`	Historial de sesiones (SQLite). Incluye el contenido de las conversaciones; trátalo como información confidencial.
`~/.local/share/devin/cli-federal/audit/`	Directorio del registro de auditoría: `audit.jsonl`, los archivos rotados `audit-<timestamp>.jsonl` y el bloqueo consultivo `.audit.lock`. El esquema se describe más abajo.

cli-federal es el subdirectorio de producto que usa la compilación aislada de la red; así, este estado se mantiene separado de cualquier instalación estándar de la Devin CLI en la misma máquina, que usa cli. En Windows, la CLI no lee las variables XDG_*. Guarda los mismos archivos en %APPDATA%\devin\ y su caché en %LOCALAPPDATA%\devin\:

Ruta (Windows)	Contenido
`%APPDATA%\devin\config.json`	Configuración de usuario, como se indica arriba.
`%APPDATA%\devin\mcp_config.json`	Servidores MCP configurados localmente.
`%APPDATA%\devin\sso_tokens.toml`	Caché de tokens de SSO.
`%APPDATA%\devin\cli-federal\sessions.db`	Historial de sesiones (SQLite).
`%APPDATA%\devin\cli-federal\audit\`	Directorio del registro de auditoría.

Estado específico de Desktop

La aplicación Desktop está aislada de cualquier otra instalación de Devin Desktop o Windsurf en la misma máquina:

Ruta	Contenido
`~/.devin-airgap-config/`	Un `XDG_CONFIG_HOME` aislado que Desktop pasa al agente integrado. Dentro de él, `devin/config.json` es un enlace simbólico al archivo real `~/.config/devin/config.json`, de modo que la CLI y el agente integrado comparten la misma configuración de usuario. El agente que se ejecuta dentro de Desktop no ve ningún otro elemento de `~/.config/devin/` (en particular, `mcp_config.json`).
`~/.devin-airgap/`	Directorio de extensiones de Desktop.
`~/.codeium/windsurf-airgap/`	Estado del language-server.
Linux `~/.config/Devin - Airgap/`, macOS `~/Library/Application Support/Devin - Airgap/`	Datos de usuario de Desktop: `User/settings.json` (incluido `devin.acp.agentEnv`) y estado de las ventanas.

Desktop crea el enlace simbólico al iniciarse solo si no existe nada en ~/.devin-airgap-config/devin/config.json. Si ya hay un archivo normal en esa ubicación, Desktop no lo toca y el agente integrado usa ese archivo en lugar del compartido; además, el canal de salida Devin ACP registra una línea WARNING: … is a regular file, not a symlink. Para restaurar el enlace, elimine el archivo y reinicie Desktop. En Windows no se usa enlace simbólico: el agente integrado de Desktop y la CLI comparten directamente %APPDATA%\devin\config.json, y Desktop no carga el archivo %APPDATA%\devin\mcp_config.json del usuario. Los datos de usuario de Desktop se encuentran en %APPDATA%\Devin - Airgap\. Para hacer una reinstalación desde cero, solo es seguro eliminar ~/.devin-airgap-config/ y ~/.devin-airgap/. Los directorios ~/.config/devin/ y ~/.local/share/devin/ también los usa la CLI independiente.

Registro de auditoría

La CLI aislada de la red escribe un registro de auditoría local, estructurado y de solo anexión. Está siempre activo (no hay ningún interruptor para desactivarlo), no existe en ninguna otra compilación de Devin y se guarda en la estación de trabajo para que puedas revisarlo y para su ingesta en tu SIEM.

Ubicación y rotación

Propiedad	Valor
Archivo activo	`~/.local/share/devin/cli-federal/audit/audit.jsonl` (Windows: `%APPDATA%\devin\cli-federal\audit\audit.jsonl`)
Formato	JSON Lines: un objeto JSON autónomo por línea, en UTF-8
Permisos	El directorio y los archivos se crean con acceso exclusivo para el propietario (`0600`)
Rotación	Cuando `audit.jsonl` alcanza 10 MiB, se renombra a `audit-<UTC timestamp>.jsonl` (por ejemplo, `audit-20260127T234500123Z.jsonl`) y se crea un archivo nuevo
Retención	Se conservan como máximo 10 archivos rotados; los más antiguos se eliminan primero
Concurrencia	La rotación está protegida por el bloqueo consultivo `.audit.lock`, por lo que varios procesos de la CLI en ejecución simultánea nunca rotan el mismo archivo dos veces

Si necesitas una retención ilimitada, envía los archivos rotados a tu SIEM antes de que se eliminen. Como la CLI solo añade líneas y nunca reescribe las existentes, basta con un recolector estándar de seguimiento de archivos; consulta Reenviar el registro de auditoría a tu SIEM.

Garantías de ocultación de datos sensibles

Los eventos solo incluyen rutas y metadatos. El registro nunca contiene prompts, respuestas del modelo, código, contenido de archivos, valores secretos, claves de API ni líneas de comandos de shell completas: en el caso de las herramientas de shell, solo se registra el nombre del programa (el primer token).

Envoltura (versión de esquema 1)

Cada línea incluye esta envoltura; los campos propios de cada evento se aplanan al mismo nivel.

Campo	Tipo	Descripción
`schema_version`	number	Actualmente `1`. Solo se incrementa cuando hay cambios incompatibles.
`ts`	string	Marca de tiempo UTC en formato RFC 3339 con milisegundos.
`pid`	number	ID del proceso de la CLI que emite el evento.
`event`	string	Tipo de evento; determina los demás campos.

Configura tu analizador para que ignore los campos y los valores de event desconocidos: es posible que se agreguen nuevos campos y tipos de evento sin incrementar schema_version.

Tipos de eventos

`session_start`

Se emite cuando comienza una sesión del agente (sesión raíz nueva o reanudada).

Campo	Tipo	Descripción
`session_id`	string	ID de sesión de la CLI. Úsalo para relacionar todos los demás eventos de la sesión.
`source`	string	Cómo se inició la sesión (por ejemplo, `startup`).
`cli_version`	string	Versión publicada de la CLI, tal como la muestra `devin --version`.
`actor`	object	Atribución de identidad; consulta objeto `actor`.

{"schema_version":1,"ts":"2026-01-27T23:45:00.123Z","pid":4242,"event":"session_start","session_id":"a1b2","source":"startup","cli_version":"1.2.3","actor":{"os_user":"jsmith","git_user_name":"J. Smith","git_user_email":"jsmith@example.com","sso_issuer":"https://sso.example.com/realms/corp","sso_subject":"6f1c…","sso_user":"jsmith","sso_groups":["/devin-users"]}}

`session_end`

Se emite cuando finaliza la sesión o se detiene el agente.

Campo	Tipo	Descripción
`session_id`	string	ID de sesión de la CLI.
`reason`	string	`prompt_input_exit`, `clear`, `resume`, `logout` u `other`.

{"schema_version":1,"ts":"2026-01-27T23:59:59.000Z","pid":4242,"event":"session_end","session_id":"a1b2","reason":"prompt_input_exit"}

Cada session_start va emparejado con exactamente un session_end para el mismo session_id cuando la salida es limpia. La CLI ejecuta el agente en un proceso hijo que finaliza durante el cierre, por lo que el proceso padre registra el session_end de la sesión hija (motivo other) cuando la sesión termina. Una sesión interrumpida por SIGKILL o por un corte de energía no puede escribir un evento final; trata cualquier session_start sin su session_end correspondiente como una terminación anómala.

`tool_call`

Se emite después de cada herramienta que ejecuta el agente.

Campo	Tipo	Descripción
`session_id`	string	ID de sesión de la CLI.
`tool_name`	string	Nombre de la herramienta (por ejemplo, `read`, `write`, `exec`).
`tool_id`	string	ID único de esta invocación de la herramienta.
`success`	boolean	Indica si la herramienta se ejecutó correctamente.
`program`	string, opcional	Para herramientas de shell: solo el nombre del programa, nunca los argumentos.
`paths`	string[], opcional	Rutas del sistema de archivos a las que estaba limitada la herramienta. Se omite si está vacío.

{"schema_version":1,"ts":"2026-01-27T23:45:07.001Z","pid":4242,"event":"tool_call","session_id":"a1b2","tool_name":"exec","tool_id":"t_01","success":true,"program":"cargo"}

`file_read` y `file_write`

Se emiten además de tool_call, una vez por cada ruta incluida en el ámbito de permisos resuelto de la herramienta. Describen el acceso al que la herramienta estaba limitada, no operaciones de E/S verificadas: una herramienta aprobada con ámbito de lectura sobre varias rutas emite un file_read por cada ruta aunque solo haya accedido a algunas de ellas, y los eventos se emiten tanto si la llamada a herramienta tuvo éxito como si no.

Campo	Tipo	Descripción
`session_id`	string	ID de sesión de la CLI.
`path`	string	Ruta en el sistema de archivos.

{"schema_version":1,"ts":"2026-01-27T23:45:09.410Z","pid":4242,"event":"file_write","session_id":"a1b2","path":"/home/jsmith/repo/src/main.rs"}

`model_call`

Se emite después de cada solicitud de inferencia a un endpoint de modelo definido en tu archivo de modelos.

Campo	Tipo	Descripción
`session_id`	string	ID de sesión de la CLI.
`model`	string	Nombre del modelo en el archivo de modelos.
`endpoint`	string, opcional	URL base del endpoint configurado.
`input_tokens`	number, opcional	Total de tokens de entrada, incluidas las lecturas de caché.
`output_tokens`	number, opcional	Tokens de salida.
`cache_read_tokens`	number, opcional	Tokens leídos de la caché, si el endpoint los reporta.
`cache_creation_tokens`	number, opcional	Tokens escritos en la caché, si se reportan.

Los campos de tokens se omiten cuando el endpoint no reporta el consumo.

{"schema_version":1,"ts":"2026-01-27T23:45:12.900Z","pid":4242,"event":"model_call","session_id":"a1b2","model":"llama-3-70b","endpoint":"https://models.internal:8000/v1","input_tokens":5120,"output_tokens":384}

`auth`

Campo	Tipo	Descripción
`action`	string	Una de las acciones que se indican a continuación.
`actor`	object	Atribución de identidad; consulta objeto `actor`.
`error_code`	string, optional	En `sso_login_denied` y `sso_revalidation_failed`: el código `IDPnnn` que se mostró al usuario. Se omite en las acciones completadas correctamente.

`action`	Descripción
`identity_resolved`	Atribución de identidad al inicio de la sesión y después de cada comando `devin auth` (así, `status` indica el inicio de sesión que validó y `logout` no indica ninguno).
`license_validated`	El archivo de licencia se validó correctamente al iniciar.
`license_installed`	Se guardó un archivo de licencia desde la página Settings de Desktop. No incluye la ruta ni el contenido del archivo.
`sso_login`	Se completó el inicio de sesión con SSO (`devin auth login` o el inicio de sesión de Desktop).
`sso_login_denied`	Se rechazó el inicio de sesión con SSO tras la respuesta del IdP: falta el grupo obligatorio (`IDP004`), o el token de ID devuelto no superó la validación o no se recibió (`IDP005`). `actor` contiene la identidad que el IdP avaló si el token se validó; no se almacena nada en caché.
`sso_refresh`	Se renovaron los tokens de SSO con el IdP.
`sso_logout`	Cierre de sesión de SSO (`devin auth logout` o el cierre de sesión de Desktop).
`sso_revalidation_failed`	Un agente en ejecución perdió su inicio de sesión con SSO y se está cerrando; consulta Revalidación en sesiones en ejecución.

{"schema_version":1,"ts":"2026-01-27T23:44:58.000Z","pid":4241,"event":"auth","action":"sso_login","actor":{"os_user":"jsmith","git_user_name":"J. Smith","git_user_email":"jsmith@example.com","sso_issuer":"https://sso.example.com/realms/corp","sso_subject":"6f1c…","sso_user":"jsmith","sso_groups":["/devin-users"]}}
{"schema_version":1,"ts":"2026-01-28T08:10:02.512Z","pid":5150,"event":"auth","action":"sso_login_denied","error_code":"IDP004","actor":{"os_user":"rjones","sso_issuer":"https://sso.example.com/realms/corp","sso_subject":"a90d…","sso_user":"rjones","sso_groups":["/contractors"]}}
{"schema_version":1,"ts":"2026-01-28T09:00:00.000Z","pid":4242,"event":"auth","action":"sso_revalidation_failed","error_code":"IDP003","actor":{"os_user":"jsmith","sso_issuer":"https://sso.example.com/realms/corp","sso_subject":"6f1c…","sso_user":"jsmith","sso_groups":["/devin-users"]}}

Objeto `actor`

La atribución de identidad se compone del usuario del sistema operativo, la identidad de Git local y (cuando SSO está configurado) la identidad del token de ID validado. Los campos se omiten cuando no están disponibles.

Campo	Tipo	Descripción
`os_user`	string, opcional	`$USER`.
`git_user_name`	string, opcional	`git config user.name`.
`git_user_email`	string, opcional	`git config user.email`.
`sso_issuer`	string, opcional	La URL del emisor del IdP con la que se validó el token.
`sso_subject`	string, opcional	La declaración `sub` del token de ID.
`sso_user`	string, opcional	La identidad que muestra `devin auth status` (`preferred_username`, `email` o `sub`).
`sso_groups`	string[], opcional	Las claims de grupo del token (`groups` de forma predeterminada, o el `groups_claim` configurado).

Los campos de SSO están presentes en todos los eventos auth que disponen de un token validado (sso_login, sso_refresh, sso_logout, sso_login_denied); en sso_revalidation_failed, para el inicio de sesión que validó el proceso (o, si no validó ninguno, el inicio de sesión que sigue en la caché de tokens), y en session_start e identity_resolved, para el inicio de sesión que el proceso en ejecución validó al arrancar. tool_call, file_read, file_write y model_call no incluyen actor; atribúyelos a su session_start mediante session_id.

sso_groups registra en la máquina local la pertenencia a grupos del IdP de cada usuario. El directorio y los archivos de auditoría solo son accesibles para su propietario; inclúyelos en tu revisión de tratamiento de datos si los nombres de los grupos son confidenciales en tu entorno.

Reenviar el registro de auditoría a tu SIEM

Devin no envía los registros de auditoría a ningún sitio. Para centralizar el consumo de todas las estaciones de trabajo, apunta el agente de recopilación de registros que ya usa tu SIEM (por ejemplo, un Splunk universal forwarder o Elastic Agent) al directorio de auditoría de cada estación de trabajo. No hace falta configurar nada en Devin. Configura la entrada de archivos del agente con estos ajustes:

Ajuste	Valor
Archivos que se recopilan	`audit*.jsonl` en el directorio de auditoría. Este patrón abarca tanto el archivo activo como los archivos rotados. No recopiles `.audit.lock`.
Ruta para todos los usuarios de una estación de trabajo	Linux: `/home//.local/share/devin/cli-federal/audit/audit.jsonl`. macOS: `/Users//.local/share/devin/cli-federal/audit/audit.jsonl`. Estas rutas solo cubren los directorios personales ubicados en `/home` y `/Users`; ajústalas si los directorios personales están en otra ubicación o si tus usuarios definen `XDG_DATA_HOME`.
Formato de registro	Un objeto JSON por línea. No es necesario gestionar registros multilínea.
Marca de tiempo	El campo `ts`: RFC 3339, UTC, con precisión de milisegundos.
Posición inicial	Inicio del archivo, para que también se recopilen los registros escritos antes de instalar el agente.
Rotación	La rotación renombra el archivo activo y crea un nuevo `audit.jsonl`. El agente debe rastrear los archivos por identidad y no por nombre, para no volver a leer un archivo renombrado. Comprueba cómo gestiona tu agente los archivos renombrados.
Campos desconocidos	Consérvalos. Pueden añadirse nuevos campos y tipos de evento sin que cambie `schema_version`.

El directorio y los archivos de auditoría solo puede leerlos el usuario propietario, y Devin restablece estos permisos cada vez que abre el registro. Ejecuta el agente de recopilación como root o como ese usuario. No cambies los permisos de los archivos para dar acceso a otra cuenta, ya que el cambio no se mantiene.

La estación de trabajo de cada usuario conserva el archivo activo y un máximo de 10 archivos rotados de 10 MiB cada uno, unos 110 MiB en total. Lo que exceda ese límite se elimina, por lo que una estación de trabajo que genere más datos entre una recopilación y la siguiente perderá sus registros más antiguos. Para confirmar que la recopilación funciona, inicia y finaliza una sesión de Devin en una estación de trabajo y, a continuación, busca en tu SIEM un registro session_start y un registro session_end con el mismo session_id.

Ejemplo: Splunk universal forwarder

Despliega estos dos archivos en una aplicación de cada forwarder (por ejemplo, $SPLUNK_HOME/etc/apps/devin_audit/local/). Usa solo la stanza monitor que corresponda al sistema operativo de la estación de trabajo y sustituye devin por el índice que quieras usar.

inputs.conf

[monitor:///home/*/.local/share/devin/cli-federal/audit/audit*.jsonl]
sourcetype = devin:airgap:audit
index = devin
disabled = 0

[monitor:///Users/*/.local/share/devin/cli-federal/audit/audit*.jsonl]
sourcetype = devin:airgap:audit
index = devin
disabled = 0

props.conf

[devin:airgap:audit]
INDEXED_EXTRACTIONS = json
KV_MODE = none
SHOULD_LINEMERGE = false
TIMESTAMP_FIELDS = ts
TIME_FORMAT = %Y-%m-%dT%H:%M:%S.%3NZ
TZ = UTC

props.conf debe estar en el forwarder, no solo en los indexadores, porque INDEXED_EXTRACTIONS se aplica donde se lee el archivo. Deja crcSalt sin definir: así, el forwarder reconoce un archivo rotado por su contenido y no vuelve a leerlo con su nuevo nombre. La cuenta con la que se ejecuta el forwarder debe tener permiso de lectura sobre todos los directorios de la ruta con comodines; un forwarder instalado como cuenta de servicio sin privilegios de root no puede leer los directorios de auditoría restringidos al propietario. Los campos llegan como campos indexados con sus nombres JSON, por lo que actor.sso_user, model e input_tokens se pueden buscar directamente:

index=devin sourcetype="devin:airgap:audit" event=model_call | stats sum(input_tokens) sum(output_tokens) by model

Ejemplo: Elastic (Filebeat o Elastic Agent)

Agrega esta entrada filestream a filebeat.yml. Conserva solo la ruta correspondiente al sistema operativo de la estación de trabajo.

filebeat.yml

filebeat.inputs:
  - type: filestream
    id: devin-airgap-audit
    paths:
      - /home/*/.local/share/devin/cli-federal/audit/audit*.jsonl
      - /Users/*/.local/share/devin/cli-federal/audit/audit*.jsonl
    prospector.scanner.fingerprint.length: 64
    parsers:
      - ndjson:
          target: devin
          add_error_key: true
    processors:
      - timestamp:
          field: devin.ts
          layouts:
            - "2006-01-02T15:04:05.999Z"

El analizador ndjson coloca cada registro bajo el prefijo devin. (devin.event, devin.session_id, devin.actor.sso_user). No establezcas target: "": el campo event del registro es una cadena, lo que entra en conflicto con el objeto event del Elastic Common Schema y hace que Elasticsearch rechace los documentos. El procesador timestamp copia ts en @timestamp; Elastic marca este procesador como beta, así que, si lo prefieres, puedes eliminarlo y establecer @timestamp a partir de devin.ts en un pipeline de ingesta. El id debe ser único entre tus entradas filestream. De forma predeterminada, Filebeat identifica cada archivo mediante una huella digital de su inicio, que se mantiene aunque la rotación renombre el archivo, por lo que no hace falta configurar nada para la rotación. La longitud de la huella se reduce de los 1024 bytes predeterminados a 64 porque las versiones 9.0 a 9.4 de Filebeat ignoran un archivo hasta que alcanza al menos esa longitud, lo que haría que se omitieran las estaciones de trabajo con pocos registros. Los primeros 64 bytes de un archivo de auditoría contienen el ts y el pid del primer registro, lo que garantiza que las huellas sean distintas. Si cambias la longitud más adelante, Filebeat volverá a leer todos los archivos. Con Elastic Agent, agrega la integración Custom Logs (Filestream) a la política del agente, introduce las mismas rutas y coloca los bloques parsers y processors anteriores en el campo de configuración personalizada de la integración.

Cognition no ha probado estos ejemplos en un despliegue de Splunk o Elastic. Valídalos en tu entorno y consulta la documentación del proveedor correspondiente a tu versión instalada antes de desplegarlos en las estaciones de trabajo.

Campos útiles para indexar o realizar búsquedas:

Pregunta	Campos
Quién usó Devin y cuándo	`event` = `session_start`, con `actor.sso_user` (o `actor.os_user`) y `ts`
Qué versión está desplegada	`cli_version` en `session_start`
Uso de tokens por modelo	`event` = `model_call`, con `model`, `input_tokens`, `output_tokens`
Llamadas a herramientas fallidas	`event` = `tool_call`, con `success` = `false`
Inicios de sesión rechazados	`event` = `auth`, con `action` = `sso_login_denied` y `error_code`

Solo los registros session_start y auth identifican al usuario. Para atribuir los registros tool_call, file_read, file_write y model_call a un usuario, combínalos con el registro session_start que tenga el mismo session_id.

Informe de diagnósticos

devin diagnostics genera un informe en texto plano, con los datos sensibles ocultos, que puedes revisar antes de enviarlo al soporte de Cognition. Solo incluye versiones, la estructura de la configuración (si cada archivo existe y se puede analizar), nombres de modelos, si cada variable de clave de API está definida y estadísticas del registro de auditoría; nunca incluye prompts, código, contenido de archivos, valores secretos, URL de endpoints ni valores de variables de entorno.

devin diagnostics

Diagnostics written to devin-diagnostics-20260127T234500Z.txt
The report is plain text and stays on this machine; review it before sharing.

Usa --output <path> para elegir el nombre del archivo. El informe se guarda con permisos de acceso exclusivo para el propietario (0600). Consulta Solución de problemas para saber qué incluir en una solicitud de soporte.

​Ubicación de los archivos

​Archivos que creas tú

​Estado por usuario escrito por la CLI

​Estado específico de Desktop

​Registro de auditoría

​Ubicación y rotación

​Garantías de ocultación de datos sensibles

​Envoltura (versión de esquema 1)

​Tipos de eventos

​session_start

​session_end

​tool_call

​file_read y file_write

​model_call

​auth

​Objeto actor

​Reenviar el registro de auditoría a tu SIEM

​Ejemplo: Splunk universal forwarder

​Ejemplo: Elastic (Filebeat o Elastic Agent)

​Informe de diagnósticos

Ubicación de los archivos

Archivos que creas tú

Estado por usuario escrito por la CLI

Estado específico de Desktop

Registro de auditoría

Ubicación y rotación

Garantías de ocultación de datos sensibles

Envoltura (versión de esquema 1)

Tipos de eventos

`session_start`

`session_end`

`tool_call`

`file_read` y `file_write`

`model_call`

`auth`

Objeto `actor`

Reenviar el registro de auditoría a tu SIEM

Ejemplo: Splunk universal forwarder

Ejemplo: Elastic (Filebeat o Elastic Agent)

Informe de diagnósticos