Configuration du runtime

Anda stocke l'état du runtime dans ~/.anda par défaut. Le fichier de configuration principal est ~/.anda/config.yaml, créé automatiquement lors du premier lancement. La configuration facultative du serveur MCP se trouve dans ~/.anda/mcp.json.

Fournisseurs de modèles

Le fournisseur actif doit inclure family, model et api_base. La clé api_key peut être écrite dans le fichier de configuration ou laissée vide et fournie via une variable d'environnement.

model:
  active: "deepseek-v4-pro"
  providers:
    - family: anthropic
      model: "deepseek-v4-pro"
      api_base: "https://api.deepseek.com/anthropic"
      api_key: "VOTRE_CLE_API"
      labels: ["pro", "brain"]
      disabled: false

Les variables d'environnement de clé API de modèle prises en charge sont :

OPENAI_API_KEY
ANTHROPIC_API_KEY
GEMINI_API_KEY
GOOGLE_API_KEY
DEEPSEEK_API_KEY
MINIMAX_API_KEY
MIMO_API_KEY
MOONSHOT_API_KEY
KIMI_API_KEY
BIGMODEL_API_KEY
GLM_API_KEY

Paramètres communs de niveau supérieur

Paramètre	Objectif
addr	Adresse de la passerelle locale, par défaut 127.0.0.1:8042.
sandbox	Si activé (true), l'exécution du shell se fait via ~/.anda/sandbox.
https_proxy	Proxy utilisé pour les requêtes de modèles et de canaux.
model	Fournisseurs de modèles pour l'agent et le cerveau de mémoire.
transcription	Fournisseur pour la transcription de la saisie vocale et des fichiers audio joints.
tts	Fournisseur pour la synthèse vocale.
channels	Configuration de Telegram, WeChat, Discord, Lark/Feishu et autres canaux.

Serveurs MCP

Anda Bot peut se connecter à des serveurs MCP via des processus enfants stdio ou des points de terminaison HTTP. Placez une configuration MCP portable dans ~/.anda/mcp.json, puis exécutez anda mcp reload (ou redémarrez le démon). Le fichier accepte à la fois mcpServers et servers comme clé racine, afin de vous permettre de coller des configurations provenant d'autres outils compatibles avec MCP avec un minimum de modifications.

{
  "mcpServers": {
    "filesystem": {
      "type": "stdio",
      "command": "npx",
      "args": ["-y", "@modelcontextprotocol/server-filesystem", "$ANDA_WORKSPACE"]
    },
    "remote": {
      "type": "http",
      "url": "https://mcp.example.com/mcp",
      "headers": {
        "Authorization": "Bearer ${secret:MCP_REMOTE_TOKEN}"
      }
    }
  }
}

Les outils MCP distants apparaissent comme des outils Anda nommés sous la forme mcp_<server_id>_<remote_tool>. Les chaînes de configuration prennent en charge l'expansion des variables d'environnement $VAR et ${VAR}, avec ${VAR:-default} pour une variable qui peut ne pas être définie, et ${secret:NAME} pour un secret (voir la section « Secrets » plus bas). ANDA_HOME et ANDA_WORKSPACE sont intégrées. Pour les serveurs stdio, le paramètre command est lancé directement sans shell ; lorsque cwd est omis, le premier espace de travail Anda est utilisé. Si type est omis, Anda infère stdio à partir du paramètre command ou http à partir de l'URL.

Chaque entrée est chargée séparément et MCP n'empêche jamais le daemon de démarrer : une entrée inutilisable (une variable d'environnement non définie, un type non pris en charge comme sse, désormais obsolète, un identifiant en double) est ignorée avec un avertissement dans le journal du daemon, et les autres serveurs se chargent normalement. Les serveurs se connectent en arrière-plan une fois le daemon démarré : un point de terminaison lent ou un premier téléchargement npx -y ne le retarde pas ; ajoutez "startup": "eager" à une entrée pour découvrir ses outils avant que le daemon ne se déclare prêt. Les serveurs stdio reçoivent le même PATH étendu que l'outil shell, de sorte que npx, uvx et les commandes Homebrew sont trouvés même lorsque le daemon tourne comme service de session ; ce service ne voit pas les variables exportées dans le profil de votre shell, donc les références ${VAR} exigent que la variable soit présente dans l'environnement du daemon lui-même.

