Formati su disco di Devin air-gapped

Questa documentazione riguarda le distribuzioni di Devin per il governo federale. Torna alla documentazione di Devin

La CLI e Devin Desktop air-gapped conservano tutto il proprio stato in un numero ridotto di file, con formati documentati e stabili. Questa pagina indica dove si trova ciascun file, quali file devi creare tu e lo schema esatto del registro di audit, così da poterlo inoltrare al tuo SIEM.

Percorsi dei file

File creati da te

Questi sono gli input machine-wide. Ognuno ha un percorso predefinito, che può essere sostituito tramite una variabile d’ambiente; la variabile deve essere impostata nell’ambiente da cui viene avviato l’agente (consulta Variabili d’ambiente per le chiavi API per sapere come farlo in Desktop).

File	Percorso predefinito	Override	Formato	Documentazione
Licenza	`/etc/devin/license.devin-onprem-license`	`DEVIN_LICENSE_FILE`	Token firmato, su una sola riga	Licenza
File dei modelli	`/etc/devin/models.json`	`DEVIN_MODELS_FILE`	JSON, `"version": 0`	File dei modelli
File di autenticazione (facoltativo, abilita l’SSO)	`/etc/devin/auth.json`	`DEVIN_AUTH_FILE`	JSON, `"version": 0`	SSO
Bundle CA (facoltativo)	nessuno	`DEVIN_CA_BUNDLE`	PEM	Rete e certificati
Policy machine-wide (facoltativa)	Linux `/etc/devin/system.json`, macOS `/Library/Application Support/Devin/system.json`	nessuno	JSON	Configurazione di sistema della CLI

I percorsi predefiniti sono gli stessi su macOS e Linux. Su Windows, la licenza, il file dei modelli e il file di autenticazione si trovano per impostazione predefinita in C:\ProgramData\Devin\ (license.devin-onprem-license, models.json, auth.json), il file dei criteri machine-wide è C:\ProgramData\Devin\system.json e le variabili di override restano le stesse; proteggi la cartella prima di inserirvi i file. La CLI legge questi file ma non vi scrive mai, quindi puoi gestirli con i tuoi strumenti di gestione della configurazione e impostarli in sola lettura.

Stato Per-user scritto dalla CLI

La CLI segue la struttura delle directory di base XDG sia su macOS sia su Linux (non usa ~/Library per il proprio stato). Le variabili XDG_CONFIG_HOME e XDG_DATA_HOME, se impostate, vengono rispettate.

Percorso	Contenuto
`~/.config/devin/config.json`	Configurazione utente condivisa con la Devin CLI standard (autorizzazioni, `proxy` e così via). Non contiene mai credenziali. Consulta il riferimento del file di configurazione della CLI.
`~/.config/devin/mcp_config.json`	Server MCP configurati localmente.
`~/.local/share/devin/sso_tokens.toml`	Cache dei token SSO scritta da `devin auth login`, con autorizzazioni riservate al proprietario (`0600`). Viene eliminata da `devin auth logout`.
`~/.local/share/devin/cli-federal/sessions.db`	Cronologia delle sessioni (SQLite). Include il contenuto delle conversazioni: trattala come dato sensibile.
`~/.local/share/devin/cli-federal/audit/`	Directory del registro di audit: contiene `audit.jsonl`, i file ruotati `audit-<timestamp>.jsonl` e il lock consultivo `.audit.lock`. Lo schema è descritto più avanti.

cli-federal è la sottodirectory di prodotto usata dalla build air-gapped; tiene questo stato separato da eventuali installazioni della Devin CLI standard sulla stessa macchina, che usano cli. Su Windows la CLI non legge le variabili XDG_*. Salva gli stessi file in %APPDATA%\devin\ e la propria cache in %LOCALAPPDATA%\devin\:

