Aprenda a minimizar contexto sensível ao usar Claude Code com templates de prompt práticos, fluxos de compartilhamento de arquivos e passos de redacção que ainda permitem ajuda útil para programar.
“Contexto” é tudo o que você fornece a um modelo: trechos de código, stack traces, arquivos de configuração, variáveis de ambiente, amostras de banco de dados, capturas de tela e até mensagens anteriores no mesmo chat. Mais contexto pode acelerar a depuração, mas também aumenta a chance de você colar algo que não pretendia compartilhar.
O oversharing geralmente acontece sob pressão. Um bug bloqueia uma release, a autenticação quebra pouco antes de uma demo, ou um teste instável só falha no CI. Nesse momento é fácil colar o arquivo inteiro, depois o log inteiro, depois a configuração completa “só por via das dúvidas”. Hábitos de equipe podem empurrar para o mesmo lado: em code review e debugging, visibilidade total é normal, mesmo quando só uma pequena parte é necessária.
Os riscos não são hipotéticos. Um único paste pode vazar segredos, dados de clientes ou detalhes internos do sistema. Exemplos comuns incluem:
O objetivo não é ser secreto. É compartilhar a menor parte que ainda reproduz o problema ou explica a decisão, para obter a mesma qualidade de ajuda com menos exposição.
Um modelo mental simples: trate o assistente como um colega externo útil que não precisa do seu repositório inteiro. Comece com uma pergunta precisa (“Por que essa requisição retorna 401?”). Depois compartilhe apenas o que suporta essa pergunta: a entrada que falha, o resultado esperado, o resultado atual e o caminho de código estreito envolvido.
Se uma chamada de login falha, você geralmente não precisa do módulo de auth inteiro. Um par request/response sanitizado, a função que monta os headers e as chaves de configuração relevantes (com valores substituídos) costuma ser suficiente.
Quando você pede ajuda para programar, “contexto” não é apenas código fonte. É qualquer coisa que possa ajudar alguém a fazer login, identificar uma pessoa ou mapear seus sistemas. Comece sabendo o que é tóxico colar.
Credenciais transformam um snippet útil em um incidente. Isso inclui chaves e tokens de API, chaves privadas, cookies de sessão, URLs assinadas, segredos de clientes OAuth, senhas de banco de dados e “tokens temporários” impressos em logs.
Uma surpresa comum são vazamentos indiretos. Uma mensagem de erro pode incluir headers completos com um Authorization bearer, ou um dump de debug das variáveis de ambiente.
Qualquer dado ligado a uma pessoa pode ser sensível, mesmo que pareça inofensivo isoladamente. Fique atento a emails, nomes, telefones, endereços, IDs de clientes, IDs de funcionários, tickets de suporte com conversas e detalhes de pagamento.
Se você precisa de dados para reproduzir um bug, troque registros reais por falsos realistas. Mantenha a forma (campos e tipos), não a identidade.
Fatos “chatos” internos são valiosos para atacantes e concorrentes: hostnames, IPs, nomes de repositórios, IDs de tickets, nomes de fornecedores, termos contratuais e URLs de serviços internos.
Mesmo um único stack trace pode revelar caminhos de pasta com nomes de usuário ou cliente, convenções de nomenclatura de serviço e pistas de conta de nuvem (nomes de buckets, strings de região).
Nem todo código é igualmente sensível. As partes mais arriscadas são as que codificam como seu negócio funciona: regras de preço e desconto, checagens de fraude, lógica de recomendação, templates de prompt para recursos de LLM e documentos estratégicos.
Se precisar de ajuda com um bug, compartilhe a menor função que o reproduza, não o módulo inteiro.
Detalhes sensíveis frequentemente aparecem em lugares que você não nota: comentários com nomes, mensagens de commit, TODOs referindo clientes e stack traces coladas “como estão”. Arquivos de configuração são especialmente arriscados porque misturam configurações inofensivas com segredos.
Uma regra prática: se o texto ajudaria alguém a entender seu sistema mais rápido do que um exemplo em sala limpa faria, trate-o como sensível e redija ou substitua.
O melhor momento para reduzir exposição é antes de abrir o editor. Uma pausa de 30 segundos para definir o resultado muitas vezes corta o que você compartilha pela maior parte.
Comece nomeando o resultado que você quer em uma frase. Você está tentando encontrar a causa de um bug, obter um plano de refatoração seguro ou desenhar testes? Cada objetivo precisa de entradas diferentes. Caça a bugs geralmente precisa de um stack trace e uma função pequena. Questões de refatoração costumam precisar só das interfaces públicas e um exemplo curto de uso atual.
Depois escolha um “artefato mínimo” que prove o problema. Pegue a menor coisa que ainda falha: um único teste que falha, o menor trecho que dispara o erro, um trecho curto de log em torno da falha ou um exemplo simplificado de configuração com placeholders.
Ao descrever dados, prefira formas em vez de valores. “Objeto User tem id (UUID), email (string), role (enum), createdAt (timestamp)” quase sempre é suficiente. Se precisar de exemplos, use falsos que batam com o formato, não registros reais.
Seja rígido com arquivos. Compartilhe apenas o módulo que você está mudando e as interfaces que ele toca. Se uma função chama outro módulo, muitas vezes você só precisa da assinatura e uma curta descrição do que ele retorna. Se um bug envolve uma requisição a outro serviço, talvez você só precise do formato da requisição, da lista de nomes de headers (não dos valores) e do formato de resposta esperado.
Estabeleça limites que nunca saiam da sua máquina: chaves de API, certificados privados, tokens de acesso, dados de clientes, URLs internas, dumps completos do repositório e logs brutos de produção. Se você está debugando um 401, compartilhe o fluxo de auth e a mensagem de erro, mas substitua o token por TOKEN_REDACTED e o email por [email protected].
Uma boa redacção não é só esconder segredos. Ela preserva a estrutura do problema para que o assistente ainda possa raciocinar sobre ele. Remover demais resulta em conselho genérico. Remover de menos arrisca vazar dados.
Escolha um estilo de placeholder e mantenha-o em código, config e logs. Consistência facilita seguir o fluxo.
Se o mesmo token aparece em três lugares, não substitua de três formas diferentes. Use placeholders como API_KEY_1, TOKEN_1, USER_ID_1, CUSTOMER_ID_1, EMAIL_1 e incremente conforme necessário (TOKEN_2, TOKEN_3).
Uma legenda curta ajuda sem revelar valores reais:
TOKEN_1: bearer token usado no header AuthorizationCUSTOMER_ID_1: identificador de cliente interno usado na busca do bancoAPI_KEY_1: chave usada para chamar o provedor de pagamentoAlguns bugs dependem do tamanho e da estrutura (parsing, validação, checagem de assinatura, regex). Nesses casos, substitua strings únicas por valores fictícios que mantenham a aparência.
Por exemplo:
Isso permite dizer “o token falha na validação” sem expor o token real.
Ao compartilhar JSON, mantenha as chaves e substitua valores. As chaves mostram o que o sistema espera; os valores frequentemente são a parte sensível.
Ao invés de:
{"email":"[email protected]","password":"SuperSecret!","mfa_code":"123456","customer_id":"c8b1..."}
Compartilhe:
{"email":"EMAIL_1","password":"PASSWORD_1","mfa_code":"MFA_CODE_1","customer_id":"CUSTOMER_ID_1"}
A mesma ideia para SQL: mantenha nomes de tabelas, joins e condições, mas remova literais.
WHERE user_id = USER_ID_1 AND created_at > DATE_1Se uma função contém regras de negócio ou lógica proprietária, descreva-a. Mantenha o que afeta o bug: entradas, saídas, efeitos colaterais e tratamento de erros.
Exemplo de resumo que continua útil:
“signRequest(payload) recebe um payload JSON, adiciona timestamp e nonce, então cria uma assinatura HMAC SHA-256 a partir de method + path + body. Retorna {headers, body}. O erro acontece quando o payload inclui caracteres não ASCII.”
Isso geralmente é suficiente para diagnosticar problemas de codificação, canonicalização e mismatch de assinatura sem expor a implementação completa.
Ao final do seu prompt, informe o que você removeu e o que manteve. Isso evita idas e vindas e reduz a chance de você ser solicitado a colar mais.
Exemplo:
“Redigido: tokens, emails, dados de clientes, bodies completos de requisição. Mantido: caminhos de endpoint, códigos de status, nomes de headers, frames do stack trace e o texto exato do erro.”
Trate o assistente como um colega que só precisa da parte em que você está trabalhando. Compartilhe interfaces e contratos em vez de arquivos inteiros: assinaturas de função, tipos, formatos de requisição/resposta e o texto exato do erro.
Um repro mínimo em linguagem simples frequentemente é suficiente: a entrada usada, o que você esperava, o que aconteceu em vez disso e algumas notas de ambiente (versão do runtime, SO, versão do framework). Você não precisa do histórico completo do projeto.
Templates que tendem a funcionar bem:
Um bloco de config sanitizado é um bom meio-termo. Ele mostra quais botões existem sem expor segredos:
# sanitized
DB_HOST: "<set>"
DB_PORT: "5432"
DB_USER: "<set>"
DB_PASSWORD: "<redacted>"
JWT_SECRET: "<redacted>"
OAUTH_CLIENT_ID: "<set>"
OAUTH_CLIENT_SECRET: "<redacted>"
Exemplo de prompt seguro:
“Login falha com 401. Esperado 200. Body da resposta: ‘invalid token’. Ambiente: Node 20, dev local, sincronização de tempo habilitada. Contrato da requisição: Authorization: Bearer \u003credacted\u003e. Passos: token é emitido por /auth/login e usado em /me. Quais são as principais causas (clock skew, mismatch de audience, mismatch de secret de assinatura) e qual checagem única confirma cada uma?”
Um hábito confiável é tratar o compartilhamento como empacotar uma pequena reprodução. Compartilhe o suficiente para diagnosticar o problema e nada mais.
Uma abordagem prática é uma “pasta de compartilhamento” temporária separada do seu repositório real. Copie arquivos para ela manualmente em vez de compartilhar o projeto inteiro. Isso força escolhas intencionais.
Mantenha o fluxo simples:
Depois de montar a pasta, leia-a como um estranho. Se um arquivo não ajuda a depurar o problema específico, ele não pertence ali.
Ao redigir, evite quebrar o código ou os logs. Substitua valores por placeholders óbvios que mantenham tipo e estrutura. Por exemplo, troque:
DATABASE_URL=postgres://user:[email protected]:5432/app
por:
DATABASE_URL=postgres://user:REDACTED@localhost:5432/app
Se o bug depende da resposta de um terceiro, escreva a forma da resposta no README e inclua um JSON sintético que a corresponda. Dá para obter depuração significativa sem compartilhar tráfego real.
Use um loop repetível para não improvisar sob pressão.
Escreva duas frases primeiro.
Colete as entradas mínimas. Traga só o que ajuda a reproduzir ou raciocinar sobre o problema: um pequeno trecho ao redor da linha que falha, o texto exato do erro, versões relevantes e 3 a 5 passos de repro.
Redija sem achatar a estrutura. Substitua segredos por placeholders e mantenha a forma intacta. Remova identificadores que não afetam o comportamento (nomes de projeto, tenant IDs, emails). Mantenha placeholders consistentes.
API_KEY=sk_live_...
becomes
API_KEY=<API_KEY>
customer-1234-prod-db
becomes
<DB_HOST_PROD>
Faça perguntas direcionadas. Combine “Qual a causa mais provável?” com “O que devo mudar?”. Se quiser um patch, peça uma alteração limitada ao trecho que forneceu e exija que suposições sejam rotuladas.
Verifique localmente, depois adicione um detalhe novo. Teste a sugestão. Se falhar, adicione apenas um novo pedaço de informação (a próxima linha do stack trace, uma flag de config, um repro mais estreito). Não cole o arquivo inteiro de cara.
Essa divulgação incremental geralmente consegue uma resposta real mantendo segredos e código não relacionado fora do prompt.
Uma situação comum: login funciona no laptop e em staging, mas falha em produção. Você precisa de ajuda rápido, mas não pode colar tokens reais, emails de usuários, hostnames internos ou seu middleware de auth completo.
Comece pelo que pode observar: formato da requisição e resposta, código de status e um stack trace curto. Se for relacionado a JWT, você também pode compartilhar detalhes de header não sensíveis (como o algoritmo esperado) e informações de tempo (como drift do servidor). Mantenha todo o resto em placeholders.
Um pacote seguro costuma incluir:
Então faça uma pergunta focada. Falhas de auth só em produção frequentemente vêm de clock skew, issuer/audience errados, chaves de assinatura diferentes, rotação de chave faltante ou diferenças de proxy/header.
Padrão de 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?
Depois de receber hipóteses, valide com mudanças seguras que você pode manter. Adicione logging temporário que imprima apenas fatos não sensíveis (exp, iat, now e o código de razão da falha). Escreva um teste pequeno que alimente um token fixture seguro (ou um token gerado localmente) e asserte o comportamento do validador para casos de borda.
Um plano simples:
A maneira mais rápida de perder os benefícios de privacidade é compartilhar “uma pequena coisa” que, silenciosamente, contém tudo. Colar um .env completo ou um arquivo de config é o exemplo clássico. Mesmo se você deletar segredos óbvios, esses arquivos frequentemente incluem hostnames internos, nomes de serviço, feature flags e pistas de ambiente que mapeiam seu sistema.
Stack traces completos são outro vazamento frequente. Podem incluir usernames, nomes de máquina, nomes de repositório e caminhos absolutos como /Users/alex/company-payments/.... Às vezes incluem query strings, headers HTTP ou objetos de erro com tokens. Se precisar do trace, copie apenas os frames relevantes e substitua caminhos por placeholders consistentes.
Payloads reais de clientes são arriscados mesmo quando “pequenos”. Um JSON pode incluir emails, endereços, IDs de pedidos ou notas de texto livre. A alternativa mais segura é gerar um payload falso com a mesma forma e casos de borda (campos faltando, strings longas, caracteres estranhos), sem valores reais.
Placeholders inconsistentes também causam problemas. Se USER_ID significa “id de cliente” em um lugar e “id de conta interna” em outro, o diagnóstico será errado. Escolha um esquema e mantenha-o.
Se sua mensagem ajudaria um estranho a fazer login, localizar seus servidores ou identificar um cliente, ela precisa de outra revisão.
Quando você tenta ser cuidadoso, velocidade é inimiga. Uma rotina curta ajuda a obter respostas úteis mantendo dados sensíveis fora do prompt.
Faça uma passagem para segredos, depois uma segunda para identificadores que ainda expõem seu sistema:
Após redigir, mantenha a forma. Deixe tipos, schemas, nomes de campos, códigos de status e estrutura de payload intactos, mas troque valores reais por placeholders.
Para manter consistência (especialmente sob pressão), escreva um pequeno conjunto de regras de redacção e reutilize-as. Para equipes, transforme isso em um template compartilhado com dois blocos: “o que estou compartilhando” (arquivos, funções, endpoints) e “o que não estou compartilhando” (segredos, dados de produção, domínios internos).
Se quiser uma camada extra de segurança, faça experimentos em um ambiente isolado e mantenha mudanças reversíveis. No Koder.ai (koder.ai), o modo de planejamento pode ajudar a delinear a menor mudança necessária para testar uma hipótese, e snapshots com rollback facilitam tentar uma correção sem arrastar contexto sensível para os prompts.
Comece com o menor fragmento que responda à sua pergunta: a entrada que falha, o esperado vs o real, e o caminho de código estreito envolvido.
Um pacote padrão útil é:
Não cole:
.env/configs completos ou logs brutos de produçãoSe isso ajudaria um estranho a fazer login, identificar uma pessoa ou mapear seus sistemas, redija ou resuma.
Use placeholders consistentes para que o fluxo continue legível.
Exemplo de esquema:
TOKEN_1, TOKEN_2API_KEY_1USER_ID_1, Preserve o formato quando o bug depende de parsing ou validação.
Casos comuns:
8-4-4-4-12Isso mantém o comportamento realista sem expor o valor verdadeiro.
Compartilhe chaves e estrutura, substitua valores.
Para JSON:
Para SQL:
Exemplo:
Resuma em termos de entradas, saídas e a regra específica que afeta o bug.
Um resumo prático inclui:
Isso costuma trazer o mesmo valor de depuração sem revelar sua implementação.
Um prompt seguro simples contém:
Inclua também uma nota de redacção como:
“Redigido: tokens, emails, dados de clientes, hostnames internos. Mantido: caminhos de endpoint, códigos de status, nomes de cabeçalhos, texto exato do erro.”
Porque eles geralmente contêm tudo de uma vez:
Uma alternativa mais segura é um template de config:
Use divulgação incremental:
Isso mantém o escopo pequeno e evita vazamentos acidentais sob pressão.
Um pacote prático inclui:
Depois, pergunte:
CUSTOMER_ID_1EMAIL_1Adicione uma pequena legenda quando necessário:
TOKEN_1: token bearer usado em /meCUSTOMER_ID_1: identificador interno usado na busca do bancoWHERE user_id = USER_ID_1 AND created_at > DATE_1\u003cset\u003e ou \u003credacted\u003e