Une entrée peut aussi régler la façon dont son serveur s'exécute. timeouts est en secondes, chacun entre 1 et 86400 : setup_secs pour se connecter (90 par défaut), list_secs pour lister les outils (30), request_secs pour une requête (180) et call_secs pour un appel complet (600). concurrency décide quels outils peuvent s'exécuter en même temps : serial (par défaut), read_only_parallel (ceux que le serveur marque en lecture seule) ou parallel. limits.output_text_bytes est le texte que l'agent reçoit d'un résultat, entre 256 et 1048576 (32768 par défaut). lifecycle décide comment la révision du protocole est négociée (auto, discover ou initialize), et tasks ({"max_wait_secs": 900}) permet à un outil long de renvoyer une tâche qu'Anda interroge jusqu'à son achèvement. Un serveur local reçoit tout l'environnement du démon, sauf avec "inherit_env": false, qui ne lui donne que l'essentiel de la plateforme (PATH, HOME, TMPDIR et autres) et son propre env : aucun autre secret de l'environnement du démon ne lui parvient. resources et elicitation sont activés sauf s'ils valent false : ils décident si l'agent et les applications peuvent lister et lire les ressources du serveur, et si le serveur peut vous demander une saisie pendant qu'un de ses outils s'exécute ; timeouts.elicitation_secs (300) est le temps qu'il attend votre réponse. C'est vous qui modifiez ces réglages, dans mcp.json, sur la page MCP ou avec anda mcp options, pas les outils de l'agent.

L'agent peut également ajouter un serveur au runtime à l'aide de add_mcp_server. Définissez persist: false pour le démon actuel uniquement, ou persist: true pour enregistrer le serveur dans ~/.anda/mcp.json pour les redémarrages futurs. Ses champs de serveur correspondent à une entrée de mcp.json : type, command, args, env, cwd, url, headers, enabled, include et exclude, ainsi que les champs exclusifs aux outils id et persist. manage_mcp_server permet à l'agent de lister les serveurs avec leur état et leur dernière erreur, et d'en reconnecter un ; activer, désactiver, supprimer un serveur ou s'en déconnecter demande d'abord votre approbation.

Gérer les serveurs avec anda mcp

anda mcp list                                         # état, outils et dernière erreur de chaque serveur
anda mcp get github                                   # un serveur et ses outils
anda mcp add context7 -- npx -y @upstash/context7-mcp
anda mcp add docs --url https://docs.example.com/mcp --header 'Authorization: Bearer ${DOCS_TOKEN}'
anda mcp add-json notes '{"type":"http","url":"https://notes.example.com/mcp"}'
anda mcp login linear --url https://mcp.linear.app/mcp  # connexion OAuth ; --no-browser affiche l'URL
anda mcp tool github delete_repository --hide         # masquer un outil à l'agent
anda mcp secret set DOCS_TOKEN                        # aussi : secret list, secret unset
anda mcp disable context7                             # aussi : enable, remove, reconnect, logout, reload
anda mcp options github --call-timeout 900            # réglages avancés ; `default` en efface un
anda mcp import --dry-run                             # serveurs configurés dans d'autres applications
anda mcp import github notes=work-notes --from cursor # les importer ; sans nom, tous les nouveaux
anda mcp events github                                # les événements qu'un serveur signale
anda mcp triggers                                     # automatisations sur événements ; aussi : add, get, update, pause, resume, delete

Quand le démon tourne, chaque commande passe par lui et la modification s'applique aussitôt : un serveur dont les paramètres de connexion ont changé redémarre, et celui dont la modification ne touche pas la connexion (un champ qu'Anda ne lit pas, par exemple) continue de tourner. Les serveurs en échec sont relancés en arrière-plan, avec un délai qui passe de 30 secondes à 30 minutes, et la raison est conservée pour list. Sans le démon, add, add-json, remove, enable, disable, tool, approval, external-users, secret, options, import et logout modifient directement les fichiers et prennent effet au démarrage du démon. list affiche aussi les entrées ignorées et pourquoi, et --json imprime tout résultat en JSON. Les modifications conservent les champs qu'Anda ne lit pas, vos références ${VAR} et la clé racine du fichier ; remove supprime aussi la connexion enregistrée du serveur, sauf avec --keep-credentials. Anda ne surveille pas mcp.json : après une modification manuelle, exécutez anda mcp reload. L'origine de chaque serveur, sa dernière erreur, les définitions d'outils et les instructions que vous avez revues et le nombre d'appels de ses outils sont conservés dans ~/.anda/mcp_state.json.