Percorso (Windows)	Contenuto
`%APPDATA%\devin\config.json`	Configurazione utente, come sopra.
`%APPDATA%\devin\mcp_config.json`	Server MCP configurati localmente.
`%APPDATA%\devin\sso_tokens.toml`	Cache dei token SSO.
`%APPDATA%\devin\cli-federal\sessions.db`	Cronologia delle sessioni (SQLite).
`%APPDATA%\devin\cli-federal\audit\`	Directory del registro di audit.

Stato specifico di Desktop

L’applicazione Desktop è isolata da qualsiasi altra installazione di Devin Desktop o Windsurf presente sulla stessa macchina:

Percorso	Contenuto
`~/.devin-airgap-config/`	Un `XDG_CONFIG_HOME` isolato che Desktop passa all’agente incluso nel bundle. Al suo interno, `devin/config.json` è un collegamento simbolico al file reale `~/.config/devin/config.json`, così la CLI e l’agente incluso nel bundle condividono un’unica configurazione utente. Nessun altro file di `~/.config/devin/` (in particolare `mcp_config.json`) è visibile all’agente all’interno di Desktop.
`~/.devin-airgap/`	Directory delle estensioni di Desktop.
`~/.codeium/windsurf-airgap/`	Stato del language-server.
Linux `~/.config/Devin - Airgap/`, macOS `~/Library/Application Support/Devin - Airgap/`	Dati utente di Desktop: `User/settings.json` (incluso `devin.acp.agentEnv`), stato delle finestre.

Il collegamento simbolico viene creato all’avvio di Desktop solo se in ~/.devin-airgap-config/devin/config.json non esiste ancora nulla. Se è già presente un file normale, Desktop lo lascia invariato e l’agente incluso nel bundle usa quel file anziché quello condiviso; il canale di output Devin ACP registra una riga WARNING: … is a regular file, not a symlink. Per ripristinare il collegamento, elimina il file e riavvia Desktop. Su Windows non viene usato alcun collegamento simbolico: l’agente incluso nel bundle di Desktop e la CLI condividono direttamente %APPDATA%\devin\config.json, e Desktop non carica il file %APPDATA%\devin\mcp_config.json dell’utente. I dati utente di Desktop si trovano in %APPDATA%\Devin - Airgap\. Per una reinstallazione da zero, solo ~/.devin-airgap-config/ e ~/.devin-airgap/ possono essere eliminate in sicurezza. ~/.config/devin/ e ~/.local/share/devin/ sono usate anche dalla CLI autonoma.

Registro di audit

La CLI air-gapped genera un registro di audit locale, strutturato e di sola aggiunta (append-only). È sempre attivo (non è previsto alcun toggle), non è presente in nessun’altra build di Devin e viene salvato sulla workstation per la tua revisione e per l’ingestione nel SIEM.

Posizione e rotazione

Proprietà	Valore
File attivo	`~/.local/share/devin/cli-federal/audit/audit.jsonl` (Windows: `%APPDATA%\devin\cli-federal\audit\audit.jsonl`)
Formato	JSON Lines: un oggetto JSON autonomo per riga, UTF-8
Autorizzazioni	La directory e i file vengono creati con accesso riservato al proprietario (`0600`)
Rotazione	Quando `audit.jsonl` raggiunge 10 MiB, viene rinominato in `audit-<UTC timestamp>.jsonl` (ad esempio `audit-20260127T234500123Z.jsonl`) e si inizia a scrivere su un nuovo file
Conservazione	Vengono mantenuti al massimo 10 file ruotati; i più vecchi vengono eliminati per primi
Concorrenza	La rotazione è protetta dal lock consultivo `.audit.lock`, così i processi CLI concorrenti non eseguono mai una doppia rotazione

Se ti serve una conservazione illimitata, invia i file ruotati al tuo SIEM prima che vengano eliminati. Poiché la CLI si limita ad aggiungere righe in coda e non riscrive mai quelle esistenti, è sufficiente un collector standard basato sul tailing dei file; consulta Inoltrare il registro di audit al tuo SIEM.

Garanzie di oscuramento

Gli eventi includono solo percorsi e metadati. Il log non contiene mai prompt, risposte del modello, codice, contenuti dei file, valori segreti, chiavi API né righe di comando della shell complete: per gli strumenti della shell viene registrato solo il nome del programma (il primo token).

Envelope (versione dello schema 1)

Ogni riga contiene questo envelope; i campi specifici di ciascun evento sono appiattiti allo stesso livello.

Campo	Tipo	Descrizione
`schema_version`	number	Attualmente `1`. Viene incrementato solo in caso di modifiche non retrocompatibili.
`ts`	string	Timestamp UTC in formato RFC 3339 con millisecondi.
`pid`	number	ID del processo CLI che ha emesso l’evento.
`event`	string	Tipo di evento; determina i campi restanti.

Configura il tuo parser in modo che ignori i campi e i valori di event sconosciuti: nuovi campi e tipi di evento possono essere aggiunti senza incrementare schema_version.

Tipi di evento

`session_start`

Emesso all’avvio di una sessione dell’agente (sessione root nuova o ripresa).

Campo	Tipo	Descrizione
`session_id`	string	ID sessione della CLI. Usalo per correlare tutti gli altri eventi della sessione.
`source`	string	Modalità di avvio della sessione (ad esempio `startup`).
`cli_version`	string	Versione rilasciata della CLI, come restituita da `devin --version`.
`actor`	object	Attribuzione dell’identità; vedi oggetto `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`

Emesso quando la sessione termina o l’agente si arresta.

Campo	Tipo	Descrizione
`session_id`	string	ID sessione della CLI.
`reason`	string	`prompt_input_exit`, `clear`, `resume`, `logout` o `other`.

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

In caso di uscita regolare, ogni session_start è associato esattamente a un session_end con lo stesso session_id. La CLI esegue l’agente in un processo figlio, che termina in fase di chiusura: per questo è il processo padre a registrare il session_end della sessione figlia (motivo other) al termine della sessione. Una sessione terminata da SIGKILL o da un’interruzione di corrente non può scrivere un evento finale; considera un session_start privo di un session_end corrispondente come una terminazione anomala.

`tool_call`

Emesso dopo ogni esecuzione di uno strumento da parte dell’agente.

Campo	Tipo	Descrizione
`session_id`	string	ID sessione della CLI.
`tool_name`	string	Nome dello strumento (ad esempio `read`, `write`, `exec`).
`tool_id`	string	ID univoco di questa invocazione dello strumento.
`success`	boolean	Indica se lo strumento ha segnalato un esito positivo.
`program`	string, optional	Per gli strumenti shell: solo il nome del programma, mai gli argomenti.
`paths`	string[], optional	Percorsi del filesystem a cui era limitato l’ambito dello strumento. Omesso se vuoto.

{"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` e `file_write`

