Claude Code Monitoring: attesa di autorizzazione di cattura e risultati mancanti

Il monitoraggio di Claude Code ha bisogno di tre strati, non di una dashboard. Utilizzare il feed ufficiale di OpenTelemetry di Claude Code per il consumo e l'attività, i ganci del ciclo di vita per le attese e i guasti del terminale e un controllo del progetto per il risultato effettivamente richiesto. Se ometti il terzo strato, una sessione può avere tracce pulite, chiamate di successo degli strumenti e una risposta finale lucidata mentre manca ancora il patch, il risultato del test o il file atteso. Il default ragionevole è deliberatamente piccolo: esportare metriche ed eventi modificati, registrare sei eventi del ciclo di vita senza i loro carichi utili di testo libero, quindi valutare l'ultimo evento in base a un predicato di completamento specifico per il compito. Non raccogliere le richieste o il contenuto grezzo degli strumenti solo per decidere se una corsa ha bisogno di attenzione. Questa guida costruisce tale progettazione a partire dagli attuali schemi di Claude Code e mette alla prova l'ordine decisionale in base a sette sessioni. Non presuppone che una chiamata agli strumenti significhi progresso, che una pausa significhi fallimento o che Stop significhi che il lavoro sia completato. Inizia con tre domande diverse Il monitoraggio diventa più chiaro quando ogni segnale risponde a una domanda e gli viene vietato rispondere alle altre due. Strato Domanda che può rispondere Segnali Cosa non può dimostrare Telemetria Cosa ha consumato o eseguito Claude Code? Sessioni, richieste di API, token, costo stimato, risultati degli strumenti, decisioni sugli strumenti, durata se il risultato richiesto è corretto Ciclo di vita Perche' questa sessione e' silenziosa o termina? richiesta di autorizzazione, notifica, compito di background, sveglio programmato, stop, turno terminato dell'API, fine della sessione se un file, un test o un risultato esterno sono validi Risultato Questo compito ebbe il risultato promesso? hash del file, stato di uscita del test, convalida dello schema, risposta API, artefatto firmato perché la sessione è stata attesa o quanto è costata Il Documentazione ufficiale di monitoraggio del codice Claude espone le metriche attraverso il protocollo di metriche OTel, gli eventi attraverso i registri/eventi e le tracce distribuite opzionali. Le metriche documentate includono il numero di sessioni, le linee cambiate, i commit, le richieste di pull, il tempo attivo, i token e il costo stimato. Gli eventi aggiungono correlazioni immediate, risultati API, risultati degli strumenti e decisioni di autorizzazione. Questa è un'eccellente prova per il primo strato. Non si tratta di un contratto di completamento. La distinzione è importante nel lavoro ordinario. Un evento di successo dello strumento Write dice che una scrittura è completata. Non dice che il file previsto sia stato scritto nella giusta posizione, che il programma risultante compila o che l'utente abbia richiesto quel file. Le curve dei token e dei costi possono rivelare un consumo irripetibile, ma una sessione a basso costo può comunque fermarsi un passo prima del consegnabile. Aggiungere le prove del ciclo di vita con ganci Claude Code Claude Codes annunci di riferimento fornisce un secondo strato che manca a un dashboard solo per uso. Sono particolarmente utili quattro eventi: PermissionRequest viene eseguito quando viene mostrato un dialogo di autorizzazione. Se si tratta dell'evento non risolto più recente, la sessione sta aspettando una persona; non è bloccata. Stop scatta quando l'agente principale finisce di rispondere. L'input corrente può includere background tasks e session crons , quindi una svolta fermata può ancora essere in attesa di un'attività di shell, subagente, attività di monitoraggio, flusso di lavoro, attività MCP o sveglio programmato. StopFailure si accende al posto di Stop quando un errore API termina il giro. Le sue classi di errori documentate includono il limite di velocità, il sovraccarico, l'autenticazione, la fatturazione, la richiesta invalida, il modello mancante, l'errore del server e i token di output massimi. SessionEnd registra il motivo per cui la sessione è terminata. È utile per la pulizia e l'audit, ma non può bloccare la cessazione. PostToolUse , PostToolUseFailure , Notification e PreCompact aggiungono un contesto utile. Tenere la loro semantica stretta: recente PostToolUse è prova di attività; ripetuto PostToolUseFailure è prova di problemi con gli strumenti; PreCompact segna una transizione di contesto che vale la pena correlare con il comportamento successivo. Nessuno è un verdetto sanitario universale. Per un collezionatore di privacy minimo, conservare solo un timestamp, un identificatore di sessione hashato localmente, il nome dell'evento, il nome dello strumento, la classe di errore, il tipo di notifica e il conteggio delle attività di background o dei risvegli pianificati. Se non è stato identificato un caso di utilizzo, omettere transcript path , cwd , last assistant message , comandi Bash, input di strumento e testo di notifica. I default ufficiali di OTel supportano la stessa restrizione. Il testo immediato, il testo di risposta assistente, gli argomenti degli strumenti, il contenuto di input/output degli strumenti e i corpi API grezzi sono disabilitati per impostazione predefinita. Abilitare OTEL LOG RAW API BODIES può esporre l'intera storia della conversazione; non dovrebbe mai essere un interruttore casuale per la risoluzione dei problemi. Trasforma le ultime prove in uno stato L'ordine di decisione qui sotto è abbastanza piccolo da poter essere ispezionato. Classifica l'ultimo evento per ogni sessione, mentre un verificatore esterno fornisce outcome verified quando un turno si ferma. L'ordine è intenzionale. Un fallimento dell'API terminale supera un recente evento di attività. Un'approvazione non risolta sta aspettando, non un tempo di pausa. Il lavoro di base impedisce che un evento Stop sia trattato come completato. Solo dopo che tali casi sono stati esclusi, il verificatore decide tra complete e outcome missing . Il dispositivo di prova conservato utilizza sette sessioni e una soglia di esempio di 15 minuti: L'esecuzione dell'apparecchio ad un timestamp fisso riproduce tutte e sette le linee: Questa e' una regola decisionale, non un demone di produzione. La soglia di 15 minuti e' sbagliata per un lavoro di due minuti e sbagliata per un lavoro di due ore. Indicare la freschezza rispetto alla cadenza e alla durata attese del lavoro, quindi mantenere un percorso uncertain per le prove mancanti o contraddittorie. Definire il termine al di fuori della conversazione L'unico input specifico per l'applicazione del classificatore è outcome verified . Questo bit dovrebbe provenire da un controllo deterministico quando possibile, non dalla ricerca del messaggio dell'assistente finale per done. Per un compito di modifica del codice, un compimento utile potrebbe richiedere tutte le seguenti caratteristiche: 1. i file attesi differiscono dal commit iniziale; 2. il comando di prova focalizzato esce con successo; 3. i decodici degli artefatti generati o il pacchetto possono essere importati; 4. il risultato rimane all'interno del repositorio e del campo di applicazione approvati. Per un compito di documentazione, richiede il file di destinazione, la connessione o la convalida dello schema, tutti i percorsi locali citati e qualsiasi verificatore di collegamento che il repository abbia già fiducia. Per l'esportazione dei dati, controllare il file atteso, analizzarlo, convalidare le colonne richieste e confrontare il numero di righe con il limite sorgente. Per una modifica dell'API, eseguire il test del contratto piuttosto che accettare una richiesta HTTP che è semplicemente ritornata. Il monitor deve memorizzare il nome del verificatore, lo stato di uscita, il tempo di osservazione e un digest del risultato, non una spiegazione inventata. Quando non esiste un predicato deterministico, registrare outcome unknown . Un risultato sconosciuto può richiedere un riesame; non deve diventare silenziosamente sano. Avviso sulla prossima azione sicura Sette stati non hanno bisogno di sette suoni di allarme. Invia ogni stato alla più piccola azione utile: Stato Azione predefinita working Non fare niente waiting human notificare alla persona responsabile la categoria di autorizzazione, senza approvarla waiting background mostrare la dipendenza e la sua freschezza; non riavviare la sessione failed: espone la classe di errore e la politica di riprova limitata outcome missing mostrare il preannuncio di completamento fallito e conservare il lavoro per l'ispezione stalled controllare di nuovo la raggiungibilità e la durata prevista prima di proporre una spinta limitata complete conservare le prove e chiudere la questione Questa rotta evita due errori costosi. Innanzitutto, evita di riprovare un agente che attende correttamente l'autorità. In secondo luogo, evita di celebrare una sospensione della conversazione quando le prove del progetto dicono che il risultato è assente. Il recupero automatico richiede limiti più stretti del monitoraggio. Un fallimento del limite di velocità può essere ripristinato dopo un backup; un fallimento di autenticazione di solito richiede una persona; un prompt di autorizzazione non deve essere auto approvato semplicemente perché è vecchio. Dopo qualsiasi intervento, eseguire di nuovo il predicato di completamento. Un comando di successo è la prova dell'attività, non la prova che il compito originale si è recuperato. Applicare il disegno senza sovraccarico Un lancio pratico può rimanere incrementale: 1. Abilitare la telemetria di Claude Code con metriche ed eventi, lasciando tutti gli interruttori di registrazione dei contenuti disattivati. 2. Confirmare che claude code.session.count o claude code.user prompt raggiungono il collezionista prima di costruire gli avvisi. 3. Aggiungere ganci locali per PermissionRequest , Stop , StopFailure , Notification , PreCompact e SessionEnd . 4. Normalizzare quei carichi utili di gancio nella busta minima; identificatori hash localmente e percorsi di drop e testo libero. 5. Definire un predicato di completamento deterministico per un compito conseguente. 6. Riproduci gli eventi sintetici per ogni stato prima di avvisare chiunque. 7. Aggiungere un allarme solo quando il suo proprietario e la prossima azione di sicurezza sono espliciti. La versione del normalizzatore. Claude Code documenta le versioni minime per diversi campi, e le trascrizioni interne non sono esplicitamente un contratto stabile. Preferire i campi di gancio e OTel che la documentazione corrente espone; non costruire un monitor a lunga durata scraping pixel terminali o assumendo una forma di trascrizione privata non cambierà mai. Il limite utile per Sidewisp Claude Code fornisce già forti segnali grezzi. Il divario operativo sta trasformando questi segnali in una decisione di salute contenuta: funzionare, aspettare, fallire, obsoletare o mancare il risultato promessopoi mostrando le prove e la mossa successiva più sicura. Sidewisp è attualmente in anteprima privata. Il suo sito pubblico e il sistema di articoli sono in onda, ma gli adattatori di monitoraggio Claude Code di produzione, la raccolta dell'agente sanità e il recupero non sono generalmente spediti. Il ruolo previsto è uno strato di salute accanto ai tempi di esecuzione esistenti, non un tempo di esecuzione sostitutivo, un gateway di modello obbligatorio o un fissatore autonomo. Se quel limite corrisponde al modo in cui si gestiscono gli agenti di codifica, la lista di attesa di anteprima privata è il passo successivo appropriato. Fino ad allora, il modello a tre strati di questa guida può essere utilizzato da solo: telemetria per l'attività, ganci per il ciclo di vita e controlli deterministici per i risultati.