La page MCP

Anda Desktop (MCP dans la barre latérale) et le tableau de bord de l'extension (#mcp) gèrent les mêmes serveurs. La page liste chaque serveur avec son état et affiche sa dernière erreur, son utilisation et ses instructions ; ses outils, avec la politique d'approbation de chacun, les indications du serveur et ce qui a changé depuis votre vérification ; la connexion ; les secrets qu'il utilise ; et son entrée, secrets masqués. Ajouter accepte une URL avec des en-têtes, une commande avec des variables d'environnement, ou une configuration collée depuis une autre application. La ligne de commande complète s'affiche avant toute exécution, la connexion est testée et, par défaut, les valeurs des en-têtes, les jetons et les clés sont stockés comme secrets : mcp.json ne garde que des références ${secret:...}. Un serveur qui demande OAuth ouvre sa page de connexion dans votre navigateur.

Le menu Ajouter importe aussi des serveurs depuis d'autres applications et parcourt le MCP Registry (voir plus bas), et l'onglet Configuration modifie les réglages avancés.

Dans Anda Desktop, un lien de la forme anda://mcp/install?name=<id>&config=<base64url JSON> ouvre la boîte Ajouter avec cette configuration et un avertissement invitant à vérifier ce qu'elle exécute. Rien n'est enregistré avant que vous l'ajoutiez, et un lien ne peut pas modifier un serveur existant.

Importer depuis d'autres applications

anda mcp import et Importer depuis d'autres applications sur la page MCP lisent la configuration MCP de Claude Desktop, Claude Code (~/.claude.json), Cursor, VS Code (et la CLI de GitHub Copilot, ~/.copilot/mcp-config.json), Windsurf et Codex (~/.codex/config.toml), ainsi que les fichiers de projet (.mcp.json, .cursor/mcp.json, .vscode/mcp.json) des projets que Claude Code connaît et du répertoire courant (pour la CLI) ou de l'espace de travail du démon. Ces fichiers sont seulement lus, jamais modifiés.

anda mcp import --dry-run                    # ce que deviendrait chaque serveur
anda mcp import                              # tous les serveurs nouveaux pour Anda
anda mcp import github notes=work-notes      # ceux nommés ; NAME=ID renomme
anda mcp import --from cursor --keep-plaintext

Chaque serveur est affiché avec ce que ferait son import : nouveau ; renommé quand un autre serveur porte déjà son nom ; déjà dans Anda ; le même serveur qu'un autre listé plus haut ; ou impossible à importer (un serveur SSE, par exemple) avec la raison. À l'import, l'entrée est traduite dans le format d'Anda : ${env:NAME}, ${userHome} et ${workspaceFolder} de VS Code sont remplis, et le serverUrl de Windsurf, les listes d'outils de Copilot et les tables de Codex sont lus. Les valeurs des en-têtes, les jetons et les clés passent en secrets, sauf avec --keep-plaintext. Un ${input:...} de VS Code et une variable d'environnement absente de l'environnement du démon deviennent des secrets à renseigner : la CLI et la page les demandent, et un serveur dont le secret n'est pas encore renseigné l'attend. Les serveurs locaux importés reçoivent "inherit_env": false. Ce qui n'est pas repris, comme un envFile ou une liste d'outils approuvés automatiquement, est indiqué avec le serveur.

Le MCP Registry

Parcourir le MCP Registry, sur la page MCP, cherche dans le MCP Registry officiel. La requête est faite par le démon, avec ses propres réglages de proxy. Un serveur publié avec un point d'accès distant s'installe par défaut sous cette forme, car il n'exécute rien sur votre ordinateur ; vous pouvez choisir à la place l'un de ses paquets npm, PyPI, OCI (Docker) ou NuGet, qui s'exécute comme commande locale avec "inherit_env": false. Le formulaire d'installation demande les variables d'URL, en-têtes, variables d'environnement et arguments que le serveur déclare ; une valeur marquée secrète va dans le coffre de secrets. Vous pouvez tester le serveur avant de l'installer. Le Registry indique seulement qu'un serveur a été publié, pas qu'il est sûr : ses outils demandent toujours avant de s'exécuter tant que vous ne les autorisez pas.