Vengono emessi in aggiunta a tool_call, una volta per ciascun percorso incluso nell’ambito di autorizzazione determinato per lo strumento. Descrivono l’accesso entro cui lo strumento era circoscritto, non operazioni di I/O verificate: uno strumento approvato con ambito di lettura su più percorsi emette un file_read per ciascun percorso anche se ne ha usati solo alcuni, e gli eventi vengono emessi indipendentemente dall’esito della tool call.

Campo	Tipo	Descrizione
`session_id`	string	ID sessione della CLI.
`path`	string	Percorso nel filesystem.

{"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`

Emesso dopo ogni richiesta di inferenza a un endpoint di modello definito nel tuo file dei modelli.

Campo	Tipo	Descrizione
`session_id`	stringa	ID sessione della CLI.
`model`	stringa	Nome del modello nel file dei modelli.
`endpoint`	stringa, facoltativo	URL di base dell’endpoint configurato.
`input_tokens`	numero, facoltativo	Totale dei token di input, incluse le letture dalla cache.
`output_tokens`	numero, facoltativo	Token di output.
`cache_read_tokens`	numero, facoltativo	Token letti dalla cache, se forniti dall’endpoint.
`cache_creation_tokens`	numero, facoltativo	Token scritti nella cache, se forniti.

I campi relativi ai token vengono omessi quando l’endpoint non fornisce i dati di utilizzo.

{"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	Descrizione
`action`	string	Una delle azioni elencate di seguito.
`actor`	object	Attribuzione dell’identità; vedi oggetto `actor`.
`error_code`	string, facoltativo	Per `sso_login_denied` e `sso_revalidation_failed`: il codice `IDPnnn` mostrato all’utente. Omesso per le azioni riuscite.

`action`	Descrizione
`identity_resolved`	Attribuzione dell’identità all’inizio della sessione e dopo ogni comando `devin auth` (in questo modo `status` indica il login convalidato e `logout` non ne indica nessuno).
`license_validated`	Il file di licenza è stato convalidato correttamente all’avvio.
`license_installed`	Un file di licenza è stato scritto tramite la pagina Settings di Desktop. Non include né il percorso né il contenuto del file.
`sso_login`	Login SSO completato (`devin auth login` o accesso da Desktop).
`sso_login_denied`	Login SSO rifiutato dopo la risposta dell’IdP: manca il gruppo richiesto (`IDP004`), oppure il token ID restituito non ha superato la convalida o era assente (`IDP005`). Se il token è stato convalidato, `actor` contiene l’identità garantita dall’IdP; nulla viene memorizzato nella cache.
`sso_refresh`	Token SSO aggiornati presso l’IdP.
`sso_logout`	Logout SSO (`devin auth logout` o disconnessione da Desktop).
`sso_revalidation_failed`	Un agente in esecuzione ha perso il login SSO e si sta arrestando; vedi Riconvalida nelle sessioni in esecuzione.

{"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"]}}

