Pratik istem şablonları, dosya paylaşma iş akışları ve sansür adımlarıyla Claude Code'da hassas bağlamı nasıl azaltacağınızı öğrenin—hala işe yarayan kod yardımı alırken gizliliği koruyun.
“Bağlam”, modelle paylaştığınız her şeydir: kod parçaları, stack trace'ler, konfig dosyaları, ortam değişkenleri, veritabanı örnekleri, ekran görüntüleri ve aynı sohbet içindeki önceki mesajlar. Daha fazla bağlam hata ayıklamayı hızlandırabilir, ancak istemeden paylaşacağınız bir şeyi yapıştırma olasılığını da artırır.
Aşırı paylaşım genellikle baskı altında olur. Bir hata bir yayını engelliyor, oturum açma bir demo öncesinde bozuluyor ya da flakiy test yalnızca CI'de hata veriyor olabilir. O anda tüm dosyayı, sonra tüm logu, sonra tüm konfigüru "tedbir amaçlı" yapıştırmak kolaydır. Ekip alışkanlıkları da aynı yönde itebilir: kod incelemede ve hata ayıklamada tam görünürlük normaldir, oysa yalnızca küçük bir parça gereklidir.
Riskler teorik değil. Tek bir yapıştırma gizli bilgileri, müşteri verilerini veya iç sistem detaylarını sızdırabilir. Yaygın örnekler şunlardır:
Amaç gizemli olmak değil. Sorunu çoğaltacak veya kararı açıklayacak en küçük parçayı paylaşmaktır; böylece aynı kalitede yardım alır, ama daha az maruziyet yaşarsınız.
Basit bir zihinsel model: asistana tüm repoyu bilmesi gereken yardımcı dış ekip arkadaşı gibi davranmayın. Önce tek ve kesin bir soru ile başlayın (“Neden bu istek 401 dönüyor?”). Sonra bu soruyu destekleyenleri paylaşın: başarısız girdi, beklenen çıktı, gerçek çıktı ve ilgili dar kod yolu.
Bir giriş çağrısı başarısız oluyorsa, genellikle tüm auth modülünü paylaşmanıza gerek yoktur. Bir sanitizelenmiş istek/yanıt çifti, başlıkları oluşturan fonksiyon ve ilgili konfig anahtarları (değerler yerine yer tutucularla) çoğu durumda yeterlidir.
Kod yardımı isterken “bağlam” sadece kaynak kod değildir. Birine giriş yapma, bir kişiyi tanımlama veya sistemlerinizi eşleme imkanı verebilecek her şeydir. Önce neyin toksik olduğunu bilin.
Kimlik bilgileri yardımcı bir parçayı bir olay haline getirir. Buna API anahtarları ve tokenlar, özel anahtarlar, session cookie'leri, imzalanmış URL'ler, OAuth istemci sırları, veritabanı parolaları ve loglarda yazdırılan “geçici” tokenlar dahildir.
Dolaylı sızıntılar sürpriz olabilir. Bir hata mesajı Authorization bearer token içeren tam istek header'larını veya ortam değişkenlerinin debug çıktısını içerebilir.
Bir kişiye bağlı her veri hassas olabilir, tek başına zararsız görünse bile. E-postalar, isimler, telefon numaraları, adresler, müşteri ID'leri, çalışan ID'leri, destek ticket'ları ve ödeme detaylarına dikkat edin.
Bir hatayı çoğaltmak için veriye ihtiyaç varsa, gerçek kayıtları gerçek değerleri yerine gerçekçi sahte verilerle değiştirin. Şekli (alanlar ve tipler) koruyun, kimliği değil.
“Sıkıcı” iç bilgiler saldırganlar ve rakipler için değerlidir: host isimleri, IP'ler, repo isimleri, ticket ID'leri, tedarikçi isimleri, sözleşme koşulları ve iç servis URL'leri.
Tek bir stack trace bile klasör yollarında kullanıcı adlarını veya müşteri isimlerini, servis adlandırma konvansiyonlarını ve bulut hesap ipuçlarını (bucket isimleri, bölge dizeleri) açığa çıkarabilir.
Tüm kod aynı derecede hassas değildir. En riskli parçalar işinizin nasıl çalıştığını kodlayanlardır: fiyatlama ve indirim kuralları, dolandırıcılık kontrolleri, öneri mantığı, LLM özellikleri için prompt şablonları ve stratejik dokümanlar.
Bir hata için yardım istiyorsanız, tüm modülü değil hatayı yeniden üreten en küçük fonksiyonu paylaşın.
Hassas detaylar çoğu zaman fark etmediğiniz yerlerde gezer: içeren yorumlar, commit mesajları, müşteriye referans veren TODO'lar ve olduğu gibi yapıştırılmış stack trace'ler. Konfig dosyaları özellikle risklidir çünkü masum ayarlarla gizlileri karıştırırlar.
Pratik bir kural: metin, temiz bir örneğin sisteminizi daha hızlı anlamasına yardımcı oluyorsa, onu hassas kabul edin ve sansürleyin veya değiştiriş yapın.
Maruz kalmayı azaltmanın en iyi zamanı editörünüzü açmadan önce. Sonuçtan 30 saniyelik bir düşünme çoğu şeyi azaltır.
İsteneni bir cümlede adlandırarak başlayın. Bir hatanın nedenini mi bulmaya çalışıyorsunuz, güvenli bir refactor planı mı istiyorsunuz yoksa test tasarımı mı? Her hedef farklı girdiler gerektirir. Hata avları genellikle tek bir stack trace ve küçük bir fonksiyon gerektirir. Refactor soruları genellikle yalnızca public arayüzleri ve kısa bir kullanım örneğini ister.
Sonra problemi kanıtlayan bir “minimal artefakt” seçin. Hataları tetikleyen en küçük şeyi seçin: tek başarısız test, hatayı tetikleyen en küçük snippet, başarısızlığın etrafından kısa bir log alıntısı veya yer tutucular içeren basitleştirilmiş bir konfig örneği.
Verileri tanımlarken, değerler yerine şekillere öncelik verin. “Kullanıcı nesnesi: id (UUID), email (string), role (enum), createdAt (timestamp)” genelde yeterlidir. Örnekler gerekiyorsa, formatı eşleyen sahte veriler kullanın, gerçek kayıtları değil.
Dosyalar konusunda katı olun. Yalnızca değiştirdiğiniz modülü ve etkileştiği arayüzleri paylaşın. Bir fonksiyon başka bir modüle çağrı yapıyorsa genellikle yalnızca imzayı ve döndürdüğü şeyin kısa bir açıklamasını paylaşmanız yeterlidir. Bir hata başka bir servise yapılan bir isteği içeriyorsa, genellikle sadece istek şekli, header isimlerinin listesi (değerler değil) ve beklenen yanıt şekli yeterli olur.
Bilgisayarınızdan asla çıkmayacak sert sınırlar belirleyin: API anahtarları, özel sertifikalar, erişim tokenları, müşteri verileri, iç URL'ler, tam repo dökümleri ve ham üretim logları. Eğer 401 hatasını debug ediyorsanız, auth akışını ve hata mesajını paylaşın, ama tokenı TOKEN_REDACTED ile ve e-postayı [email protected] ile değiştirin.
İyi sansür sadece gizlileri gizlemek değildir. Problemin yapısını korur, böylece asistan hala mantık yürütebilir. Çok fazlasını kaldırırsanız genel tavsiye alırsınız; çok azını kaldırırsanız veri sızdırırsınız.
Bir yer tutucu stili seçin ve kod, konfig ve loglarda tutarlı kullanın. Tutarlılık akışı takip etmeyi kolaylaştırır.
Aynı token üç yerde görünüyorsa, üç farklı şekilde değiştirmeyin. API_KEY_1, TOKEN_1, USER_ID_1, CUSTOMER_ID_1, EMAIL_1 gibi yer tutucular kullanın ve gerektiğinde numaralandırın (TOKEN_2, TOKEN_3).
Kısa bir efsane yardımcı olur:
TOKEN_1: Authorization header'da kullanılan bearer tokenCUSTOMER_ID_1: veritabanı aramasında kullanılan dahili müşteri kimliğiAPI_KEY_1: ödeme sağlayıcısına çağrı yaparken kullanılan anahtarBazı hatalar uzunluk ve yapıya bağlıdır (parsing, doğrulama, imza kontrolleri, regex). Bu durumlarda benzeyen dummy değerler kullanın.
Örneğin:
8-4-4-4-12 desenini koruyunBu sayede “token doğrulama hatası alıyorum” diyebilirsiniz, gerçek tokenı ifşa etmeden.
JSON paylaşırken anahtarları bırakın ve değerleri değiştirin. Anahtarlar sistemin ne beklediğini gösterir; değerler genellikle hassastır.
Yerine koyma örneği:
{"email":"EMAIL_1","password":"PASSWORD_1","mfa_code":"MFA_CODE_1","customer_id":"CUSTOMER_ID_1"}
SQL için de aynı fikir geçerli: tablo isimlerini, joinleri ve koşulları tutun ama literal değerleri kaldırın.
WHERE user_id = USER_ID_1 AND created_at > DATE_1Bir fonksiyon iş kuralları veya tescilli mantık içeriyorsa, onu tanımlayın. Hatanın neyi etkilediğini tutun: girdi, çıktı, yan etkiler ve hata ele alma.
Örnek özet:
“signRequest(payload) bir JSON payload alır, timestamp ve nonce ekler, sonra method + path + body'den HMAC SHA-256 imzası oluşturur. {headers, body} döndürür. Hata payload non-ASCII karakter içerdiğinde oluşuyor.”
Bu genelde kodun tam implementasyonunu açığa çıkarmadan kodlama, canonicalization ve imza uyuşmazlıklarını teşhis etmeye yeter.
İsteminizin sonunda neyi kaldırdığınızı ve neyi bıraktığınızı belirtin. Bu tur-söhbette geri dönüşleri azaltır ve daha fazlasının istenme olasılığını düşürür.
Örnek:
“Redacted: tokens, emails, customer data, full request bodies. Kept: endpoint paths, status codes, header names, stack trace frames, and the exact error text.”
Asistanı yalnızca aktif olarak üzerinde çalıştığınız parçayı bilmesi gereken bir iş arkadaşı gibi ele alın. Tüm dosyaları paylaşmak yerine arayüzleri ve kontratları paylaşın: fonksiyon imzaları, tipler, istek/yanıt şekilleri ve kesin hata metni.
Açık dilde küçük bir yeniden üretme genelde yeterlidir: kullandığınız girdi, beklenen çıktı, gerçekleşen ve birkaç ortam notu (runtime sürümü, OS, framework sürümü). Proje geçmişinize gerek yoktur.
Etkili olma eğilimindeki şablonlar:
Sansürlenmiş bir konfig blok'u iyi bir orta yol sağlar: hangi düğmelerin olduğunu gösterir, gizlileri açığa çıkarmadan.
# sanitized
DB_HOST: "\u003cset\u003e"
DB_PORT: "5432"
DB_USER: "\u003cset\u003e"
DB_PASSWORD: "\u003credacted\u003e"
JWT_SECRET: "\u003credacted\u003e"
OAUTH_CLIENT_ID: "\u003cset\u003e"
OAUTH_CLIENT_SECRET: "\u003credacted\u003e"
Güvenli bir örnek istem:
“Giriş 401 dönüyor. Beklenen 200. Gerçek yanıt gövdesi: ‘invalid token’. Ortam: Node 20, local dev, zaman senkronizasyonu etkin. İstek kontratı: Authorization: Bearer \u003credacted\u003e. Doğrulama adımları: token /auth/login tarafından veriliyor ve /me üzerinde kullanılıyor. En olası sebepler nelerdir (clock skew, audience mismatch, signing secret mismatch) ve her biri için hangi tek kontrol bunu doğrular?”
Güvenilir bir alışkanlık, paylaşmayı küçük bir reproducible paket olarak ele almaktır. Sorunu teşhis edecek kadar paylaşın, daha fazlasını değil.
Pratik bir yol, gerçek repodan ayrı geçici bir “share folder” tutmaktır. Dosyaları manuel olarak oraya kopyalayın; bu kasıtlı seçimleri zorunlu kılar.
İş akışını basit tutun:
Klasör oluşturduktan sonra dışarıdan birisi gibi okuyun. Bir dosya spesifik problemi çözmeye yardımcı olmuyorsa, orada olmamalıdır.
Sansürlerken kodun veya logların bozulmasından kaçının. Değerleri type ve yapıyı koruyan bariz yer tutucularla değiştirin. Örnek:
DATABASE_URL=postgres://user:[email protected]:5432/app
ile
DATABASE_URL=postgres://user:REDACTED@localhost:5432/app
Değişiklik üçüncü taraf yanıtına bağlıysa, README'de yanıt şekline dair not yazın ve eşleşen sentetik bir JSON dosyası ekleyin. Gerçek trafik paylaşmadan anlamlı hata ayıklama yapabilirsiniz.
Tekrar edilebilir bir döngü kullanın ki baskı altında doğaçlama yapmayın.
Önce iki cümle yazın.
Minimum girdileri toplayın. Yalnızca yeniden üretmeye veya sorunu mantıksal olarak incelemeye yardımcı olacakları getirin: başarısız satır etrafındaki küçük bir snippet, kesin hata metni, ilgili sürümler ve 3–5 repro adımı.
Yapıyı bozmadan sansürleyin. Gizli bilgileri yer tutucularla değiştirin ve şekli koruyun. Davranışı etkilemeyen kimlikleri (proje isimleri, tenant ID'leri, e-postalar) kaldırın. Yer tutucuları tutarlı kullanın.
API_KEY=sk_live_...
becomes
API_KEY=\u003cAPI_KEY\u003e
customer-1234-prod-db
becomes
\u003cDB_HOST_PROD\u003e
Hedeflenen sorular sorun. “En olası neden nedir?” ile “Ne değiştirmeliyim?”ı eşleştirin. Yama istiyorsanız, sağladığınız snippet ile sınırlı bir değişiklik isteyin ve varsayımların etiketlenmesini talep edin.
Yerelde doğrulayın, sonra bir ayrıntı daha ekleyin. Öneriyi test edin. Başarısız olursa, yalnızca bir yeni bilgi ekleyin (bir sonraki stack trace satırı, bir konfig bayrağı, daraltılmış bir repro). Doğrudan tüm dosyayı yapıştırmayın.
Bu kademeli açıklama genelde gerçek bir cevap almanızı sağlar ve gizli bilgileri sohbetten uzak tutar.
Yaygın bir durum: laptopta ve staging'de giriş çalışıyor, ama üretimde başarısız oluyor. Hemen yardım gerekir, fakat gerçek tokenları, kullanıcı e-postalarını, iç host isimlerini veya tam auth middleware'ini yapıştıramazsınız.
Başlangıç olarak gözlemleyebildiğiniz şeyleri paylaşın: istek ve yanıt şekli, status kodu ve kısa bir stack trace. JWT ile ilgiliyse, hassas olmayan header detaylarını (beklenen algoritma gibi) ve zamanla ilgili notları paylaşabilirsiniz. Geri kalan her şeyi yer tutucularla değiştirin.
Güvenli bir paket genelde şunları içerir:
Sonra odaklanmış bir soru sorun. Prod-özel auth hataları genelde clock skew, yanlış issuer/audience, farklı imza anahtarları, anahtar rotasyon eksikliği veya proxy/header farklılıklarından kaynaklanır.
İstem deseni:
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 \u003cJWT_REDACTED\u003e
- Expected claims: iss=\u003cISSUER_PLACEHOLDER\u003e, aud=\u003cAUDIENCE_PLACEHOLDER\u003e
- Token validation library: \u003cLIB_NAME_AND_VERSION\u003e
Sanitized log snippet:
\u003cPASTE 5-10 LINES WITH TOKENS/EMAILS/HOSTS REDACTED\u003e
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?
Hipotezleri aldıktan sonra güvenli şekilde doğrulamalar yapın. Sadece hassas olmayan gerçekleri (exp, iat, now ve başarısızlık neden kodu) yazan geçici loglama ekleyin. Bilinçli bir test yazın: bilinen-güvenli bir token fixture'ı ile doğrulayıcı davranışı sınayın. Geçerli sonucu doğruladıktan sonra geçici logları kaldırın.
Basit bir plan:
Mahremiyete dair faydayı hızlı şekilde kaybetmenin en kolay yolu “küçük bir şey” yapıştırırken içeriğin her şeyi barındırmasıdır. Tam .env veya konfig dosyasını yapıştırmak klasik örnektir. Belki açık gizlileri sildiğinizi düşünürsünüz, ama bu dosyalar genellikle iç host isimleri, servis isimleri, feature flag'leri ve ortam ipuçlarını içerir.
Tam stack trace'ler sıkça bilgi sızdırır. Kullanıcı adları, makine isimleri, repo isimleri ve /Users/alex/company-payments/... gibi mutlak yollar içerebilirler. Trace gerekiyorsa, sadece ilgili frame'leri kopyalayın ve yolları tutarlı yer tutucularla değiştirin.
Gerçek müşteri yükleri “küçük” görünseler bile risklidir. Tek bir JSON gövdesi e-postalar, adresler, sipariş ID'leri veya serbest metin notları içerebilir. Daha güvenli hareket, aynı şekil ve sınır durumları (eksik alanlar, uzun dizeler, garip karakterler) içeren sahte yük oluşturmaktır.
Tutarsız yer tutucular da sorun çıkarır. Eğer USER_ID bir yerde “müşteri id” ve başka yerde “iç hesap id” anlamına geliyorsa yanlış teşhis alırsınız. Bir şema seçin ve ona sadık kalın.
Mesajınız bir yabancının giriş yapmasına, sunucularınızı bulmasına veya bir müşteriyi tanımlamasına yardımcı olacaksa, bir tur daha sansürleyin.
Dikkatli olmaya çalışırken hız düşmanınızdır. Kısa bir rutin, yararlı cevaplar alırken hassas verileri dışarıda tutmanıza yardımcı olur.
İlk turda gizlilere bakın, ikinci turda sistemi açığa çıkaran tanımlayıcıları sansürleyin:
Sansürledikten sonra yapıyı koruyun. Tipleri, şemaları, alan isimlerini, status kodlarını ve örnek yük yapılarını bırakın; gerçek değerleri yer tutucularla değiştirin.
Baskı altında da tutarlı kalmak için küçük bir sansür kural seti yazın ve yeniden kullanın. Ekipler için bunu iki bloklu bir şablona çevirin: “paylaşıyorum” (dosyalar, fonksiyonlar, endpoint'ler) ve “paylaşmıyorum” (gizli anahtarlar, üretim verileri, iç domainler).
Ek güvenlik için deneyleri izole bir ortamda yapın ve değişiklikleri geri alınabilir tutun. Koder.ai (koder.ai) içinde planning mode, bir hipotezi test etmek için gereken en küçük değişikliği tasarlamanıza ve snapshot/rollback ile riskleri azaltmanıza yardımcı olabilir.
Sorunu cevaplayabilecek en küçük dilimi paylaşarak başlayın: başarısız olan girdi, beklenen ile gerçek çıktı arasındaki fark ve ilgili dar kod yolu.
İyi bir varsayılan paket şunları içerir:
Aşağıdakileri yapıştırmayın:
.env/konfigürasyon dosyaları veya ham üretim loglarıEğer paylaştığınız şey bir yabancının giriş yapmasına, bir kişiyi tanımlamasına veya sisteminizi eşlemesine yardımcı oluyorsa, sansürleyin veya özetleyin.
Akışı okunur tutacak şekilde tutarlı yer tutucular kullanın.
Örnek şema:
TOKEN_1, TOKEN_2API_KEY_1USER_ID_1, Hata ayrıştırma veya doğrulamaya bağlıysa formatı koruyun.
Yaygın durumlar:
8-4-4-4-12 desenini koruyunBu, gerçek değeri açığa çıkarmadan davranışı gerçekçi tutar.
Anahtarları ve yapıyı bırakın, değerleri değiştirin.
JSON için:
SQL için:
Örnek:
Proprietary (özel) mantık içeren kodunuz varsa, girdi/çıktı ve hatayı etkileyen kuralı özetleyin.
Pratik bir özet şunları içermelidir:
Bu, implementasyonu açığa çıkarmadan aynı hata ayıklama değerini sağlar.
Basit ve güvenli bir istem şablonu:
Ayrıca şu tarz bir sansür notu ekleyin:
“Redacted: tokens, emails, customer data, internal hostnames. Kept: endpoint paths, status codes, header names, exact error text.”
Çünkü genellikle her şeyi bir arada tutarlar:
Daha güvenli alternatif bir konfig şablonu:
Aşamalı açıklama kullanın:
Bu, kapsamı küçük tutar ve baskı altında yanlışlıkla sızıntı yapılmasını önler.
Pratik paket şunları içerir:
Sonra şu soruyu sorun:
CUSTOMER_ID_1EMAIL_1Gerektiğinde kısa bir anahtar ekleyin:
TOKEN_1: /me üzerinde kullanılan Authorization bearer tokenCUSTOMER_ID_1: veritabanı aramasında kullanılan müşteri kimliğiWHERE user_id = USER_ID_1 AND created_at > DATE_1\u003cset\u003e veya \u003credacted\u003e ile değiştirin