Secrets

${secret:NAME} dans un en-tête, une valeur d'environnement, un argument ou une URL se développe en un secret stocké dans ~/.anda/mcp_secrets.json, que seul votre utilisateur peut lire : mcp.json ne contient aucun jeton et peut être partagé ou sauvegardé tel quel. Les noms utilisent des lettres, des chiffres et _, et un secret peut servir à plusieurs serveurs.

anda mcp secret set GITHUB_PAT              # lit la valeur sans l'afficher
gh auth token | anda mcp secret set GITHUB_PAT
anda mcp secret list                        # noms, s'ils sont définis et les serveurs qui les utilisent
anda mcp secret unset GITHUB_PAT

Ni la CLI, ni la page MCP, ni l'API ne réaffichent une valeur : pour la changer, définissez-en une nouvelle. Un serveur dont le secret n'est pas défini est ignoré, avec un diagnostic qui nomme le secret, et démarre dès que vous le définissez ; une nouvelle valeur redémarre les serveurs qui l'utilisent. Supprimer un serveur supprime aussi les secrets qu'il était seul à utiliser, sauf avec --keep-credentials.

Approuver les appels d'outils MCP

Chaque appel de l'agent à un outil MCP passe par une vérification d'approbation, comme les commandes shell. C'est la politique approval du serveur qui décide, pour tous ses outils ou pour un seul :

Politique	Quand l'agent demande d'abord
auto (par défaut)	Sauf si la session dispose de l'accès complet. Les outils que le serveur marque en lecture seule s'exécutent sans demander tant que leur définition n'a pas changé.
ask	Toujours, même avec l'accès complet.
allow	Jamais, tant que la définition de l'outil n'a pas changé.

"github": {
  "type": "http",
  "url": "https://api.githubcopilot.com/mcp/",
  "approval": { "default": "allow", "tools": { "merge_pull_request": "ask" } }
}

anda mcp approval github allow                              # tous les outils du serveur
anda mcp approval github ask --tool merge_pull_request      # un seul outil
anda mcp approval github inherit --tool merge_pull_request  # revient à la politique du serveur

La politique n'est lue qu'à l'appel d'un outil : la modifier ne reconnecte jamais le serveur. Les tâches planifiées et les objectifs s'exécutent avec l'accès complet, donc les outils auto s'y exécutent aussi. Là où personne ne peut répondre à une approbation, comme une conversation IM ou une tâche planifiée qui rencontre un outil ask, l'appel n'est pas fait et l'agent apprend comment vous pouvez l'autoriser.

La carte d'approbation d'un outil MCP propose aussi Toujours autoriser (la touche a dans la TUI) : elle approuve l'appel et règle cet outil sur allow.

Anda conserve la définition de chaque outil telle que le serveur l'a fournie la première fois. Si le serveur modifie ensuite la description ou le schéma d'un outil, ou en ajoute un, cet outil perd ce qui avait été accordé à son ancienne définition : l'agent demande avant de l'appeler, même avec allow, jusqu'à ce que vous approuviez un de ses appels ou que vous l'acceptiez avec anda mcp review github (tous les outils) ou anda mcp review github <tool>. anda mcp diff github <tool> montre ce qui a changé, et anda mcp get github signale les outils à revoir. Les instructions qu'un serveur donne au modèle sont conservées de la même façon : quand elles changent, anda mcp get le signale et la page MCP montre les deux versions, jusqu'à ce que anda mcp review github les accepte.

Les requêtes des utilisateurs IM externes ne peuvent appeler les outils d'un serveur que s'il les y autorise ("allow_external_users": true, ou anda mcp external-users github on), et jamais un outil qui exigerait une approbation : un utilisateur externe ne peut pas approuver à votre place.

Les skills écrites pour d'autres agents peuvent nommer des outils MCP sous la forme mcp__<server>__<tool>, et Anda résout ces noms vers les mêmes outils. Un joker comme mcp__github__* n'est pas résolu : listez chaque outil.

Automatisations sur événements

Les serveurs qui prennent en charge l'extension MCP Events signalent des événements, comme une nouvelle issue ou un nouveau commentaire. Une automatisation lance l'agent avec vos instructions quand l'un d'eux arrive. Créez-la dans l'onglet Événements d'un serveur sur la page MCP, avec anda mcp triggers add, ou en le demandant à l'agent, dont le create_event_trigger demande d'abord votre approbation :