Oggetto `actor`

L’attribuzione dell’identità comprende l’utente del sistema operativo, l’identità Git locale e (quando SSO è configurato) l’identità ricavata dall’ID token convalidato. I campi non disponibili vengono omessi.

Campo	Tipo	Descrizione
`os_user`	string, facoltativo	`$USER`.
`git_user_name`	string, facoltativo	`git config user.name`.
`git_user_email`	string, facoltativo	`git config user.email`.
`sso_issuer`	string, facoltativo	L’URL dell’emittente IdP rispetto al quale è stato convalidato il token.
`sso_subject`	string, facoltativo	Il claim `sub` dell’ID token.
`sso_user`	string, facoltativo	L’identità mostrata da `devin auth status` (`preferred_username`, `email` o `sub`).
`sso_groups`	string[], facoltativo	I claim di gruppo del token (`groups` per impostazione predefinita, oppure il `groups_claim` configurato).

I campi SSO sono presenti in ogni evento auth che dispone di un token convalidato (sso_login, sso_refresh, sso_logout, sso_login_denied), in sso_revalidation_failed per il login convalidato dal processo (oppure, se il processo non ne ha convalidato nessuno, per il login ancora presente nella cache dei token) e in session_start e identity_resolved per il login convalidato all’avvio dal processo in esecuzione. tool_call, file_read, file_write e model_call non contengono actor: per attribuirli, collegali tramite session_id al relativo evento session_start.

sso_groups registra le appartenenze ai gruppi IdP di ciascun utente sulla macchina locale. La directory e i file di audit sono accessibili solo al proprietario; se nel tuo ambiente i nomi dei gruppi sono dati sensibili, includili nella revisione delle tue pratiche di gestione dei dati.

Inoltra il registro di audit al tuo SIEM

