Leer hoe je gevoelige context in Claude Code minimaliseert met praktische prompt-templates, workflows voor delen van bestanden en redactie-stappen die nog steeds bruikbare programmeerhulp opleveren.
"Context" is alles wat je een model geeft om mee te werken: codefragmenten, stacktraces, configbestanden, omgevingsvariabelen, databasevoorbeelden, schermafbeeldingen en zelfs eerdere berichten in dezelfde chat. Meer context kan debuggen versnellen, maar vergroot ook de kans dat je iets plakt dat je niet had willen delen.
Oversharing gebeurt meestal onder druk. Een bug blokkeert een release, authenticatie faalt vlak voor een demo, of een instabiele test faalt alleen in CI. In die momenten is het makkelijk om het hele bestand te plakken, dan de hele log, dan de volledige config "voor het geval dat." Teamgewoonten kunnen hetzelfde stimuleren: in code review en debugging is volledige zichtbaarheid normaal, ook als slechts een klein deel nodig is.
De risico's zijn niet hypothetisch. Eén plakactie kan geheimen, klantgegevens of interne systeemdetails lekken. Veelvoorkomende voorbeelden zijn:
Het doel is niet om geheimzinnig te zijn. Het doel is het delen van het kleinste stukje dat de fout reproduceert of de keuze verklaart, zodat je dezelfde kwaliteit hulp krijgt met minder blootstelling.
Een eenvoudig mentaal model: behandel de assistent als een behulpzame externe collega die je hele repo niet nodig heeft. Begin met één precieze vraag ("Waarom geeft dit verzoek 401 terug?"). Deel dan alleen wat die vraag ondersteunt: de mislukte input, verwacht resultaat, daadwerkelijk resultaat en het smalle codepad dat erbij betrokken is.
Als een login-call faalt, heb je meestal niet de hele auth-module nodig. Een gesanitiseerd request/response-paar, de functie die headers bouwt en de relevante configkeys (met vervangen waarden) is vaak genoeg.
Wanneer je om programmeerhulp vraagt, is "context" niet alleen broncode. Het is alles wat iemand kan helpen in te loggen, een persoon te identificeren of je systemen in kaart te brengen. Begin met te weten wat toxisch is om te plakken.
Credentials veranderen een behulpzaam fragment in een incident. Dit omvat API-sleutels en tokens, private keys, sessiecookies, signed URLs, OAuth client secrets, databasewachtwoorden en "tijdelijke" tokens die in logs verschijnen.
Een veelvoorkomende verrassing is indirecte lekken. Een foutmelding kan volledige request-headers bevatten met een Authorization bearer-token, of een debugdump van omgevingsvariabelen.
Elke data die aan een persoon gekoppeld is kan gevoelig zijn, ook als het op zichzelf onschuldig lijkt. Let op e-mails, namen, telefoonnummers, adressen, klant-ID's, medewerker-ID's, supporttickets met gesprekken en betaalgegevens.
Als je data nodig hebt om een bug te reproduceren, vervang echte records door realistische nepdata. Behoud de vorm (velden en types), niet de identiteit.
"Saaie" interne feiten zijn waardevol voor aanvallers en concurrenten: hostnamen, IP's, reponamen, ticket-ID's, vendornamen, contractvoorwaarden en interne service-URL's.
Zelfs een enkele stacktrace kan folderpaden met gebruikersnamen of klantnamen onthullen, service-namingsconventies en aanwijzingen voor cloudaccounts (bucket-namen, regio-strings).
Niet alle code is even gevoelig. De risicovolle stukken zijn diegene die beschrijven hoe je business werkt: prijs- en kortingsregels, fraudekontroles, aanbevelingslogica, prompt-templates voor LLM-functies en strategische documenten.
Als je hulp bij een bug nodig hebt, deel dan de kleinste functie die het reproduceren mogelijk maakt, niet het hele modulebestand.
Gevoelige details zitten vaak op plekken die je niet opmerkt: opmerkingen met namen, commit-berichten, TODO's die klanten noemen en stacktraces die letterlijk geplakt worden. Configbestanden zijn extra riskant omdat ze onschuldige instellingen met geheimen vermengen.
Een praktische regel: als de tekst iemand helpt je systeem sneller te begrijpen dan een clean-room voorbeeld zou doen, behandel het als gevoelig en redacteer of vervang het.
De beste tijd om blootstelling te verminderen is voordat je je editor opent. Een pauze van 30 seconden om het gewenste resultaat te definiëren verkleint vaak wat je deelt aanzienlijk.
Begin met het in één zin benoemen van het resultaat dat je wilt. Probeer je de oorzaak van een bug te vinden, wil je een veilige refactor, of tests ontwerpen? Elk doel heeft andere inputs nodig. Bughunts hebben meestal één stacktrace en een kleine functie nodig. Refactorvragen hebben vaak alleen publieke interfaces en een kort gebruiksvoorbeeld nodig.
Kies vervolgens één "minimaal artefact" dat het probleem bewijst. Pak het kleinste ding dat nog faalt: een enkele falende test, het kleinste fragment dat de fout triggert, een korte loguitreksel rondom de fout, of een vereenvoudigd configvoorbeeld met placeholders.
Wanneer je data beschrijft, geef liever vormen dan waarden. "User-object heeft id (UUID), email (string), role (enum), createdAt (timestamp)" is vrijwel altijd genoeg. Als je voorbeelden nodig hebt, gebruik nepwaarden die het formaat matchen, geen echte records.
Wees strikt met welke bestanden je deelt. Deel alleen de module die je verandert plus de interfaces die het aanraakt. Als een functie een andere module aanroept, heb je vaak alleen de handtekening en een korte beschrijving van wat die teruggeeft nodig. Als een bug een request naar een andere service betreft, heb je mogelijk alleen de request-vorm, een lijst met header-namen (geen waarden) en de verwachte response-vorm nodig.
Stel harde grenzen die nooit je machine verlaten: API-sleutels, private certificaten, access tokens, klantdata, interne URL's, volledige repository-dumps en ruwe productielogs. Als je een 401 debugt, deel de auth-flow en de foutmelding, maar vervang het token met TOKEN_REDACTED en het e-mailadres met [email protected].
Goede redactie verbergt niet alleen geheimen. Ze behoudt de structuur van het probleem zodat de assistent er nog steeds over kan redeneren. Verwijder je teveel, dan krijg je generieke adviezen. Verwijder je te weinig, dan loop je risico op datalekken.
Kies één placeholder-stijl en gebruik die consistent in code, config en logs. Consistentie maakt de stroom makkelijker te volgen.
Als hetzelfde token op drie plekken voorkomt, vervang het niet drie verschillende manieren. Gebruik placeholders zoals API_KEY_1, TOKEN_1, USER_ID_1, CUSTOMER_ID_1, EMAIL_1 en tel op indien nodig (TOKEN_2, TOKEN_3).
Een korte legenda helpt zonder echte waarden te onthullen:
TOKEN_1: bearer-token gebruikt in Authorization-headerCUSTOMER_ID_1: interne klantidentifier gebruikt in database-opzoekingAPI_KEY_1: sleutel gebruikt om de betalingsprovider aan te roepenSommige bugs hangen af van lengte en structuur (parsing, validatie, handtekeningen, regex). In die gevallen vervang unieke strings door dummywaarden die er hetzelfde uitzien.
Bijvoorbeeld:
Dit laat je zeggen "het token faalt op validatie" zonder het echte token te tonen.
Bij het delen van JSON: behoud keys en vervang waarden. Keys tonen wat het systeem verwacht; waarden zijn vaak het gevoelige deel.
In plaats van:
{"email":"[email protected]","password":"SuperSecret!","mfa_code":"123456","customer_id":"c8b1..."}
Deel:
{"email":"EMAIL_1","password":"PASSWORD_1","mfa_code":"MFA_CODE_1","customer_id":"CUSTOMER_ID_1"}
Hetzelfde idee voor SQL: behoud tabelnamen, joins en condities, maar verwijder literalen.
WHERE user_id = USER_ID_1 AND created_at > DATE_1Als een functie bedrijfsregels of eigendomscode bevat, beschrijf deze dan. Behoud wat van invloed is op de bug: inputs, outputs, bijwerkingen en error-handling.
Voorbeeldsamenvatting die nog steeds helpt:
"signRequest(payload) neemt een JSON-payload, voegt timestamp en nonce toe en maakt vervolgens een HMAC SHA-256-handtekening van method + path + body. Het retourneert {headers, body}. De fout treedt op wanneer de payload niet-ASCII tekens bevat."
Dat is meestal genoeg om encoding-, canonicalization- en handtekeningongelijkheden te diagnosticeren zonder de volledige implementatie te tonen.
Aan het einde van je prompt, vermeld wat je verwijderd hebt en wat je hebt gehouden. Dat voorkomt heen-en-weer en vermindert de kans dat je gevraagd wordt nog meer te plakken.
Voorbeeld:
"Redacted: tokens, e-mails, klantdata, volledige request bodies. Gehouden: endpoint-paden, statuscodes, header-namen, stacktrace-frames en de exacte fouttekst."
Behandel de assistent als een collega die alleen het deel hoeft te zien waar jij aan werkt. Deel interfaces en contracten in plaats van hele bestanden: functiehandtekeningen, types, request/response-vormen en de exacte fouttekst.
Een minimale repro in gewone taal is vaak genoeg: de input die je gebruikte, wat je verwachtte, wat er gebeurde en een paar omgevingsnotities (runtimeversie, OS, frameworkversie). Je hebt je volledige projectgeschiedenis niet nodig.
Templates die goed werken:
Een gesaniteerde config-block is een nuttig middenweg. Het toont welke knoppen er zijn zonder geheimen te tonen:
# sanitized
DB_HOST: "<set>"
DB_PORT: "5432"
DB_USER: "<set>"
DB_PASSWORD: "<redacted>"
JWT_SECRET: "<redacted>"
OAUTH_CLIENT_ID: "<set>"
OAUTH_CLIENT_SECRET: "<redacted>"
Voorbeeld van een veilige prompt:
"Login faalt met 401. Verwacht 200. Werkelijke response body: 'invalid token'. Omgeving: Node 20, lokale dev, tijdsynchronisatie ingeschakeld. Requestcontract: Authorization: Bearer <redacted>. Verificatiestappen: token wordt uitgegeven door /auth/login en gebruikt op /me. Wat zijn de belangrijkste oorzaken (clock skew, audience mismatch, signing secret mismatch), en welke ene check bevestigt elk?"
Een betrouwbare gewoonte is om delen te behandelen als het verpakken van een kleine reproductie. Deel genoeg om het probleem te diagnosticeren, en niets meer.
Een praktische aanpak is een tijdelijke "share folder" apart van je echte repo. Kopieer bestanden handmatig naar die map in plaats van je hele project te delen. Dat dwingt bewuste keuzes af.
Houd de workflow simpel:
Lees de map na het bouwen alsof je een buitenstaander bent. Als een bestand niet helpt het specifieke probleem te debuggen, hoort het er niet bij.
Wanneer je redigeert, voorkom dat de code of logs breken. Vervang waarden door duidelijke placeholders die types en structuur behouden. Bijvoorbeeld, vervang:
DATABASE_URL=postgres://user:[email protected]:5432/app
met:
DATABASE_URL=postgres://user:REDACTED@localhost:5432/app
Als de bug afhankelijk is van een derdepartijresponse, noteer dan de response-vorm in je README en voeg een synthetisch JSON-bestand toe dat erbij past. Je kunt zinvol debuggen zonder echte traffic te delen.
Gebruik een herhaalbare lus zodat je niet onder druk gaat improviseren.
Schrijf eerst twee zinnen.
Verzamel de minimale inputs. Breng alleen wat helpt reproduceren of redeneren over het probleem: een klein fragment rond de falende regel, de exacte fouttekst, relevante versies en 3 tot 5 repro-stappen.
Redigeer zonder de structuur te vlakken. Vervang geheimen met placeholders en behoud de vorm. Verwijder identifiers die het gedrag niet beïnvloeden (projectnamen, tenant-ID's, e-mails). Houd placeholders consistent.
API_KEY=sk_live_...
becomes
API_KEY=<API_KEY>
customer-1234-prod-db
becomes
<DB_HOST_PROD>
Stel gerichte vragen. Koppel “Wat is de meest waarschijnlijke oorzaak?” aan “Wat moet ik veranderen?” Als je een patch wilt, vraag om een wijziging beperkt tot het fragment dat je gaf, en eis dat aannames gelabeld worden.
Verifieer lokaal, voeg daarna één nieuw detail toe. Test het voorstel. Als het faalt, voeg slechts één nieuw stuk informatie toe (de volgende stacktraceregel, één configflag, een versmalde repro). Plak niet meteen een heel bestand.
Deze incrementele onthulling levert meestal een echt antwoord op terwijl geheimen en niet-gerelateerde code uit de prompt blijven.
Een veelvoorkomende situatie: login werkt op je laptop en staging, maar faalt in productie. Je hebt snel hulp nodig, maar je kunt geen echte tokens, klant-e-mails, interne hostnamen of je volledige auth-middleware plakken.
Begin met wat je kunt observeren: request- en response-vormen, statuscode en een korte stacktrace. Als het JWT-gerelateerd is, kun je ook niet-gevoelige headerdetails delen (zoals de verwachte algoritme) en timingdetails (zoals server time drift). Houd alles verder als placeholders.
Een veilig pakket bevat vaak:
Vraag dan een gerichte vraag. Productie-only auth-fouten komen vaak door clock skew, verkeerde issuer/audience, verschillende signing keys, ontbrekende key rotation of proxy/header-verschillen.
Promptpatroon:
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?
Nadat je hypotheses hebt gekregen, valideer veilig met wijzigingen die je kunt terugdraaien. Voeg tijdelijke logging toe die alleen niet-gevoelige feiten logt (exp, iat, now en de reden-code voor falen). Schrijf een kleine test die een veilig token-fixture voedt (of een lokaal gegenereerd token) en het validatiegedrag controleert voor randgevallen.
Een eenvoudig plan:
De snelste manier om privacyvoordelen te verliezen is het delen van "één klein ding" dat stiekem alles bevat. Het plakken van een volledige .env of configbestand is het klassieke voorbeeld. Zelfs als je duidelijke geheimen verwijdert, bevatten die bestanden vaak interne hostnamen, servicenames, featureflags en omgevingsclues die je systeem in kaart brengen.
Volledige stacktraces lekken ook vaak informatie. Ze kunnen gebruikersnamen, machinenamen, reponamen en absolute paden zoals /Users/alex/company-payments/... bevatten. Soms bevatten ze querystrings, HTTP-headers of error-objecten met tokens. Als je de trace nodig hebt, kopieer dan alleen de relevante frames en vervang paden door consistente placeholders.
Echte klantpayloads zijn risicovol, zelfs als ze "klein" zijn. Een enkele JSON-body kan e-mails, adressen, order-ID's of vrije-tekst notities bevatten. Een veiligere zet is het genereren van een nep-payload met dezelfde vorm en randgevallen (ontbrekende velden, lange strings, vreemde tekens) zonder echte waarden.
Inconsistente placeholders veroorzaken ook problemen. Als USER_ID op de ene plek "klant-id" betekent en op een andere plek "interne account-id", krijg je de verkeerde diagnose. Kies een schema en houd je eraan.
Als je bericht een vreemde zou helpen inloggen, je servers te lokaliseren of een klant te identificeren, geef het dan nog een ronde redactie.
Wanneer je voorzichtig wilt zijn, is snelheid je vijand. Een korte routine helpt je nuttige antwoorden te krijgen terwijl je gevoelige data uit de prompt houdt.
Doe één ronde voor geheimen en een tweede voor identifiers die je systeem nog steeds blootleggen:
Na het redigeren behoud je de vorm. Laat types, schema's, veldnamen, statuscodes en voorbeeldpayload-structuur intact, maar ruil echte waarden in voor placeholders.
Om consistent te blijven (vooral onder druk), schrijf je een kleine set redactie-regels op en hergebruik ze. Voor teams, maak er een gedeeld template van met twee blokken: "wat ik deel" (bestanden, functies, endpoints) en "wat ik niet deel" (geheimen, productiedata, interne domeinen).
Als je een extra veiligheidslaag wilt, doe je experimenten in een geïsoleerde omgeving en zorg je dat veranderingen omkeerbaar zijn. In Koder.ai (koder.ai) kan de planningsmodus je helpen de kleinst mogelijke wijziging uit te tekenen om een hypothese te testen, en snapshots plus rollback maken het makkelijker een fix te proberen zonder extra gevoelige context in je prompts te slepen.
Begin met het kleinste stukje dat je vraag kan beantwoorden: de falende input, verwacht versus daadwerkelijk resultaat, en het nauwe codepad dat erbij betrokken is.
Een goed standaardpakket is:
Plak niet:
.env/configbestanden of ruwe productielogsAls het een vreemde zou helpen in te loggen, een persoon te identificeren of je systeem in kaart te brengen, moet je het redigeren of samenvatten.
Gebruik consistente placeholders zodat de flow leesbaar blijft.
Voorbeeldschema:
TOKEN_1, TOKEN_2API_KEY_1USER_ID_1, Bewaar het formaat als de bug afhankelijk is van parsing of validatie.
Veelvoorkomende gevallen:
8-4-4-4-12 patroonZo blijft het gedrag realistisch zonder de echte waarde te tonen.
Deel keys en structuur, vervang waarden.
Voor JSON:
Voor SQL:
Voorbeeld:
Vat het samen in termen van inputs, outputs en de specifieke regel die van invloed is op de bug.
Een praktische samenvatting bevat:
Dat levert vaak dezelfde debugwaarde zonder je implementatie prijs te geven.
Een eenvoudig veilig promptformat ziet er zo uit:
Voeg ook een redactionote toe zoals:
“Redacted: tokens, e-mails, customer data, internal hostnames. Kept: endpoint paths, status codes, header names, exact error text.”
Omdat ze vaak alles in één keer bevatten:
Een veiliger alternatief is een config-template:
Gebruik incrementele onthulling:
Dat houdt de scope klein en voorkomt per ongeluk lekken onder druk.
Een praktisch pakket is:
Vraag dan:
CUSTOMER_ID_1EMAIL_1Voeg zonodig een korte legenda toe:
TOKEN_1: Bearer-token gebruikt op /meCUSTOMER_ID_1: identifier gebruikt in database-opzoekingWHERE user_id = USER_ID_1 AND created_at > DATE_1<set> of <redacted>