anda mcp events github                         # types d'événements, mode de livraison et arguments
anda mcp triggers add github issue.opened --args '{"repo":"owner/name"}' \
    --instructions "Étiquette chaque nouvelle issue et résume-la" --batch-window 60
anda mcp triggers get 3                        # son état, ses dernières exécutions et ses événements
anda mcp triggers update 3 --instructions "Étiquetez-la et assignez-la"  # ce que vous omettez reste
anda mcp triggers pause 3                      # aussi : resume, delete

• Où vont les résultats. Une automatisation créée sur la page MCP ou avec la CLI répond dans une de vos conversations, que les exécutions suivantes poursuivent ; une automatisation créée par l'agent répond là où on le lui a demandé, dans cette conversation ou ce chat IM.
• Regroupement et limites. Les événements arrivés pendant la fenêtre de regroupement (30 secondes par défaut, jusqu'à une heure) sont traités en une exécution de 20 événements au plus. Une automatisation se met en pause d'elle-même lorsqu'elle dépasserait sa limite horaire (max_runs_per_hour, 12 par défaut), ce qui coupe aussi une boucle de rétroaction, comme répondre à une issue et recevoir ce commentaire comme nouvel événement, ainsi qu'après cinq échecs consécutifs. Reprenez-la quand vous êtes prêt.
• Confiance. Les données d'événement viennent du serveur et ne sont pas fiables : les exécutions les présentent au modèle comme des données, non comme des instructions, et ne les enregistrent pas comme les vôtres. Ces exécutions n'ont pas l'accès complet des tâches planifiées : elles peuvent appeler les outils en lecture seule et ceux réglés sur allow, et tout ce qui demande une approbation (un outil d'écriture en auto, une commande shell risquée) est refusé.
• Modifications et avis. Modifiez une automatisation dans l'onglet Événements ou avec anda mcp triggers update ; changer son événement, ses arguments ou sa livraison la réabonne à partir de maintenant. La boîte de dialogue nomme aussi les outils du serveur qui lui seraient refusés. Quand une automatisation se met en pause d'elle-même, que son serveur demande une connexion ou que le serveur y met fin, Anda vous prévient d'un court message là où vont ses réponses.
• Mémoire. Ce qu'apporte une exécution est attribué au serveur et à l'événement (mcp:<server>/<event>) comme source externe, à la manière des propos d'un expéditeur IM externe : Formation ne l'enregistre jamais comme venant de vous.
• Livraison. Anda garde un flux push ouvert, ou interroge le serveur, selon ce que permet le type d'événement, et conserve la position atteinte : les événements arrivés pendant l'arrêt du daemon sont rejoués si le serveur le permet, et un événement déjà vu n'est pas exécuté deux fois. Quand le serveur signale des événements perdus, l'automatisation l'indique. Une automatisation dont le serveur est désactivé, supprimé ou en échec attend ; si le serveur demande une connexion, elle l'indique ; les deux reprennent quand le serveur revient.
• Webhooks via dMsg. Certains serveurs ne livrent leurs événements que par webhook, et Anda n'écoute sur aucun port public. Marquez l'entrée de dMsg avec "events": {"webhook_ingress": true} : pour chaque automatisation de ce type, Anda y crée un endpoint, y abonne le serveur et renouvelle l'abonnement avant son expiration, et dMsg relaie les livraisons qu'il a vérifiées. Sans récepteur, l'automatisation attend dans l'état needs_ingress.

{
  "mcpServers": {
    "dmsg": { "command": "dmsg", "args": ["mcp"], "events": { "webhook_ingress": true } }
  }
}

Les automatisations, les événements reçus et leurs exécutions sont conservés dans la base de données du daemon ; le secret de signature d'un endpoint est conservé dans le magasin de secrets MCP.

Ressources et demandes de saisie