Devin non invia i record di audit da nessuna parte. Per aggregare l’utilizzo di più workstation, configura l’agente di raccolta dei log già usato dal tuo SIEM (ad esempio uno Splunk universal forwarder o Elastic Agent) in modo che legga la directory di audit su ciascuna workstation. Non è richiesta alcuna impostazione in Devin. Configura l’input da file dell’agente con queste impostazioni:

Impostazione	Valore
File da raccogliere	`audit*.jsonl` nella directory di audit. Questo pattern include sia il file attivo sia i file ruotati. Non raccogliere `.audit.lock`.
Percorso per tutti gli utenti di una workstation	Linux: `/home//.local/share/devin/cli-federal/audit/audit.jsonl`. macOS: `/Users//.local/share/devin/cli-federal/audit/audit.jsonl`. Questi percorsi coprono solo le directory home sotto `/home` e `/Users`; modificali se le directory home si trovano altrove o se i tuoi utenti impostano `XDG_DATA_HOME`.
Formato dei record	Un oggetto JSON per riga. Non è necessaria alcuna gestione multiriga.
Timestamp	Il campo `ts`: RFC 3339, UTC, precisione al millisecondo.
Posizione iniziale	Inizio del file, in modo da raccogliere anche i record scritti prima dell’installazione dell’agente.
Rotazione	La rotazione rinomina il file attivo e crea un nuovo `audit.jsonl`. L’agente deve monitorare i file in base all’identità e non al nome, in modo che un file rinominato non venga letto due volte. Verifica come il tuo agente gestisce i file rinominati.
Campi sconosciuti	Conservali. Possono essere aggiunti nuovi campi e tipi di evento senza che `schema_version` cambi.

La directory e i file di audit sono leggibili solo dall’utente proprietario e Devin reimposta queste autorizzazioni ogni volta che apre il log. Esegui l’agente di raccolta come root o come l’utente stesso. Non modificare le autorizzazioni dei file per concedere l’accesso a un altro account: la modifica non viene mantenuta.

La workstation di ciascun utente conserva il file attivo più un massimo di 10 file ruotati da 10 MiB ciascuno, per circa 110 MiB in totale. I record che eccedono questo limite vengono eliminati, quindi una workstation che produce più dati di questa quantità tra una raccolta e l’altra perde i record più vecchi. Per verificare che la raccolta funzioni, avvia e termina una sessione Devin su una workstation, quindi cerca nel tuo SIEM un record session_start e un record session_end con lo stesso session_id.

Esempio: Splunk universal forwarder

Distribuisci questi due file in un’app su ciascun forwarder (ad esempio $SPLUNK_HOME/etc/apps/devin_audit/local/). Usa solo la stanza monitor relativa al sistema operativo della workstation e sostituisci devin con l’indice che vuoi usare.

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 deve trovarsi sul forwarder, non solo sugli indexer, perché INDEXED_EXTRACTIONS viene applicato nel punto in cui il file viene letto. Non impostare crcSalt: in questo modo il forwarder riconosce un file ruotato dal suo contenuto e non lo rilegge con il nuovo nome. Ogni directory nel percorso con caratteri jolly deve essere leggibile dall’account con cui viene eseguito il forwarder; un forwarder installato come account di servizio non root non può leggere le directory di audit accessibili solo al proprietario. I campi arrivano come campi indicizzati con i rispettivi nomi JSON, quindi actor.sso_user, model e input_tokens sono ricercabili direttamente:

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

Esempio: Elastic (Filebeat o Elastic Agent)

Aggiungi questo input filestream a filebeat.yml. Mantieni solo il percorso corrispondente al sistema operativo della workstation.

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"

