Lerne, wie du in Claude Code sensible Kontexte minimierst: praktische Prompt-Vorlagen, sichere Datei-Workflows und Redaktionsschritte, die trotzdem nützliche Coding-Hilfe liefern.
„Kontext“ umfasst alles, was du einem Modell zur Verfügung stellst: Codeausschnitte, Stacktraces, Konfigurationsdateien, Umgebungsvariablen, Datenbankbeispiele, Screenshots und sogar frühere Nachrichten im selben Chat. Mehr Kontext kann das Debuggen beschleunigen, erhöht aber auch die Wahrscheinlichkeit, aus Versehen etwas zu teilen, das du nicht preisgeben wolltest.
Übermäßiges Teilen passiert oft unter Druck. Ein Bug blockiert ein Release, die Auth bricht kurz vor einer Demo, oder ein instabiler Test schlägt nur in CI fehl. In solchen Momenten ist es einfach, die ganze Datei, dann das ganze Log, dann die komplette Konfiguration zu kopieren „nur für den Fall“. Teamgewohnheiten verstärken das: Bei Code-Reviews und beim Debuggen ist volle Sichtbarkeit normal, auch wenn nur ein kleiner Ausschnitt nötig wäre.
Die Risiken sind real. Ein einziger Paste kann Geheimnisse, Kundendaten oder interne Systemdetails leaken. Häufige Beispiele sind:
Das Ziel ist nicht, alles geheim zu halten. Es geht darum, den kleinsten Ausschnitt zu teilen, der das Problem reproduziert oder die Entscheidung erklärt, sodass du dieselbe Hilfequalität bei geringerem Exposure bekommst.
Ein einfaches mentales Modell: Behandle den Assistenten wie einen hilfreichen externen Kollegen, der nicht dein gesamtes Repo braucht. Beginne mit einer präzisen Frage („Warum liefert diese Anfrage 401?“). Teile dann nur, was diese Frage unterstützt: die fehlschlagende Eingabe, erwartetes Ergebnis, tatsächliches Ergebnis und den engen Codepfad.
Wenn ein Login-Aufruf fehlschlägt, brauchst du normalerweise nicht das ganze Auth-Modul. Ein bereinigtes Request/Response-Paar, die Funktion, die Header baut, und die relevanten Config-Keys (mit ersetzten Werten) reichen oft aus.
„Kontext“ ist nicht nur Quellcode. Es ist alles, was jemanden einloggen, eine Person identifizieren oder deine Systeme kartieren helfen könnte. Fang damit an zu wissen, was toxisch zum Einfügen ist.
Zugangsdaten verwandeln einen hilfreichen Ausschnitt in einen Vorfall. Dazu zählen API-Keys und Tokens, private Keys, Session-Cookies, signierte URLs, OAuth-Client-Secrets, Datenbankpasswörter und „temporäre“ Tokens, die in Logs auftauchen.
Eine häufige Überraschung sind indirekte Leaks. Eine Fehlermeldung kann vollständige Request-Header mit einem Authorization-Bearer-Token enthalten oder einen Debug-Dump von Umgebungsvariablen.
Alle personenbezogenen Daten können sensibel sein, selbst wenn sie allein harmlos aussehen. Achte auf E-Mails, Namen, Telefonnummern, Adressen, Kunden-IDs, Mitarbeiter-IDs, Support-Tickets mit Gesprächen und Zahlungsdetails.
Wenn du Daten zur Reproduktion eines Bugs brauchst, tausche echte Datensätze gegen realistische Fake-Daten aus. Erhalte die Form (Felder und Typen), nicht die Identität.
„Langweilige“ interne Fakten sind für Angreifer und Konkurrenten wertvoll: Hostnamen, IPs, Repo-Namen, Ticket-IDs, Vendor-Namen, Vertragsbedingungen und interne Service-URLs.
Schon ein einziger Stacktrace kann Ordnerpfade mit Benutzernamen oder Kundennamen, Service-Namenskonventionen und Cloud-Konto-Hinweise (Bucket-Namen, Regionen) offenbaren.
Nicht jeder Code ist gleich sensibel. Die riskantesten Teile sind solche, die zeigen, wie dein Geschäft funktioniert: Preis- und Rabattregeln, Betrugserkennung, Empfehlungslogik, Prompt-Templates für LLM-Funktionen und strategische Dokumente.
Wenn du Hilfe für einen Bug brauchst, teile die kleinste Funktion, die ihn reproduziert, nicht das ganze Modul.
Sensible Details verstecken sich oft an Stellen, die du nicht beachtest: Kommentare mit Namen, Commit-Messages, TODOs mit Kundenerwähnungen und Stacktraces, die „wie sie sind“ eingefügt werden. Konfigurationsdateien sind besonders riskant, weil sie harmlose Einstellungen mit Geheimnissen mischen.
Eine praktische Regel: Wenn der Text einem Außenstehenden hilft, dein System schneller zu verstehen als ein Clean-Room-Beispiel, behandle ihn als sensibel und redigiere oder ersetze ihn.
Der beste Zeitpunkt, die Exposition zu reduzieren, ist bevor du deinen Editor öffnest. Eine 30-Sekunden-Pause, um das gewünschte Ergebnis zu benennen, reduziert oft bereits den Großteil dessen, was du teilst.
Beginne damit, das Ergebnis in einem Satz zu benennen. Willst du die Ursache eines Fehlers finden, einen sicheren Refactor-Plan bekommen oder Tests entwerfen? Jedes Ziel braucht andere Eingaben. Bug-Suchen brauchen meist einen Stacktrace und eine kleine Funktion. Refactor-Fragen benötigen oft nur öffentliche Schnittstellen und ein kurzes Nutzungsbeispiel.
Wähle dann ein „minimales Artefakt“, das das Problem beweist. Wähle das kleinstmögliche, das fehlschlägt: ein einzelner fehlschlagender Test, der kleinste Snippet, das den Fehler auslöst, ein kurzer Logauszug um die Fehlstelle oder ein vereinfachtetes Config-Beispiel mit Platzhaltern.
Wenn du Daten beschreibst, bevorzuge Formate statt Werte. „User-Objekt hat id (UUID), email (string), role (enum), createdAt (timestamp)“ reicht fast immer. Wenn Beispiele nötig sind, benutze Fake-Daten, die das Format treffen, nicht echte Datensätze.
Sei streng bei Dateien. Teile nur das Modul, das du änderst, plus die Schnittstellen, die es berührt. Ruft eine Funktion ein anderes Modul auf, brauchst du oft nur die Signatur und eine kurze Beschreibung dessen, was zurückkommt. Betrifft ein Bug eine Anfrage an einen anderen Service, reicht oft die Request-Shape, eine Liste von Header-Namen (nicht deren Werte) und die erwartete Response-Shape.
Setze harte Grenzen, die niemals deine Maschine verlassen: API-Keys, private Zertifikate, Access-Tokens, Kundendaten, interne URLs, komplette Repo-Dumps und rohe Produktions-Logs. Wenn du einen 401 debugst, teile den Auth-Flow und die Fehlermeldung, aber ersetze das Token durch TOKEN_REDACTED und die E-Mail durch [email protected].
Gute Redaktion versteckt Geheimnisse, erhält aber die Struktur des Problems, damit der Assistent weiterhin sinnvoll mitdenken kann. Zu viel entfernen führt zu allgemeinen Empfehlungen; zu wenig entfernt erhöht das Risiko eines Leaks.
Wähle einen Platzhalterstil und bleibe dabei über Code, Config und Logs hinweg. Konsistenz erleichtert das Nachvollziehen.
Wenn derselbe Token an drei Stellen auftaucht, ersetze ihn nicht dreimal unterschiedlich. Nutze Platzhalter wie API_KEY_1, TOKEN_1, USER_ID_1, CUSTOMER_ID_1, EMAIL_1 und erhöhe bei Bedarf (TOKEN_2, TOKEN_3).
Eine kurze Legende hilft ohne echte Werte preiszugeben:
TOKEN_1: Bearer-Token im Authorization-HeaderCUSTOMER_ID_1: interne Kunden-ID, verwendet bei DB-LookupsAPI_KEY_1: Schlüssel für den ZahlungsanbieterManche Bugs hängen von Länge und Struktur ab (Parsing, Validierung, Signaturen, Regex). In diesen Fällen ersetze einzigartige Strings durch Dummy-Werte mit gleicher Optik.
Zum Beispiel:
So kannst du sagen „das Token schlägt bei der Validierung fehl“, ohne das echte Token preiszugeben.
Beim Teilen von JSON behalte Schlüssel und ersetze Werte. Schlüssel zeigen, was das System erwartet; Werte sind oft sensibel.
Statt:
{"email":"[email protected]","password":"SuperSecret!","mfa_code":"123456","customer_id":"c8b1..."}
Teile:
{"email":"EMAIL_1","password":"PASSWORD_1","mfa_code":"MFA_CODE_1","customer_id":"CUSTOMER_ID_1"}
Dasselbe gilt für SQL: Behalte Tabellennamen, Joins und Bedingungen, entferne Literalwerte.
WHERE user_id = USER_ID_1 AND created_at > DATE_1Wenn eine Funktion Geschäftsregeln oder proprietäre Logik enthält, beschreibe sie. Behalte, was den Bug beeinflusst: Eingaben, Ausgaben, Seiteneffekte und Error-Handling.
Beispielzusammenfassung, die noch hilft:
“signRequest(payload) nimmt ein JSON-Payload, fügt timestamp und nonce hinzu und erzeugt anschließend eine HMAC-SHA-256-Signatur aus method + path + body. Es gibt {headers, body} zurück. Der Fehler tritt auf, wenn das Payload nicht-ASCII-Zeichen enthält.”
Das reicht meist, um Encoding-, Canonicalization- und Signaturprobleme zu diagnostizieren, ohne die komplette Implementierung zu offenbaren.
Am Ende deiner Anfrage schreibe, was du entfernt und was du behalten hast. Das verhindert Rückfragen und reduziert die Chance, dass man dich um mehr Daten bittet.
Beispiel:
“Redacted: tokens, emails, customer data, full request bodies. Kept: endpoint paths, status codes, header names, stack trace frames, and the exact error text.”
Behandle den Assistenten wie einen Kollegen, der nur den Teil braucht, an dem du gerade arbeitest. Teile Schnittstellen und Verträge statt ganzer Dateien: Funktionssignaturen, Typen, Request/Response-Formate und den genauen Fehlertext.
Eine minimale Reproduktion in Klartext reicht oft: die Eingabe, die du verwendet hast, was du erwartest, was stattdessen passiert ist, und ein paar Umgebungsangaben (Runtime-Version, OS, Framework-Version). Du brauchst nicht die komplette Projektgeschichte.
Vorlagen, die meist gut funktionieren:
Ein sanitisiertes Config-Block ist ein guter Mittelweg: Er zeigt, welche Knöpfe existieren, ohne Geheimnisse preiszugeben:
# sanitized
DB_HOST: "<set>"
DB_PORT: "5432"
DB_USER: "<set>"
DB_PASSWORD: "<redacted>"
JWT_SECRET: "<redacted>"
OAUTH_CLIENT_ID: "<set>"
OAUTH_CLIENT_SECRET: "<redacted>"
Beispiel für eine sichere Anfrage:
“Login schlägt mit 401 fehl. Erwartet 200. Tatsächlicher Response-Body: ‘invalid token’. Umgebung: Node 20, lokal, Zeitsynchronisation aktiviert. Request-Contract: Authorization: Bearer <redacted>. Verify-Steps: Token wird von /auth/login ausgegeben und auf /me verwendet. Was sind die Top-Ursachen (Clock Skew, Audience-Mismatch, Signing-Secret-Mismatch) und welche einzelne Prüfung bestätigt jede davon?”
Eine verlässliche Gewohnheit ist, Teilen wie das Verpacken einer winzigen Reproduktion zu behandeln. Teile genug, um das Problem zu diagnostizieren, und nichts mehr.
Ein praktischer Ansatz ist ein temporärer „Share-Ordner“, getrennt vom echten Repo. Kopiere Dateien manuell hinein anstatt dein ganzes Projekt zu teilen. Das zwingt zu bewussten Entscheidungen.
Halte den Workflow einfach:
Nachdem du den Ordner gebaut hast, lese ihn wie ein Außenstehender. Wenn eine Datei beim Debuggen nicht hilft, gehört sie nicht dazu.
Wenn du redigierst, vermeide es, Code oder Logs zu zerstören. Ersetze Werte durch offensichtliche Platzhalter, die Typ und Struktur erhalten. Beispiel:
DATABASE_URL=postgres://user:[email protected]:5432/app
wird zu:
DATABASE_URL=postgres://user:REDACTED@localhost:5432/app
Wenn der Bug von einer Drittanbieterantwort abhängt, schreibe die Response-Shape in deine README und füge eine synthetische JSON-Datei bei, die dazu passt. Damit lässt sich sinnvolles Debugging betreiben, ohne echten Traffic zu teilen.
Nutze eine wiederholbare Schleife, damit du unter Druck nicht improvisierst.
Schreibe zuerst zwei Sätze.
Sammle die minimalen Eingaben. Bringe nur, was hilft, das Problem zu reproduzieren oder nachzuvollziehen: ein kleiner Ausschnitt um die fehlschlagende Zeile, der genaue Fehlertext, relevante Versionen und 3–5 Repro-Schritte.
Redigiere ohne die Struktur zu zerstören. Ersetze Geheimnisse mit Platzhaltern und erhalte die Form. Entferne Identifikatoren, die das Verhalten nicht beeinflussen (Projekt-Namen, Tenant-IDs, E-Mails). Halte Platzhalter konsistent.
API_KEY=sk_live_...
becomes
API_KEY=<API_KEY>
customer-1234-prod-db
becomes
<DB_HOST_PROD>
Stelle gezielte Fragen. Kombiniere „Was ist die wahrscheinlichste Ursache?“ mit „Was soll ich ändern?“ Wenn du einen Patch willst, fordere eine Änderung, die nur den von dir bereitgestellten Ausschnitt betrifft, und verlange, dass Annahmen gekennzeichnet werden.
Verifiziere lokal, dann füge genau ein neues Detail hinzu. Teste den Vorschlag. Wenn er scheitert, füge nur ein neues Detail hinzu (die nächste Stacktrace-Zeile, einen Config-Flag, eine eingeengte Repro). Teile nicht sofort die ganze Datei.
Diese schrittweise Offenlegung liefert meist echte Antworten und schützt gleichzeitig Geheimnisse und nicht relevante Codebereiche vor der Anfrage.
Ein häufiger Fall: Login funktioniert lokal und in Staging, aber in Produktion nicht. Du brauchst schnell Hilfe, darfst aber keine echten Tokens, Nutzer-E-Mails, internen Hostnamen oder dein komplettes Auth-Middleware posten.
Beginne mit dem Beobachtbaren: Request- und Response-Shape, Statuscode und ein kurzer Stacktrace. Bei JWT-Problemen kannst du auch nicht-sensible Header-Details (wie erwarteter Algorithmus) und Timing-Details (Serverzeitabweichung) teilen. Alles andere ersetze durch Platzhalter.
Ein sicheres Paket enthält häufig:
Dann stelle eine fokussierte Frage. Produktionsspezifische Auth-Fehler kommen oft von Clock Skew, falschem Issuer/Audience, unterschiedlichen Signatur-Keys, fehlender Key-Rotation oder Proxy-/Header-Unterschieden.
Prompt-Muster:
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?
Nachdem du Hypothesen erhältst, verifiziere sie sicher mit temporären Änderungen. Füge temporäres Logging hinzu, das nur nicht-sensible Fakten ausgibt (exp, iat, now und den Grundcode für das Fehlschlagen). Schreibe einen kleinen Test, der ein bekannt-sicheres Token-Fixture verwendet (oder lokal generierte Tokens) und das Validator-Verhalten für Randfälle prüft.
Ein einfacher Plan:
Der schnellste Weg, die Datenschutzvorteile zu verlieren, ist, „ein kleines Ding“ zu teilen, das stillschweigend alles enthält. Eine ganze .env oder Config-Datei zu kopieren ist das klassische Beispiel. Selbst wenn du offensichtliche Geheimnisse entfernst, enthalten solche Dateien oft interne Hostnamen, Servicenamen, Feature-Flags und Umgebungsinformationen, die dein System kartieren.
Komplette Stacktraces sind eine weitere häufige Quelle für Leaks. Sie können Benutzernamen, Maschinennamen, Repo-Namen und absolute Pfade wie /Users/alex/company-payments/... enthalten. Manchmal sind Query-Strings, HTTP-Header oder Error-Objekte mit Tokens darin. Wenn du den Trace brauchst, kopiere nur die relevanten Frames und ersetze Pfade mit konsistenten Platzhaltern.
Echte Kundenpayloads sind riskant, selbst wenn sie „klein“ sind. Ein einzelner JSON-Body kann E-Mails, Adressen, Bestell-IDs oder Freitext-Notizen enthalten. Die sicherere Vorgehensweise ist, ein Fake-Payload mit derselben Struktur und den gleichen Randfällen zu erstellen (fehlende Felder, lange Strings, Sonderzeichen), ohne echte Werte.
Inkonsequente Platzhalter führen ebenfalls zu Problemen. Wenn USER_ID an einer Stelle „Kunden-ID“ und an einer anderen „interne Konto-ID“ bedeutet, erhältst du die falsche Diagnose. Wähle ein Schema und bleibe dabei.
Wenn deine Nachricht einem Fremden helfen würde einzuloggen, deine Server zu lokalisieren oder einen Kunden zu identifizieren, braucht sie eine weitere Überarbeitung.
Wenn du vorsichtig sein willst, ist Tempo dein Feind. Eine kurze Routine hilft dir, nützliche Antworten zu erhalten und gleichzeitig sensible Daten aus der Anfrage herauszuhalten.
Mache einen Pass für Geheimnisse und einen zweiten für Identifikatoren, die noch dein System offenbaren:
Nach dem Redigieren behalte die Form: Typen, Schemata, Feldnamen, Statuscodes und Beispiel-Payload-Struktur bleiben erhalten; echte Werte werden durch Platzhalter ersetzt.
Um konsistent zu bleiben (besonders unter Druck), schreibe ein kleines Set an Redaktionsregeln auf und nutze sie wieder. Für Teams: Mach daraus eine gemeinsame Vorlage mit zwei Blöcken: „Was ich teile“ (Dateien, Funktionen, Endpunkte) und „Was ich nicht teile“ (Geheimnisse, Produktionsdaten, interne Domains).
Wenn du eine zusätzliche Sicherheitsebene willst, führe Experimente in einer isolierten Umgebung aus und halte Änderungen reversibel. In Koder.ai (koder.ai) kann der Planungsmodus helfen, die kleinste Änderung zu skizzieren, und Snapshots plus Rollback erleichtern Tests, ohne zusätzliche sensible Kontexte in deine Prompts zu ziehen.
Beginne mit dem kleinsten Ausschnitt, der deine Frage beantworten kann: die fehlschlagende Eingabe, erwartetes vs. tatsächliches Ergebnis und der enge Codepfad, der betroffen ist.
Ein gutes Standardpaket ist:
Teile niemals:
.env / Config-Dumps oder rohe Produktions-LogsWenn das Teilen einer Information einem Fremden ermöglichen würde, sich einzuloggen, eine Person zu identifizieren oder dein System zu kartieren, dann musst du sie redigieren oder zusammenfassen.
Verwende konsistente Platzhalter, damit der Ablauf lesbar bleibt.
Beispielschema:
TOKEN_1, TOKEN_2API_KEY_1USER_ID_1, Bewahre das Format, wenn der Fehler von Parsing oder Validierung abhängt.
Gängige Fälle:
8-4-4-4-12-MusterSo bleibt das Verhalten realistisch, ohne den echten Wert offenzulegen.
Teile Schlüssel und Struktur, ersetze Werte.
Für JSON:
Für SQL:
Beispiel:
Fasse sie in Bezug auf Eingaben, Ausgaben und die spezifische Regel zusammen, die den Fehler beeinflusst.
Eine praxisnahe Zusammenfassung sollte enthalten:
Das liefert oft denselben Debugging-Wert, ohne deine Implementierung preiszugeben.
Eine einfache, sichere Vorlage sieht so aus:
Füge eine Redaktionsnotiz hinzu wie:
„Redacted: tokens, emails, customer data, internal hostnames. Kept: endpoint paths, status codes, header names, exact error text.“
Weil sie oft alles gleichzeitig enthalten:
Eine sichere Alternative ist eine Config-Vorlage:
Nutze schrittweise Offenlegung:
So bleibt der Umfang klein und versehentliche Leaks unter Druck werden verhindert.
Ein praktisches Paket ist:
Frage dann:
CUSTOMER_ID_1EMAIL_1Füge bei Bedarf eine kurze Legende hinzu:
TOKEN_1: Authorization Bearer-Token, verwendet auf /meCUSTOMER_ID_1: interne Kunden-ID, verwendet in DB-LookupsWHERE user_id = USER_ID_1 AND created_at > DATE_1<set> oder <redacted>