Les serveurs peuvent proposer des ressources : fichiers, enregistrements et autre contexte par URI. L'agent les liste et les lit avec mcp_resources (list, sans serveur pour tous ceux qui sont connectés ; templates pour les modèles d'URI à compléter ; et read) ; un texte court revient tel quel, un contenu long ou binaire en pièce jointe. Dans Anda Desktop et l'extension, le menu + de la zone de message propose Ressource MCP, qui liste les ressources des serveurs connectés et joint à votre message celle que vous choisissez. Une lecture ne modifie rien : elle suit donc la politique d'approbation du serveur comme un outil en lecture seule déjà examiné. Elle s'exécute sans demander, sauf si le serveur est réglé sur ask ou si la session demande une approbation pour tout, et les utilisateurs IM externes n'atteignent que les serveurs qui les autorisent. Ce que renvoie un serveur n'est pas fiable, comme le résultat d'un outil.

Un serveur peut aussi vous demander une saisie pendant qu'un de ses outils s'exécute (MCP elicitation). Anda affiche la demande au-dessus de la zone de message de la conversation pour laquelle l'appel est fait : un formulaire devient une carte par champ, qui vérifie votre réponse (un nombre dans la plage, une adresse e-mail, l'une des options), et une demande d'ouvrir une page devient une carte avec le lien, qui s'ouvre quand vous choisissez Open the page. Decline indique au serveur que vous ne répondrez pas ; écrire dans le chat à la place, ou laisser passer le délai du serveur (timeouts.elicitation_secs, 300 secondes par défaut), annule la demande. Là où personne ne peut répondre, comme une automatisation, une tâche planifiée ou un chat IM, la demande est annulée aussitôt. La réponse va au serveur : ne saisissez jamais de mot de passe, de clé ni de données de paiement dans une telle carte.

Les deux sont activés par défaut. Mettez "resources": false ou "elicitation": false dans une entrée, ou lancez anda mcp options <id> --resources off (ou --elicitation off), pour en désactiver un.

Structure des répertoires locaux

~/.anda/
  config.yaml
  mcp.json
  mcp_secrets.json
  mcp_state.json
  anda-daemon.pid
  channels/
  credentials/ # stockage local d'informations d'identification chiffrées des utilisateurs de confiance
  db/
  keys/ # clés de fichiers explicites ou clés de secours (Secret Service)
  logs/
  bundled-skills/
  sandbox/
  skills/
  skills-manifest.json
  skill-backups/
  skill-trash/
  workspace/

Répertoire	Contenu
credentials/	Stockage local d'informations d'identification chiffrées. Les clés privées des utilisateurs de confiance y sont stockées sous forme de clés COSE chiffrées.
db/	Mémoire locale, conversations, état des canaux, état des tâches planifiées (cron), état des objets et données associées.
keys/	Fichiers de clés de signature exportés explicitement ou de secours pour Linux Secret Service. Les clés privées d'identité du démon et du propriétaire sont stockées par défaut dans le stockage d'informations d'identification sécurisé du système d'exploitation lorsqu'il est disponible.
logs/	Journaux du démon et de la CLI.
channels/	État du runtime des canaux.
bundled-skills/	Compétences intégrées gérées par les versions et installées via les mises à jour d'Anda.
sandbox/	Répertoire d'isolement du shell lorsque le bac à sable (sandboxing) est activé.
skills/	Compétences de runtime personnelles créées, clonées ou modifiées par l'utilisateur.
skills-manifest.json	Compétences désactivées dans le tableau de bord. Un fichier illisible est signalé et laissé tel quel, sans être réinitialisé.
skill-backups/	Copies horodatées du SKILL.md d'une compétence personnelle, faites avant chaque mise à jour.
skill-trash/	Compétences personnelles supprimées, déplacées ici avant retrait définitif.
workspace/	Espace de travail par défaut pour les outils de shell et de fichiers.

Limites de confidentialité

Les données d'état locales d'Anda, le graphe de mémoire, les conversations, l'état des canaux, l'état des tâches planifiées, les journaux et les données de l'espace de travail sont stockés par défaut sur votre machine. Les clés privées d'identité du démon et du propriétaire sont stockées par défaut dans le stockage d'informations d'identification sécurisé du système d'exploitation, tandis que les clés privées des utilisateurs de confiance sont stockées dans le stockage local d'informations d'identification chiffrées sous ~/.anda/credentials/. Des fichiers de clés explicites et des clés de secours Linux Secret Service peuvent exister sous ~/.anda/keys/.