Il parser ndjson inserisce ogni record sotto il prefisso devin. (devin.event, devin.session_id, devin.actor.sso_user). Non impostare target: "": il campo event del record è una stringa, che entra in conflitto con l’oggetto event dell’Elastic Common Schema e induce Elasticsearch a rifiutare i documenti. Il processore timestamp copia ts in @timestamp; Elastic contrassegna questo processore come beta, quindi, se preferisci, puoi rimuoverlo e impostare @timestamp a partire da devin.ts in una pipeline di ingestione. L’id deve essere univoco tra i tuoi input filestream. L’identità file predefinita di Filebeat è un’impronta dell’inizio del file, che continua a identificarlo anche dopo la ridenominazione eseguita dalla rotazione, quindi non serve alcuna impostazione di rotazione. La lunghezza dell’impronta viene ridotta dai 1024 byte predefiniti a 64 perché le versioni di Filebeat dalla 9.0 alla 9.4 ignorano un file finché non raggiunge almeno quella lunghezza, e quindi salterebbero le workstation con pochi record. I primi 64 byte di un file di audit contengono ts e pid del primo record, il che garantisce impronte distinte. Se in seguito modifichi la lunghezza, Filebeat rileggerà tutti i file. Con Elastic Agent, aggiungi l’integrazione Custom Logs (Filestream) alla policy dell’agente, specifica gli stessi percorsi e inserisci i blocchi parsers e processors indicati sopra nel campo di configurazione personalizzata dell’integrazione.

Cognition non ha testato questi esempi su una distribuzione Splunk o Elastic. Convalidali nel tuo ambiente e consulta la documentazione del fornitore relativa alla versione installata prima di distribuirli sulle workstation.

Campi utili da indicizzare o su cui eseguire ricerche:

Domanda	Campi
Chi ha usato Devin e quando	`event` = `session_start`, con `actor.sso_user` (o `actor.os_user`) e `ts`
Quale versione è distribuita	`cli_version` su `session_start`
Utilizzo dei token per modello	`event` = `model_call`, con `model`, `input_tokens`, `output_tokens`
Tool call non riuscite	`event` = `tool_call`, con `success` = `false`
Accessi rifiutati	`event` = `auth`, con `action` = `sso_login_denied` e `error_code`

Solo i record session_start e auth identificano l’utente. Per attribuire a un utente i record tool_call, file_read, file_write e model_call, collegali al record session_start con lo stesso session_id.

Report diagnostico

devin diagnostics genera un report in testo semplice, con i dati sensibili oscurati, che puoi esaminare prima di inviarlo al supporto di Cognition. Contiene solo le versioni, la struttura della configurazione (se ciascun file esiste e viene analizzato correttamente), i nomi dei modelli, l’indicazione se ciascuna variabile della chiave API è impostata e le statistiche del log di audit; non contiene mai prompt, codice, contenuti dei file, valori segreti, URL degli endpoint o valori delle variabili d’ambiente.

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> per scegliere il nome del file. Il report viene salvato con permessi di accesso riservati al solo proprietario (0600). Consulta Risoluzione dei problemi per sapere cosa includere in una richiesta di assistenza.

​Percorsi dei file

​File creati da te

​Stato Per-user scritto dalla CLI

​Stato specifico di Desktop

​Registro di audit

​Posizione e rotazione

​Garanzie di oscuramento

​Envelope (versione dello schema 1)

​Tipi di evento

​session_start

​session_end

​tool_call

​file_read e file_write

​model_call

​auth

​Oggetto actor

​Inoltra il registro di audit al tuo SIEM

​Esempio: Splunk universal forwarder

​Esempio: Elastic (Filebeat o Elastic Agent)

​Report diagnostico

Percorsi dei file

File creati da te

Stato Per-user scritto dalla CLI

Stato specifico di Desktop

Registro di audit

Posizione e rotazione

Garanzie di oscuramento

Envelope (versione dello schema 1)

Tipi di evento

`session_start`

`session_end`

`tool_call`

`file_read` e `file_write`

`model_call`

`auth`

Oggetto `actor`

Inoltra il registro di audit al tuo SIEM

Esempio: Splunk universal forwarder

Esempio: Elastic (Filebeat o Elastic Agent)

Report diagnostico