# Sessioni Una sessione è un branch Git e una sandbox in cui lavora l’agente. Canonical page: https://beeuni.ai/docs/it/work/sessions Una sessione è una singola unità di lavoro dell'agente. Beeuni crea un branch Git e prepara una sandbox per la sessione. L'ID della sessione, il nome del branch e l'ID della sandbox hanno lo stesso valore. ## Stato Nella pratica, una sessione può trovarsi in 4 stati. | Stato | Significato | |---|---| | `provisioning` | Beeuni crea il branch e richiede la sandbox. | | `running` | La sandbox è attiva e raggiungibile. | | `stopped` | La sessione è in pausa, per scelta tua o per l'arresto automatico dopo un periodo di inattività. | | `failed` | Il provisioning non è riuscito. | Il database definisce altri 3 valori (`queued`, `branching`, `completed`). Al momento Beeuni non li assegna alle sessioni. ## Arresto, ripresa e arresto automatico per inattività Puoi arrestare una sessione manualmente. Riprendendola, riottieni la stessa sandbox, con lo stesso filesystem e la stessa identità di runtime. Si azzerano solo i processi in esecuzione e la memoria. La conversazione di harness standard rimane associata alla sessione. Beeuni arresta anche le sessioni inattive: - Dopo 15 minuti di inattività, per una sessione normale o un'esecuzione di un trigger. - Dopo 2 minuti di inattività, per una sessione worker avviata da un'altra sessione. Un turno dell'agente in corso impedisce l'arresto. Il processo di manutenzione viene eseguito ogni 5 minuti. Di conseguenza, un arresto automatico normale avviene circa 15–20 minuti dopo il turno nel terminale. Un turno in attesa di una persona non svolge alcun lavoro: l'agente ha posto una domanda o chiede il permesso di usare uno strumento. In questi casi, Beeuni mantiene attivo il computer per un massimo di 2 ore dal momento in cui rileva per la prima volta l'attesa. In un'esecuzione di un trigger o di una pianificazione, nessuno riceve la richiesta e il limite è di 30 minuti. Poi Beeuni termina il turno e arresta il computer. Invia un messaggio per continuare. Una chiamata al modello o la pagina della sessione aperta contano come attività e prolungano il funzionamento del computer come di consueto. La pagina di una sessione che stai usando la mantiene attiva. Conta come in uso quando la scheda è visibile e hai fatto clic, digitato, scorrimento o interagito con essa negli ultimi 10 minuti, e solo se puoi avviare sessioni nel progetto. Una scheda lasciata aperta senza interazioni smette di contare dopo 10 minuti, quindi la sessione si arresta circa 15–20 minuti dopo. La scheda aperta di un utente con accesso in sola lettura non mantiene mai attiva la sessione. La sola pagina mantiene attiva una sessione per un massimo di 2 ore dall'ultimo turno dell'agente; un nuovo messaggio avvia un turno e azzera il limite. ## Cosa viene conservato con l'arresto e cosa si perde con l'eliminazione > **L'eliminazione è definitiva** > > L'eliminazione di una sessione distrugge definitivamente la sua sandbox. Beeuni conserva il record della sessione e il branch Git, quindi puoi ancora recuperare il lavoro inviato al repository. Tutto ciò che non è stato inviato viene perso. L'arresto e la ripresa conservano l'identità e il filesystem della sandbox. L'eliminazione distrugge la sandbox. Git è l'unico registro permanente: il lavoro che l'agente salva con un commit e invia al repository sopravvive; tutto il resto viene perso. ## Etichette Un'etichetta classifica una sessione: `bug`, `customer: eu`, `worker`. Apri il menu `⋯` della sessione e scegli **Modifica etichette**. Il filtro **Etichette** nell'elenco delle sessioni mostra solo quelle che hanno tutte le etichette selezionate. Le etichette sono testo libero, da 1 a 64 caratteri, con un massimo di 20 per sessione. Anche agenti e script possono impostare etichette: `beeuni sessions new --label worker`, `beeuni sessions update --label needs-review` (all'interno di una sessione, senza un ID, applica l'etichetta a quella sessione) oppure `labels` nell'API e nell'SDK. Una sessione include anche un oggetto `metadata` a testo libero per le tue chiavi personalizzate: consulta Sessioni SDK. ## Runtime Una sessione esegue un solo harness: harness standard o harness sperimentale. Consulta [Harness](/docs/it/work/harnesses). Beeuni memorizza l'agente e il modello selezionati all'avvio della sessione. Una sessione in esecuzione mantiene il proprio harness finché non viene riavviata o ripresa. ## Accesso alla sessione Una sessione è privata per chi l'ha creata. Il proprietario apre **Accesso alla sessione** e sceglie una delle 3 opzioni. | Opzione | Chi può aprire la sessione | |---|---| | Solo tu | Solo il proprietario. È l'impostazione predefinita. | | Persone specifiche | Il proprietario, oltre ai membri e ai gruppi scelti dal proprietario. | | Intero progetto | Tutti i membri del progetto. | Chiunque abbia accesso può leggere la conversazione e proseguirla. **Una sessione condivisa usa chiavi condivise.** Una volta condivisa, la sessione usa solo le chiavi dei provider condivise con l'intero progetto, mai le chiavi personali di qualcuno né la sua connessione ChatGPT. Se il modello era eseguito con le tue chiavi personali, la condivisione lo fa passare alle chiavi del progetto per quel provider. Se il progetto non condivide alcuna chiave che consenta di eseguire il modello, la condivisione viene rifiutata e la sessione rimane privata. Consulta [Chiavi dei provider e accesso dei membri](/docs/it/project/models#provider-keys-and-member-access). **Solo il proprietario può modificare questa impostazione.** Un responsabile del progetto che non ha creato la sessione può aprirla se è stata condivisa con lui e può arrestarla, riavviarla o eliminarla. Non può modificare l'elenco delle persone che possono aprirla. Condividere una sessione con un responsabile non significa cedergli il controllo dell'elenco degli accessi. Un tipo di sessione non ha un proprietario umano: quelle create da un trigger, che vengono eseguite con l'identità dell'agente del trigger. A gestirle sono i responsabili del progetto. Imposta la policy per tutte direttamente sul trigger, in **Accesso alla sessione**: il salvataggio aggiorna anche le sessioni già create da quel trigger. ### Gli amministratori possono aprire tutte le sessioni Il proprietario di un account può consentire ai proprietari e agli amministratori dell'account di aprire **tutte** le sessioni dell'account, comprese quelle che i membri mantengono private. Attiva l'opzione in **Account → Impostazioni → Sicurezza → Gli amministratori possono aprire tutte le sessioni**. Per impostazione predefinita è disattivata. - **Solo il proprietario dell'account può modificare l'impostazione.** Gli amministratori vedono l'interruttore, ma non possono attivarlo o disattivarlo; così nessun amministratore può concedersi l'accesso al lavoro di tutti. - **Gli amministratori trovano queste sessioni nella pagina Sessioni del progetto.** La barra laterale continua a mostrare solo le sessioni avviate da te o condivise con te. - **L'accesso è completo.** Un amministratore può aprire e leggere la sessione e proseguirla, proprio come una sessione condivisa con l'intero progetto. - **I membri ne sono informati.** Quando l'opzione è attiva, la finestra di dialogo Accesso alla sessione indica che i proprietari e gli amministratori possono aprire tutte le sessioni. - **Tutto viene registrato.** Ogni modifica dell'impostazione viene registrata come `iam.session_oversight.enable` o `iam.session_oversight.disable`, e ogni sessione aperta da un amministratore tramite questa opzione come `project.admin_oversight_session_read` (al massimo una volta per amministratore e sessione ogni ora). - I token di agenti e sandbox non ottengono mai questo accesso, nemmeno se avviati da un amministratore. ### Trova una sessione per proprietario o accesso La pagina **Sessioni** del progetto mostra il proprietario e le impostazioni di accesso di ogni sessione nella rispettiva riga: l'avatar e il nome del proprietario (**Tu** per le tue sessioni), seguiti da un'icona che indica chi può aprirla: un lucchetto per **Solo il proprietario**, un'icona con persone per **Persone specifiche** e un globo per **Intero progetto**. Apri **Filtro** nella pagina Sessioni per restringere l'elenco: - **Proprietario** — una voce per persona, con il relativo conteggio. - **Accesso** — Solo il proprietario, Persone specifiche o Intero progetto. - **Raggruppamento → Proprietario** — una sezione per persona, con le tue sessioni per prime. I filtri si combinano con **Stato**, **Origine** e la ricerca. **Reimposta** li cancella tutti. > **Una sessione mantiene il suo proprietario** > > Rimuovere una persona dall'account non trasferisce le sue sessioni a qualcun altro. La policy di accesso rimane invariata. Un responsabile del progetto può comunque arrestare o eliminare queste sessioni: eliminarle è il modo per revocare l'accesso a una sessione che non ha harness sperimentaleù un proprietario. ## Condividere un'anteprima Puoi condividere l'anteprima live di una sessione tramite un link pubblico, in modalità di sola visualizzazione o interattiva. La creazione del link spetta al proprietario della sessione, per lo stesso motivo: il link non richiede autenticazione, quindi chiunque abbia l'URL può leggere la sessione senza accedere. Un responsabile del progetto può visualizzare e revocare i link di una sessione anche senza esserne proprietario: la revoca può solo rimuovere l'accesso. Per l'enumerazione completa degli stati, le variabili d'ambiente iniettate e gli endpoint del daemon, consulta [Runtime](/docs/it/work/runtime). Per scoprire come una sessione sceglie il proprio agente, consulta [Agenti](/docs/it/project/agents). Per le sessioni avviate da una pianificazione o da un webhook, consulta [Trigger](/docs/it/connect/triggers). Per integrare il lavoro delle sessioni nel branch predefinito, consulta [Richieste di modifica](/docs/it/work/change-requests).