Gestionează cheile API
Acest ghid îți arată unde este stocat fiecare credențial folosit de Control Center și cum să îl schimbi.
Nimic nu este stocat pe mașina pe care tastezi. Fiecare credențial se află pe server; care dintre ele răspunde la o anumită cerere depinde de existența unui om în spatele ei.
| Credențial | Unde este stocat | Cine îl folosește |
|---|---|---|
| Credențialul tău de host de cod / tichete | Fișierul de secrete 0600 al serverului, indexat după id-ul tău de utilizator | Orice ceri tu: zona de PR-uri, rulările agenților tăi, imaginile tale |
| Identitatea de aplicație a serverului | Același fișier, plus server_settings pentru cele care nu sunt secrete |
Munca pe care nu a cerut-o niciun om: webhook-uri, interogarea periodică a PR-urilor, sincronizarea tichetelor |
| Chei de provideri de modele și tokenuri OAuth | Depozitul de credențiale al serverului | Adaptorul încorporat, pentru fiecare spațiu de lucru din instalare |
| Tokenuri de bot Slack | <dataDir>/<workspaceId>/chat_credentials/ pe server |
Puntea de chat pentru spațiul de lucru respectiv |
| Credențiale de CLI extern | Orice folosește CLI-ul respectiv | Claude Code, pe hostul serverului |
Două credențiale GitHub, care răspund la întrebări diferite
Secțiune intitulată „Două credențiale GitHub, care răspund la întrebări diferite”- Al tău, rezultat din autentificare (flux de dispozitiv) sau din lipirea unui token. Este cel pe care îl folosește fiecare cerere făcută în numele tău, așa că un comentariu publicat pentru tine îți poartă numele. Un alt membru nu îl poate citi și își conectează propriul credențial
- Al serverului, provenit din GitHub App pe care a înregistrat-o operatorul. Răspunde la tot ce nu are un apelant — astfel încât accesul la hostul de cod nu dispare când o persoană pleacă sau rotește un token
Al tău se setează în cardul Găzduire de cod din Setări → Spațiu de lucru → Profil și identitate; al serverului, în Aplicații provider din Setări → Server → Autentificare unică. Vezi Configurează integrarea GitHub și Creează GitHub App.
Setează cheile providerilor de modele
Secțiune intitulată „Setează cheile providerilor de modele”Adaptorul încorporat autentifică singur providerii, iar acele credențiale se află pe server.
- Mergi la Setări → Server → Provideri de modele
- Derulează până la Provideri și modele
- Conectează providerul — OAuth în browser pentru OpenAI, Codex, Cursor și Kimi Code; o cheie API pentru Anthropic și restul
Vezi Gestionează adaptoarele și modelele pentru lista completă și pentru adăugarea unui endpoint personalizat.
Aceste credențiale sunt globale la nivel de host: o singură cheie deservește fiecare spațiu de lucru din instalare. Tokenurile OAuth sunt reîmprospătate înainte de a expira.
CLI-urile adaptoarelor externe își păstrează propriile credențiale, în propria
configurație, pe hostul serverului — Control Center nu le gestionează. Autentifică
Claude Code așa cum prevede propria sa documentație, pe mașina pe care rulează
cc_server.
Dialogul Variabile de mediu al fiecărui adaptor pare un loc potrivit pentru a pune o cheie pentru unul dintre ele, dar nu este: scrie pe dispozitivul tău, în timp ce serverul citește propria copie și nimic nu le face legătura. Vezi Gestionează adaptoarele și modelele.
Conectează un furnizor de tichete
Secțiune intitulată „Conectează un furnizor de tichete”Cardul Ticketing din Setări → Spațiu de lucru → General conține ambele jumătăți ale unei singure decizii: la ce furnizor îți stau tichetele și credențialul pentru acesta. Alegerea Local ascunde rândul credențialului — tichetele locale se află în baza de date proprie a acestui server și nu au la ce să se autentifice.
Cheia ta este stocată pe server, asociată id-ului tău de utilizator, la fel ca cea de host de cod. Serverul își păstrează separat propria cheie Linear (Aplicații provider), pe care rulează sincronizarea tichetelor când nu a cerut niciun om. Nicio cheie de ticketing nu este injectată în sandbox-ul unui agent; agenții scriu tichete prin instrumentele Control Center, care întreabă regula Scrie într-un tracker extern. Vezi Configurează integrarea Linear.
Rotește sau revocă
Secțiune intitulată „Rotește sau revocă”- Credențialul tău GitHub: apasă Deconectează, apoi autentifică-te din nou sau lipește noul token. Revocă-l pe cel vechi pe GitHub
- Aplicația serverului: generează o cheie privată sau un client secret nou în pagina GitHub a aplicației, lipește-l în Aplicații provider și apasă Test
- Un provider de modele: pe rândul său, deconectează-te (OAuth) sau elimină cheia, apoi conectează-te din nou
- Slack: lipește din nou tokenurile în dialogul de conectare. Vezi Configurează integrarea Slack
Depanare
Secțiune intitulată „Depanare”Lista de PR-uri este goală, dar tokenul meu funcționează în curl
Secțiune intitulată „Lista de PR-uri este goală, dar tokenul meu funcționează în curl”Verifică subtitlul rândului Găzduire de cod. Dacă indică o altă sursă („prin aplicația acestui server”, „din mediu”), credențialul pe care îl testezi nu este cel care răspunde — al tău nu a fost salvat.
Tokenul este acceptat, dar cererile ulterioare eșuează
Secțiune intitulată „Tokenul este acceptat, dar cererile ulterioare eșuează”Tokenul este verificat așa cum este stocat, așa că rândul indică contul din spatele lui — dar numai contul, nu și scope-urile. Un token cu prea puține scope-uri se conectează, apoi eșuează la cereri individuale. Verifică scope-urile și expirarea:
curl -H "Authorization: token YOUR_TOKEN" https://api.github.com/user