Scopri come ridurre il contesto sensibile in Claude Code con template di prompt pratici, workflow per condividere file e passaggi di redazione che mantengono utile l'assistenza sul codice.
“Contesto” è tutto ciò che fornisci a un modello: frammenti di codice, stack trace, file di configurazione, variabili d'ambiente, campioni di database, screenshot e persino messaggi precedenti nella stessa chat. Più contesto può velocizzare il debug, ma aumenta anche le probabilità di incollare qualcosa che non volevi condividere.
L'oversharing di solito avviene sotto pressione. Un bug blocca una release, l'autenticazione si rompe prima di una demo, o un test intermittente fallisce solo in CI. In quel momento è facile incollare l'intero file, poi il log completo, poi tutta la configurazione “per sicurezza”. Le abitudini del team possono spingere nella stessa direzione: in code review e debugging la visibilità totale è normale, anche quando serve solo una piccola parte.
I rischi non sono teorici. Una singola incollata può perdere segreti, dati cliente o dettagli interni del sistema. Esempi comuni:
L'obiettivo non è essere segreti. È condividere la minima porzione che ancora riproduce il problema o spiega la decisione, così ottieni la stessa qualità di aiuto con meno esposizione.
Un modello mentale semplice: tratta l'assistente come un collega esterno che non ha bisogno dell'intero repo. Parti da una domanda precisa (“Perché questa richiesta restituisce 401?”). Poi condividi solo ciò che supporta quella domanda: l'input che fallisce, l'output atteso, l'output reale e il percorso di codice ristretto coinvolto.
Se una chiamata di login fallisce, di solito non serve l'intero modulo di auth. Una coppia richiesta/risposta sanificata, la funzione che costruisce gli header e le chiavi di config rilevanti (con i valori sostituiti) sono spesso sufficienti.
Quando chiedi aiuto sul codice, “contesto” non è solo codice sorgente. È qualsiasi cosa che potrebbe aiutare qualcuno a fare il login, identificare una persona o mappare i tuoi sistemi. Inizia sapendo cosa è tossico da incollare.
Le credenziali trasformano uno snippet utile in un incidente. Questo include API key e token, chiavi private, cookie di sessione, URL firmati, segreti client OAuth, password di database e token “temporanei” stampati nei log.
Una sorpresa comune sono le perdite indirette. Un messaggio di errore potrebbe includere header di richiesta completi con un bearer token Authorization, o un dump di debug delle variabili d'ambiente.
Qualsiasi dato legato a una persona può essere sensibile, anche se sembra innocuo da solo. Fai attenzione a email, nomi, numeri di telefono, indirizzi, ID cliente, ID dipendente, ticket di supporto con conversazioni e dettagli di pagamento.
Se ti servono dati per riprodurre un bug, sostituisci i record reali con dati falsi realistici. Mantieni la forma (campi e tipi), non l'identità.
Fatti “noiosi” interni sono preziosi per attaccanti e concorrenti: hostnames, IP, nomi repo, ID ticket, nomi fornitori, clausole contrattuali e URL di servizio interni.
Anche un singolo stack trace può rivelare percorsi di cartelle con nomi utente o clienti, convenzioni di naming dei servizi e indizi sugli account cloud (nomi bucket, stringhe di regione).
Non tutto il codice è ugualmente sensibile. Le parti più rischiose sono quelle che codificano come funziona il tuo business: regole di prezzo e sconto, controlli antifrode, logica di raccomandazione, template di prompt per funzionalità LLM e documenti strategici.
Se hai bisogno di aiuto per un bug, condividi la funzione più piccola che lo riproduce, non il modulo intero.
Dettagli sensibili spesso viaggiano in posti che non noti: commenti con nomi, messaggi di commit, TODO che citano clienti, e stack trace incollati “così come sono”. I file di config sono particolarmente rischiosi perché mescolano impostazioni innocue con segreti.
Una regola pratica: se il testo aiuterebbe qualcuno a capire più velocemente il tuo sistema rispetto a un esempio clean-room, trattalo come sensibile e redigi o sostituisci.
Il momento migliore per ridurre l'esposizione è prima di aprire l'editor. Una pausa di 30 secondi per definire l'esito spesso taglia ciò che condividi della maggior parte.
Inizia nominando il risultato che vuoi in una frase. Stai cercando la causa di un bug, un piano di refactor sicuro o progettare test? Ogni obiettivo richiede input diversi. Le cacce al bug di solito hanno bisogno di uno stack trace e di una piccola funzione. Le domande di refactor spesso richiedono solo interfacce pubbliche e un breve esempio d'uso.
Poi scegli un “artefatto minimo” che dimostra il problema. Prendi la cosa più piccola che ancora fallisce: un singolo test che fallisce, lo snippet minimo che scatena l'errore, un breve estratto di log intorno al fallimento o un campione di config semplificato con segnaposti.
Quando descrivi i dati, preferisci le forme ai valori. “L'oggetto User ha id (UUID), email (string), role (enum), createdAt (timestamp)” è quasi sempre sufficiente. Se servono esempi, usa esempi finti che corrispondono al formato, non record reali.
Sii rigoroso sui file. Condividi solo il modulo che stai cambiando più le interfacce che tocca. Se una funzione richiama un altro modulo, spesso serve solo la firma e una breve descrizione di cosa restituisce. Se un bug coinvolge una richiesta a un altro servizio, potrebbe bastare la forma della request, l'elenco dei nomi degli header (non i valori) e la forma della risposta attesa.
Imposta confini fermi che non lasciano mai la tua macchina: API key, certificati privati, token di accesso, dati cliente, URL interni, dump di repository completi e log di produzione grezzi. Se stai debugando un 401, condividi il flusso di auth e il messaggio d'errore, ma sostituisci il token con TOKEN_REDACTED e l'email con [email protected].
Una buona redazione non è solo nascondere i segreti. Mantiene intatta la struttura del problema così l'assistente può ancora ragionare. Rimuovi troppo e ottieni consigli generici. Rimuovi troppo poco e rischi la perdita di dati.
Scegli uno stile di segnaposto e usalo su codice, config e log. La coerenza rende più facile seguire il flusso.
Se lo stesso token appare in tre posti, non sostituirlo in tre modi diversi. Usa segnaposto come API_KEY_1, TOKEN_1, USER_ID_1, CUSTOMER_ID_1, EMAIL_1 e incrementa quando serve (TOKEN_2, TOKEN_3).
Una breve legenda aiuta senza rivelare valori reali:
TOKEN_1: bearer token usato nell'header AuthorizationCUSTOMER_ID_1: identificatore cliente interno usato per lookup nel DBAPI_KEY_1: chiave usata per chiamare il provider di pagamentoAlcuni bug dipendono da lunghezza e struttura (parsing, validazione, firma, regex). In quei casi, sostituisci stringhe uniche con valori finti che hanno lo stesso aspetto.
Per esempio:
Questo ti permette di dire “il token fallisce la validazione” senza esporre il token reale.
Quando condividi JSON, mantieni le chiavi e sostituisci i valori. Le chiavi mostrano cosa il sistema si aspetta; i valori sono spesso la parte sensibile.
Invece di:
{"email":"[email protected]","password":"SuperSecret!","mfa_code":"123456","customer_id":"c8b1..."}
Condividi:
{"email":"EMAIL_1","password":"PASSWORD_1","mfa_code":"MFA_CODE_1","customer_id":"CUSTOMER_ID_1"}
Stessa idea per SQL: mantieni nomi di tabelle, join e condizioni, ma rimuovi i letterali.
WHERE user_id = USER_ID_1 AND created_at > DATE_1Se una funzione contiene regole di business o logica proprietaria, descrivila. Mantieni ciò che influisce sul bug: input, output, effetti collaterali e gestione degli errori.
Esempio di riassunto che aiuta ancora:
“signRequest(payload) prende un payload JSON, aggiunge timestamp e nonce, poi crea una firma HMAC SHA-256 da method + path + body. Restituisce {headers, body}. L'errore avviene quando il payload include caratteri non-ASCII.”
Questo di solito è sufficiente per diagnosticare mismatch di codifica, canonicalizzazione o firma senza esporre l'implementazione completa.
Alla fine del tuo prompt, indica cosa hai rimosso e cosa hai mantenuto. Previene scambi di messaggi inutili e riduce la probabilità che ti venga chiesto di incollare altro.
Esempio:
“Redacted: tokens, emails, customer data, full request bodies. Kept: endpoint paths, status codes, header names, stack trace frames, and the exact error text.”
Tratta l'assistente come un collega che ha bisogno solo della parte su cui stai lavorando. Condividi interfacce e contratti invece di file interi: firme di funzione, tipi, forme request/response e il testo esatto dell'errore.
Un repro minimo in linguaggio semplice è spesso sufficiente: l'input che hai usato, cosa ti aspettavi, cosa è successo invece e qualche nota sull'ambiente (versione runtime, OS, versione framework). Non ti serve tutta la storia del progetto.
Template che funzionano bene:
Un blocco di config sanitizzato è un buon compromesso. Mostra quali manopole esistono senza esporre segreti:
# sanitized
DB_HOST: "<set>"
DB_PORT: "5432"
DB_USER: "<set>"
DB_PASSWORD: "<redacted>"
JWT_SECRET: "<redacted>"
OAUTH_CLIENT_ID: "<set>"
OAUTH_CLIENT_SECRET: "<redacted>"
Esempio di prompt sicuro:
“Login fallisce con 401. Atteso 200. Corpo di risposta effettivo: ‘invalid token’. Ambiente: Node 20, dev locale, time sync abilitato. Contratto della request: Authorization: Bearer redacted. Passi di verifica: il token è emesso da /auth/login e usato su /me. Quali sono le cause principali (clock skew, audience mismatch, signing secret mismatch), e quale singolo controllo conferma ciascuna?”
Un'abitudine affidabile è trattare la condivisione come il confezionamento di una piccola riproduzione. Condividi abbastanza per diagnosticare il problema e nient'altro.
Un approccio pratico è avere una “cartella di condivisione” temporanea separata dal tuo repo reale. Copia i file dentro manualmente invece di condividere l'intero progetto. Questo forza scelte intenzionali.
Mantieni il workflow semplice:
Dopo aver preparato la cartella, leggila come un estraneo. Se un file non aiuta a debuggare il problema specifico, non deve esserci.
Quando redigi, evita di rompere il codice o i log. Sostituisci valori con segnaposto evidenti che mantengono tipo e struttura. Per esempio, sostituisci:
DATABASE_URL=postgres://user:[email protected]:5432/app
con:
DATABASE_URL=postgres://user:REDACTED@localhost:5432/app
Se il bug dipende da una risposta di terze parti, scrivi la forma della risposta nel README e includi un file JSON sintetico che la rispecchi. Puoi ottenere un debug significativo senza condividere traffico reale.
Usa un loop ripetibile così non improvvisi sotto pressione.
Scrivi due frasi prima.
Raccogli gli input minimi. Porta solo ciò che aiuta a riprodurre o ragionare sul problema: uno snippet piccolo attorno alla riga che fallisce, il testo esatto dell'errore, versioni rilevanti e 3–5 passi di repro.
Redigi senza appiattire la struttura. Sostituisci segreti con segnaposto e mantieni la forma intatta. Rimuovi identificatori che non influenzano il comportamento (nomi del progetto, tenant ID, email). Mantieni i segnaposto coerenti.
API_KEY=sk_live_...
becomes
API_KEY=<API_KEY>
customer-1234-prod-db
becomes
<DB_HOST_PROD>
Fai domande mirate. Abbina “Qual è la causa più probabile?” con “Cosa dovrei cambiare?”. Se vuoi una patch, chiedi una modifica limitata allo snippet fornito e richiedi che le assunzioni siano etichettate.
Verifica localmente, poi aggiungi un solo nuovo dettaglio. Testa il suggerimento. Se fallisce, aggiungi solo una nuova informazione (la riga successiva dello stack trace, una flag di config, un repro ristretto). Non passare direttamente a incollare un file intero.
Questa divulgazione incrementale di solito ti dà una risposta reale mantenendo segreti e codice non rilevante fuori dal prompt.
Situazione comune: il login funziona sul tuo laptop e in staging, ma fallisce in produzione. Ti serve aiuto veloce, ma non puoi incollare token reali, email utente, hostnames interni o il middleware auth completo.
Inizia con ciò che puoi osservare: forma della request/response, codice di stato e un breve stack trace. Se è un problema JWT, puoi condividere anche dettagli non sensibili dell'header (come l'algoritmo atteso) e dettagli temporali (drift dell'orologio). Mantieni tutto il resto con segnaposti.
Un pacchetto sicuro spesso include:
Poi poni una domanda mirata. I fallimenti auth che avvengono solo in produzione spesso derivano da drift di orologio, issuer/audience sbagliati, chiavi di firma diverse, rotazione chiavi mancante o differenze di proxy/header.
Schema di prompt:
I have a production-only login/auth failure. Locally it passes.
Observed behavior:
- Endpoint: POST /api/login
- Production response: 401 with message "invalid token" (generic)
- Staging/local: 200
Sanitized request/response:
- Authorization: Bearer <JWT_REDACTED>
- Expected claims: iss=<ISSUER_PLACEHOLDER>, aud=<AUDIENCE_PLACEHOLDER>
- Token validation library: <LIB_NAME_AND_VERSION>
Sanitized log snippet:
<PASTE 5-10 LINES WITH TOKENS/EMAILS/HOSTS REDACTED>
Question:
Given this, what are the top causes of JWT validation failing only in production, especially clock skew or claim mismatch? What specific checks and log lines should I add to confirm which one it is?
Dopo aver ottenuto ipotesi, convalida in modo sicuro con modifiche reversibili. Aggiungi logging temporaneo che stampi solo fatti non sensibili (exp, iat, now e il codice di errore). Scrivi un piccolo test che invia un token fixture sicuro e verifica il comportamento del validatore per casi limite.
Un piano semplice:
Il modo più rapido per perdere i benefici della privacy è condividere “una piccola cosa” che in realtà contiene tutto. Incollare un .env completo è l'esempio classico. Anche se cancelli i segreti ovvi, quei file spesso includono host interni, nomi di servizio, feature flag e indizi sull'ambiente.
I stack trace completi sono un'altra perdita frequente. Possono contenere nomi utente, nomi macchina, percorsi assoluti e talvolta query string, header HTTP o oggetti errore con token. Se ti serve il trace, copia solo i frame rilevanti e sostituisci i percorsi con segnaposto coerenti.
I payload reali dei clienti sono rischiosi anche se “piccoli”. Genera payload finti con la stessa forma e casi limite senza valori reali.
I segnaposto incoerenti creano problemi. Se USER_ID significa “customer id” in un punto e “internal account id” in un altro, otterrai diagnosi sbagliate. Scegli uno schema e usalo sempre.
Se il tuo messaggio aiuterebbe uno sconosciuto a fare il login, localizzare i tuoi server o identificare un cliente, rifai un passaggio di redazione.
Quando cerchi di essere cauto, la velocità è il tuo nemico. Una breve routine ti aiuta a ottenere risposte utili mantenendo i dati sensibili fuori dal prompt.
Fai un passaggio per i segreti, poi un secondo per gli identificatori che ancora espongono il sistema:
Dopo la redazione, mantieni la forma. Lascia tipi, schemi, nomi dei campi, codici di stato e esempio di struttura dei payload, ma sostituisci i valori reali con segnaposto.
Per mantenere coerenza (soprattutto sotto pressione), annota un piccolo set di regole di redazione e riusale. Per i team, trasformalo in un template condiviso con due blocchi: “cosa sto condividendo” (file, funzioni, endpoint) e “cosa non sto condividendo” (segreti, dati di produzione, domini interni).
Se vuoi un livello di sicurezza in più, fai esperimenti in un ambiente isolato e assicurati che le modifiche siano reversibili. In Koder.ai (koder.ai), la modalità di pianificazione può aiutare a delineare la minima modifica necessaria per testare un'ipotesi, e snapshot + rollback rendono più semplice provare una correzione senza trascinare altro contesto sensibile nei tuoi prompt.
Inizia con la porzione più piccola che può rispondere alla tua domanda: l'input che fallisce, output previsto vs effettivo, e il percorso di codice ristretto coinvolto.
Un pacchetto di default utile è:
Non incollare:
.env completi / dump di configurazione o log di produzione grezziSe aiuterebbe uno sconosciuto ad accedere, identificare una persona o mappare i tuoi sistemi, redigi o riassumi.
Usa segnaposto coerenti in modo che il flusso resti leggibile.
Esempio di schema:
TOKEN_1, TOKEN_2API_KEY_1USER_ID_1, Conserva il formato quando il bug dipende dal parsing o dalla validazione.
Casi comuni:
8-4-4-4-12Questo mantiene il comportamento realistico senza esporre il valore reale.
Condividi chiavi e struttura, sostituisci i valori.
Per JSON:
Per SQL:
Esempio:
Riassumila in termini di input, output e della regola specifica che influisce sul bug.
Un riassunto pratico include:
Spesso ottieni lo stesso valore di debug senza rivelare l'implementazione.
Un prompt sicuro semplice comprende:
Includi anche una nota di redazione come:
"Redacted: tokens, emails, customer data, internal hostnames. Kept: endpoint paths, status codes, header names, exact error text."
Perché spesso contengono tutto insieme:
Un'alternativa più sicura è un template di configurazione:
Usa divulgazione incrementale:
Questo mantiene l'ambito piccolo e previene perdite accidentali sotto pressione.
Un pacchetto pratico è:
Poi chiedi:
Inizia con la più piccola parte che riproduce il problema: un singolo test che fallisce, lo snippet minimo che genera l'errore, un estratto di log breve o un campione di config semplificato con segnaposto.
Crea una cartella di condivisione temporanea separata dal repo reale e copia manualmente dentro solo ciò che serve.
Prima di condividere, rileggi la cartella come uno che non ti conosce: se un file non aiuta a risolvere il problema specifico, non deve esserci.
Ecco una semplice routine da ripetere in modo da non improvvisare sotto pressione.
API_KEY=sk_live_...
becomes
API_KEY=<API_KEY>
customer-1234-prod-db
becomes
<DB_HOST_PROD>
Non incollare tutta la roba “solo nel caso”. I soliti errori includono file .env completi e log di produzione integrali. Anche se elimini i segreti evidenti, quei file spesso contengono host interni, nomi di servizio e flag che mappano il tuo sistema.
I trace di stack completi possono includere nomi utenti, nomi macchina, percorsi assoluti come /Users/alex/company-payments/... e a volte header o token. Se hai bisogno del trace, copia solo i frame rilevanti e sostituisci i percorsi con segnaposto coerenti.
I payload reali dei clienti sono rischiosi anche se “piccoli”. Genera payload finti con la stessa forma e casi limite (campi mancanti, stringhe lunghe, caratteri strani) senza valori reali.
Infine, mantieni i segnaposto coerenti: non usare per significati diversi in punti diversi.
CUSTOMER_ID_1EMAIL_1Aggiungi una breve legenda se serve:
TOKEN_1: bearer token usato su /meCUSTOMER_ID_1: identificatore usato per lookup nel DBWHERE user_id = USER_ID_1 AND created_at > DATE_1\u003cset\u003e o \u003credacted\u003eQuesta divulgazione incrementale normalmente ti dà una risposta concreta mantenendo segreti e codice non rilevante fuori dal prompt.
USER_IDSe il tuo messaggio aiuterebbe uno sconosciuto ad accedere, localizzare i tuoi server o identificare un cliente, rifai un passaggio di redazione.