Gerenciar chaves de API
Este guia mostra onde fica armazenada cada credencial usada pelo Control Center e como alterá-la.
Nada é armazenado na máquina em que você está digitando. Todas as credenciais ficam no servidor; qual delas responde a uma determinada requisição depende de haver uma pessoa por trás dela ou não.
| Credencial | Armazenada em | Quem a usa |
|---|---|---|
| Sua credencial de forge / tickets | O arquivo de segredos 0600 do servidor, indexado pelo seu id de usuário | Tudo o que você pede: a superfície de PR, as execuções dos seus agentes, suas imagens |
| A identidade de app do servidor | O mesmo arquivo, mais server_settings para o que não é segredo |
Trabalho que nenhuma pessoa pediu: webhooks, polling de PR, sincronização de tickets |
| Chaves de provedores de modelos e tokens OAuth | O armazenamento de credenciais do próprio servidor | O adaptador integrado, para todos os espaços de trabalho da instalação |
| Tokens de bot do Slack | <dataDir>/<workspaceId>/chat_credentials/ no servidor |
A ponte de chat daquele espaço de trabalho |
| Credenciais de CLIs externas | O que essa CLI usar | Claude Code, no host do servidor |
Duas credenciais do GitHub, e elas respondem a perguntas diferentes
Seção intitulada “Duas credenciais do GitHub, e elas respondem a perguntas diferentes”- A sua, obtida ao entrar (device flow) ou ao colar um token. É ela que todas as requisições feitas em seu nome usam, então um comentário publicado por você carrega o seu nome. Outro membro não consegue lê-la, e cada um conecta a sua
- A do servidor, obtida do GitHub App que o operador registrou. Ela responde a tudo o que não tem um solicitante — assim o acesso ao forge não desaparece quando alguém sai ou rotaciona um token
A sua é definida no cartão Hospedagem de código em Configurações → Espaço de trabalho → Perfil e identidade; a do servidor, em Apps do fornecedor, em Configurações → Servidor → Início de sessão único. Consulte Configurar a integração com o GitHub e Criar o GitHub App.
Definir chaves de provedores de modelos
Seção intitulada “Definir chaves de provedores de modelos”O adaptador integrado autentica os provedores por conta própria, e essas credenciais ficam no servidor.
- Acesse Configurações → Servidor → Provedores de modelos
- Role até Provedores e modelos
- Conecte o provedor — OAuth no navegador para OpenAI, Codex, Cursor e Kimi Code; uma chave de API para Anthropic e os demais
Consulte Gerenciar adaptadores e modelos para ver a lista completa e para adicionar um endpoint personalizado.
Essas credenciais são globais do host: uma única chave atende todos os espaços de trabalho da instalação. Os tokens OAuth são renovados antes de expirarem.
As CLIs de adaptadores externos mantêm as próprias credenciais, na própria
configuração, no host do servidor — o Control Center não as gerencia. Autentique
o Claude Code como a documentação dele orienta, na máquina em que o cc_server
roda.
A caixa de diálogo Variáveis de ambiente de cada adaptador parece um lugar para colocar a chave de um deles, mas não é: ela grava no seu dispositivo, enquanto o servidor lê a própria cópia e nada liga as duas. Consulte Gerenciar adaptadores e modelos.
Conectar um fornecedor de tickets
Seção intitulada “Conectar um fornecedor de tickets”O cartão Tickets em Configurações → Espaço de trabalho → Geral reúne as duas metades de uma mesma decisão: em qual fornecedor ficam seus tickets e a credencial para ele. Escolher Local oculta a linha da credencial — os tickets locais ficam no banco de dados do próprio servidor e não há nada a autenticar.
Sua chave é armazenada no servidor vinculada ao seu id de usuário, como a do forge. O servidor mantém a própria chave do Linear separadamente (Apps do fornecedor), e é nela que a sincronização de tickets roda quando nenhuma pessoa pediu. Nenhuma chave de tickets é injetada no sandbox de um agente; os agentes escrevem tickets pelas ferramentas do Control Center, que perguntam à regra Escrever em um rastreador externo. Consulte Configurar a integração com o Linear.
Rotacionar ou revogar
Seção intitulada “Rotacionar ou revogar”- Sua credencial do GitHub: clique em Desconectar e depois entre de novo ou cole o novo token. Revogue o antigo no GitHub
- O app do servidor: gere uma nova chave privada ou um novo client secret na página do app no GitHub, cole em Apps do fornecedor e clique em Testar
- Um provedor de modelos: na linha dele, saia (OAuth) ou remova a chave e conecte de novo
- Slack: cole os tokens novamente na caixa de diálogo de conexão. Consulte Configurar a integração com o Slack
Solução de problemas
Seção intitulada “Solução de problemas”A lista de PRs está vazia, mas meu token funciona no curl
Seção intitulada “A lista de PRs está vazia, mas meu token funciona no curl”Confira o subtítulo da linha Hospedagem de código. Se ele indicar outra origem (“pela app deste servidor”, “do ambiente”), a credencial que você está testando não é a que está respondendo — a sua não foi salva.
O token é aceito, mas as requisições seguintes falham
Seção intitulada “O token é aceito, mas as requisições seguintes falham”O token é verificado conforme está armazenado, então a linha mostra a conta por trás dele — mas apenas a conta, não os escopos. Um token com escopos de menos se conecta e depois falha em requisições individuais. Confira os escopos e a expiração:
curl -H "Authorization: token YOUR_TOKEN" https://api.github.com/user