Sous Linux, si aucun fournisseur de Secret Service n'est disponible ou déverrouillé, Anda utilise par défaut les fichiers de clé privée de démon/propriétaire sous ~/.anda/keys/ et affiche/enregistre un avertissement. Les clés privées des utilisateurs de confiance restent chiffrées dans le stockage local d'informations d'identification tant que le secret d'identité du démon peut être chargé. Pour utiliser le Secret Service pour les identités de démon/propriétaire, démarrez et déverrouillez un fournisseur dans une session D-Bus utilisateur (par exemple, gnome-keyring-daemon --start --components=secrets), assurez-vous que DBUS_SESSION_BUS_ADDRESS est défini pour le processus Anda, puis redémarrez Anda. Les utilisateurs de KDE peuvent déverrouiller KWallet à la place.

Cependant, les fournisseurs de modèles peuvent toujours recevoir des prompts, des résumés de résultats d'outils et des requêtes de formation ou de rappel de mémoire. Choisissez des fournisseurs de confiance, des points de terminaison privés ou des politiques de proxy en fonction de vos exigences de confidentialité.

astuce

Utilisez anda --home /chemin/vers/.anda lorsque vous avez besoin de données isolées pour différentes identités, projets ou tests.

Brain runtime

Définissez brain.runtime_config vers un fichier JSON/YAML de confiance, relatif au dossier de configuration ; BRAIN_RUNTIME_CONFIG est prioritaire. Redémarrez pour installer les liaisons avant le chargement du Space. La boîte Brain du navigateur et /brain inbox, /brain status, /brain formation <id> dans le terminal conservent l’identité authentifiée. La lecture n’autorise aucune exécution ; réessayez une réponse avec le même événement et texte. Un reçu Recall prouve seulement la livraison ; accepter Formation ne signifie pas le terminer. La fonctionnalité learning est indépendante de mib ; sémantique, utility, trust et apprentissage automatique exigent une configuration native explicite. Les transports IM actuels ne sont pas des adaptateurs d’action automatique. Le mode MIB persistent ne garantit ni apprentissage normal/ungated ni coûts complets.

brain:
  runtime_config: null

Vous pouvez aussi connecter un forfait ChatGPT Plus / Pro éligible sans clé API :

anda auth login chatgpt
anda auth accounts
anda auth models <profile-id>
anda auth use <profile-id> <model-slug>
anda auth logout <profile-id>

Dans Anda Desktop, ouvrez Paramètres → Configuration de l’agent → Modèles. Dans l’extension, ouvrez Modèles sur la page de configuration ou la section des modèles dans les paramètres du panneau latéral. Cliquez sur Continue with ChatGPT, autorisez l’accès dans le navigateur, puis choisissez Utiliser ce modèle. Dans la TUI, appuyez sur Ctrl+G. La CLI/TUI choisit le premier modèle disponible ; la CLI accepte --model <slug>. Sans modèle configuré, le daemon expose uniquement des commandes de configuration authentifiées ; Brain, les canaux et cron démarrent après la sélection du modèle. Les trois clients partagent les comptes et le renouvellement sous le même ANDA_HOME. Les identifiants sont chiffrés dans chatgpt/accounts.cose, jamais stockés dans config.yaml ou dans le navigateur.

Attendez la fin des tâches et des sous-agents avant de changer de modèle du forfait. Les fournisseurs ChatGPT sont réservés au propriétaire local : lorsqu’ils sont activés, les demandes des autres utilisateurs et des expéditeurs externes de messagerie sont refusées. L’audio, la vidéo et la transcription nécessitent des fournisseurs distincts. Une limite d’utilisation ne déclenche jamais un basculement automatique vers une clé API payante. Consultez les paramètres d’utilisation ChatGPT. Les anciennes configurations .codex/auth.json restent compatibles, mais les nouvelles connexions doivent utiliser cette procédure.

Pour un hôte distant ou sans navigateur, utilisez anda auth login chatgpt --no-browser --port 1455 et transférez le port 127.0.0.1:1455 de la machine du navigateur vers l’hôte du daemon. Pour déplacer une session, lancez anda auth export <profile-id> --output /absolute/path/session.json (déconnecte la source), transférez le fichier par SSH avec les permissions 0600, puis lancez anda auth import /absolute/path/session.json sur la destination. L’import supprime le fichier transféré et conserve l’identifiant de l’hôte de destination. Activez un modèle avec anda auth use <profile-id> <model-slug>. Ne renouvelez jamais la même session sur les deux hôtes.