Voltar as noticias
Token de configuração do Claude corrige autenticação e remove conectores
Agentic SEOMediaEN

Token de configuração do Claude corrige autenticação e remove conectores

Dev.to - MCP·1 de setembro de 2026

Se você adicionou CLAUDE_CODE_OAUTH_TOKEN a um trabalho agendado claude -p, seus conectores claude.ai — Gmail, Google Calendar, Google Drive — desapareceram, e nada te avisou. Um setup-token "só pode fazer solicitações de modelo", e ele fica acima da sua sessão /login na precedência de autenticação do Claude Code, então configurá-lo silencia a sessão que os conectores utilizam. Eles não geram erro; eles nunca entram na lista de ferramentas. Mantenha a sessão do chaveiro como primária e faça do token um fallback explicitamente degradado. Vá para a correção.

Com uma sessão de chaveiro /login, o Claude Code busca a sessão da conta claude.ai e os conectores Gmail, Google Calendar e Google Drive aparecem na lista de ferramentas; com o CLAUDE_CODE_OAUTH_TOKEN configurado, a sessão da conta nunca é buscada e esses três conectores nunca aparecem, enquanto as solicitações de modelo têm sucesso em ambas as vias.

Eu executo um trabalho de agente agendado diariamente em um Mac: um agente launchd dispara um claude -p sem interface às 06:05, o agente lê um repositório de planejamento, verifica meu e-mail e calendário para qualquer coisa devida, e escreve um arquivo de standup. Tem sido confiável por meses. Então, ele ficou cego por quatro dias e cada uma dessas execuções me disse que tinha sido bem-sucedida.

O problema: launchd, um chaveiro e uma correção que funcionou

Uma manhã, o trabalho simplesmente não produziu nada. O log tinha a parte útil:

=== daily-standup 06:05 ===
Sessão OAuth expirou e não pôde ser renovada
=== daily-standup FALHOU (saída 1): nenhum artefato escrito ===

(Em versões atuais, isso aparece como Login expirado · Por favor, execute /login; a CLI documenta tanto o aviso quanto o estado expirado.)

Esse é o clássico problema do macOS sem supervisão. O Claude Code armazena credenciais de assinatura no Chaveiro de login criptografado, e um trabalho iniciado pelo launchd em uma máquina que acordou do sono não é a mesma coisa que você sentado em um terminal. Há um bug aberto de longa data onde uma árvore de processos enraizada no launchd relata "não logado" contra credenciais que security find-generic-password pode ler perfeitamente bem do mesmo contexto. Qualquer que seja a causa precisa em um determinado dia, o sintoma é o mesmo: um login interativo não é uma credencial durável para um trabalho em segundo plano.

A Anthropic documenta a resposta, e é uma boa:

Para pipelines CI, scripts ou outros ambientes onde o login interativo do navegador não está disponível, gere um token OAuth de um ano com claude setup-token.

Documentos do Claude Code, Autenticação

Então eu executei, coloquei o token no arquivo env que o trabalho já utiliza, e segui em frente:

# wrapper agendado — a versão que "corrigiu"
set -a                          # o arquivo env é apenas KEY=val sem `export`,
source "$HOME/.agent/.env"      # então allexport é o que faz o filho herdá-lo
set +a

claude --print --permission-mode bypassPermissions --model "$MODEL" "$PROMPT"

Esse arquivo env contém cerca de vinte chaves — credenciais de análise, alguns tokens de API, e agora o token do Claude. Uma linha, uma variável, resolvido. O trabalho rodou sem erros na manhã seguinte e todas as manhãs depois disso.

Diagnóstico: a execução não estava falhando, estava meio cega

Quatro dias depois, percebi que os standups tinham parado de mencionar e-mail. Não "falhou ao ler e-mail" — apenas nada, como se a semana tivesse sido tranquila. O resumo do agente sobre o que ele verificou listou o repositório e nada mais, e eu passei por isso quatro vezes.

Seis execuções consecutivas do agente diário: a execução que falhou completamente foi notada na mesma manhã, enquanto as quatro execuções após a adição do token OAuth todas saíram 0 e escreveram seu artefato com os conectores de e-mail e calendário ausentes, e passaram despercebidas por quatro dias.

A verificação levou trinta segundos uma vez que pensei em executá-la:

$ claude mcp list
claude.ai Gmail              ✓ Conectado
claude.ai Google Calendar    ✓ Conectado
claude.ai Google Drive       ✓ Conectado
signalk                      ✓ Conectado

$ CLAUDE_CODE_OAUTH_TOKEN=sk-ant-oat01-… claude mcp list
signalk                      ✓ Conectado

Mesma máquina, mesmo segundo, mesma configuração. A única diferença é uma variável de ambiente, e três servidores desaparecem. Não "falhou", não "precisa de autenticação" — ausente.

Por que: conectores dependem da sessão da conta, e o token tem prioridade sobre ela

Duas coisas nos documentos explicam isso completamente, e eu não li nenhuma, porque eu estava resolvendo um problema do launchd e isso está arquivado sob autenticação e MCP.

Uma. Um setup-token é deliberadamente restrito:

Esse token autentica com sua assinatura Claude e requer um plano Pro, Max, Team ou Enterprise. Ele só pode fazer solicitações de modelo, então não pode estabelecer sessões de Controle Remoto ou buscar conectores claude.ai. Servidores MCP que você configura localmente ainda funcionam.

Autenticação § Gerar um token de longa duração (ênfase minha)

Dois. A página do MCP detalha a lista de exclusão,

Contexto Triplo Up

Empresas brasileiras que utilizam automação com IA podem enfrentar problemas de autenticação ao usar tokens de configuração. É crucial entender como esses tokens afetam a integração com serviços como Gmail e Google Calendar.

Noticias relacionadas

Gostou do conteudo?

Receba toda semana as principais novidades sobre WebMCP.