Configuration de Qwen Code

Couches de configuration

La configuration est appliquée dans l’ordre de priorité suivant (les niveaux inférieurs sont remplacés par les niveaux supérieurs) :

Fichiers de paramètres

Qwen Code utilise des fichiers de paramètres au format JSON pour conserver les configurations de façon persistante. Ces fichiers peuvent être placés à quatre emplacements différents :

Le répertoire .qwen de votre projet

En plus du fichier de paramètres du projet, le répertoire .qwen d’un projet peut contenir d’autres fichiers spécifiques au projet liés au fonctionnement de Qwen Code, tels que :

• Profils de bac à sable personnalisés (par exemple .qwen/sandbox-macos-custom.sb, .qwen/sandbox.Dockerfile).
• Compétences d’agent sous .qwen/skills/ (chaque compétence est un répertoire contenant un fichier SKILL.md).

Migration de la configuration

Qwen Code migre automatiquement les anciens paramètres de configuration vers le nouveau format. Les anciens fichiers de paramètres sont sauvegardés avant la migration. Les paramètres suivants ont été renommés, passant d’une nomenclature négative (disable*) à une nomenclature positive (enable*) :

Politique de consolidation pour disableAutoUpdate et disableUpdateNag

Lorsque les deux paramètres hérités sont présents avec des valeurs différentes, la migration suit la règle suivante : si l’un ou l’autre de disableAutoUpdate ou disableUpdateNag est défini à true, alors enableAutoUpdate devient false :

Paramètres disponibles dans settings.json

Les paramètres sont organisés par catégories. Tous les paramètres doivent être placés dans l’objet de catégorie de premier niveau correspondant de votre fichier settings.json.

général

sortie

ui

ide

confidentialité

modèle

Exemple de model.generationConfig :

{
  "model": {
    "generationConfig": {
      "timeout": 60000,
      "contextWindowSize": 128000,
      "modalities": {
        "image": true
      },
      "enableCacheControl": true,
      "customHeaders": {
        "X-Client-Request-ID": "req-123"
      },
      "extra_body": {
        "enable_thinking": true
      },
      "samplingParams": {
        "temperature": 0.2,
        "top_p": 0.8,
        "max_tokens": 1024
      }
    }
  }
}

contextWindowSize :

Remplace la taille par défaut de la fenêtre contextuelle pour le modèle sélectionné. Qwen Code détermine la fenêtre contextuelle à partir de valeurs par défaut intégrées basées sur la correspondance du nom du modèle, avec une valeur constante par défaut. Utilisez ce paramètre lorsque la limite effective de contexte fournie par le fournisseur diffère de celle par défaut de Qwen Code. Cette valeur définit la capacité maximale supposée de contexte du modèle, et non une limite de jetons par requête.

modalities :

Remplace les modalités d’entrée détectées automatiquement pour le modèle sélectionné. Qwen Code détecte automatiquement les modalités prises en charge (image, PDF, audio, vidéo) selon une correspondance de motifs sur le nom du modèle. Utilisez ce paramètre lorsque la détection automatique est incorrecte — par exemple, pour activer pdf sur un modèle qui le prend en charge mais n’est pas reconnu. Format : { "image": true, "pdf": true, "audio": true, "video": true }. Omettez une clé ou définissez-la à false pour les types non pris en charge.

customHeaders :

Permet d’ajouter des en-têtes HTTP personnalisés à toutes les requêtes API. Cela est utile pour le traçage des requêtes, la surveillance, le routage via une passerelle API, ou lorsqu’un modèle nécessite des en-têtes spécifiques. Si customHeaders est défini dans modelProviders[].generationConfig.customHeaders, il sera utilisé directement ; sinon, les en-têtes provenant de model.generationConfig.customHeaders seront utilisés. Aucune fusion n’est effectuée entre ces deux niveaux.

Le champ extra_body permet d’ajouter des paramètres personnalisés au corps de la requête envoyé à l’API. Cela est utile pour les options spécifiques à un fournisseur non couvertes par les champs de configuration standard. Remarque : Ce champ n’est pris en charge que pour les fournisseurs compatibles OpenAI (openai, qwen-oauth). Il est ignoré pour les fournisseurs Anthropic et Gemini. Si extra_body est défini dans modelProviders[].generationConfig.extra_body, il sera utilisé directement ; sinon, les valeurs provenant de model.generationConfig.extra_body seront utilisées.

Exemples de model.openAILoggingDir :

• "~/qwen-logs" — Journalise dans le répertoire ~/qwen-logs
• "./custom-logs" — Journalise dans ./custom-logs, relatif au répertoire courant
• "/tmp/openai-logs" — Journalise dans le chemin absolu /tmp/openai-logs

contexte

Dépannage des performances de la recherche de fichiers

Si vous rencontrez des problèmes de performance lors de la recherche de fichiers (par exemple, avec les complétions @), notamment dans des projets comportant un très grand nombre de fichiers, voici quelques solutions à essayer, classées par ordre de recommandation :

1. Utilisez le fichier .qwenignore : Créez un fichier .qwenignore à la racine de votre projet pour exclure les répertoires contenant un grand nombre de fichiers que vous n’avez pas besoin de référencer (par exemple, les artefacts de compilation, les fichiers journaux ou le répertoire node_modules). Réduire le nombre total de fichiers explorés est la méthode la plus efficace pour améliorer les performances.
2. Désactivez la recherche floue : Si l’exclusion de fichiers ne suffit pas, vous pouvez désactiver la recherche floue en définissant enableFuzzySearch sur false dans votre fichier settings.json. Cela utilisera un algorithme de correspondance plus simple et non flou, généralement plus rapide.
3. Désactivez la recherche récursive de fichiers : En dernier recours, vous pouvez désactiver entièrement la recherche récursive de fichiers en définissant enableRecursiveFileSearch sur false. Il s’agit de l’option la plus rapide, car elle évite l’exploration récursive de votre projet. Toutefois, cela signifie que vous devrez saisir le chemin complet des fichiers lors de l’utilisation des complétions @.

Outils

mcp

lsp

[!warning] Fonctionnalité expérimentale : La prise en charge du protocole LSP est actuellement expérimentale et désactivée par défaut. Activez-la à l’aide de l’indicateur de ligne de commande --experimental-lsp.

Le protocole Language Server Protocol (LSP) fournit des fonctionnalités d’intelligence code telles que « aller à la définition », « rechercher les références » et les diagnostics.

La configuration du serveur LSP s’effectue via des fichiers .lsp.json situés dans le répertoire racine de votre projet, et non via le fichier settings.json. Consultez la documentation LSP pour obtenir des détails de configuration et des exemples.

sécurité

avancé

mcpServers

Configure les connexions à un ou plusieurs serveurs Model-Context Protocol (MCP) afin de découvrir et d’utiliser des outils personnalisés. Qwen Code tente de se connecter à chaque serveur MCP configuré pour découvrir les outils disponibles. Si plusieurs serveurs MCP exposent un outil portant le même nom, les noms des outils seront préfixés par l’alias du serveur que vous avez défini dans la configuration (par exemple, aliasServeur__nomOutilReel) afin d’éviter tout conflit. Notez que le système peut supprimer certaines propriétés de schéma des définitions d’outils MCP pour assurer la compatibilité. Au moins une des propriétés suivantes doit être fournie : command, url ou httpUrl. Si plusieurs sont spécifiées, l’ordre de priorité est le suivant : httpUrl, puis url, puis command.

Télémétrie

Configure la journalisation et la collecte de métriques pour Qwen Code. Pour plus d’informations, consultez Télémétrie.

Exemple de fichier settings.json

Voici un exemple de fichier settings.json avec la structure imbriquée, nouvelle depuis la version 0.3.0 :

{
  "general": {
    "vimMode": true,
    "preferredEditor": "code"
  },
  "ui": {
    "theme": "GitHub",
    "hideTips": false,
    "customWittyPhrases": [
      "Vous oubliez mille choses chaque jour. Assurez-vous que celle-ci en fait partie",
      "Connexion à l’AGI"
    ]
  },
  "tools": {
    "approvalMode": "yolo",
    "sandbox": "docker",
    "discoveryCommand": "bin/get_tools",
    "callCommand": "bin/call_tool",
    "exclude": ["write_file"]
  },
  "mcpServers": {
    "mainServer": {
      "command": "bin/mcp_server.py"
    },
    "anotherServer": {
      "command": "node",
      "args": ["mcp_server.js", "--verbose"]
    }
  },
  "telemetry": {
    "enabled": true,
    "target": "local",
    "otlpEndpoint": "http://localhost:4317",
    "logPrompts": true
  },
  "privacy": {
    "usageStatisticsEnabled": true
  },
  "model": {
    "name": "qwen3-coder-plus",
    "maxSessionTurns": 10,
    "enableOpenAILogging": false,
    "openAILoggingDir": "~/qwen-logs",
  },
  "context": {
    "fileName": ["CONTEXT.md", "QWEN.md"],
    "includeDirectories": ["path/to/dir1", "~/path/to/dir2", "../path/to/dir3"],
    "loadFromIncludeDirectories": true,
    "fileFiltering": {
      "respectGitIgnore": false
    }
  },
  "advanced": {
    "excludedEnvVars": ["DEBUG", "DEBUG_MODE", "NODE_ENV"]
  }
}

Historique du shell

L’interface en ligne de commande (CLI) conserve un historique des commandes que vous exécutez dans le shell. Afin d’éviter les conflits entre différents projets, cet historique est stocké dans un répertoire spécifique à chaque projet, situé dans le dossier personnel de l’utilisateur.

• Emplacement : ~/.qwen/tmp/<project_hash>/shell_history
  • <project_hash> est un identifiant unique généré à partir du chemin racine de votre projet.
  • L’historique est stocké dans un fichier nommé shell_history.

Variables d’environnement et fichiers .env

Les variables d’environnement constituent un moyen courant de configurer des applications, notamment pour les informations sensibles (telles que les jetons) ou pour les paramètres susceptibles de varier selon les environnements.

Qwen Code peut charger automatiquement les variables d’environnement à partir de fichiers .env.
Pour les variables liées à l’authentification (telles que OPENAI_*) et l’approche recommandée utilisant le fichier .qwen/.env, consultez Authentification.

Table des variables d’environnement

Arguments de ligne de commande

Les arguments passés directement lors de l’exécution de l’interface en ligne de commande (CLI) peuvent remplacer les autres configurations pour cette session spécifique.

Table des arguments en ligne de commande

Fichiers de contexte (contexte instructif hiérarchique)

Bien qu’ils ne constituent pas strictement une configuration du comportement de l’interface en ligne de commande (CLI), les fichiers de contexte (par défaut QWEN.md, mais configurables via le paramètre context.fileName) sont essentiels pour configurer le contexte instructif (également appelé « mémoire »). Cette fonctionnalité puissante vous permet de fournir au modèle des instructions spécifiques au projet, des guides de style de codage ou toute autre information contextuelle pertinente, afin d’obtenir des réponses plus adaptées et précises à vos besoins. La CLI intègre des éléments d’interface utilisateur, tels qu’un indicateur dans le pied de page affichant le nombre de fichiers de contexte chargés, pour vous tenir informé du contexte actif.

• Objectif : Ces fichiers Markdown contiennent des instructions, des directives ou des éléments de contexte que vous souhaitez voir pris en compte par le modèle Qwen pendant vos interactions. Le système est conçu pour gérer ce contexte instructif de manière hiérarchique.

Exemple de contenu de fichier de contexte (par exemple QWEN.md)

Voici un exemple conceptuel du contenu d’un fichier de contexte situé à la racine d’un projet TypeScript :

# Projet : Ma superbe bibliothèque TypeScript

## Instructions générales :
- Lors de la génération de nouveau code TypeScript, veuillez respecter le style de codage existant.
- Assurez-vous que toutes les nouvelles fonctions et classes sont accompagnées de commentaires JSDoc.
- Privilégiez les paradigmes de programmation fonctionnelle là où cela est pertinent.
- Tout le code doit être compatible avec TypeScript 5.0 et Node.js 20+.

## Style de codage :
- Utilisez deux espaces pour l’indentation.
- Les noms d’interfaces doivent être préfixés par `I` (par exemple, `IUserService`).
- Les membres privés des classes doivent être préfixés par un trait de soulignement (`_`).
- Utilisez systématiquement l’égalité stricte (`===` et `!==`).

## Composant spécifique : `src/api/client.ts`
- Ce fichier gère toutes les requêtes API sortantes.
- Lors de l’ajout de nouvelles fonctions d’appel API, assurez-vous qu’elles incluent une gestion d’erreurs robuste et une journalisation adéquate.
- Utilisez l’utilitaire existant `fetchWithRetry` pour toutes les requêtes GET.

À propos des dépendances :

• Évitez d’introduire de nouvelles dépendances externes, sauf si cela est absolument nécessaire.
• Si une nouvelle dépendance est requise, veuillez en indiquer la raison.

Cet exemple montre comment vous pouvez fournir un contexte général sur le projet, des conventions de codage spécifiques, voire des notes relatives à certains fichiers ou composants. Plus vos fichiers de contexte sont pertinents et précis, plus l’IA pourra vous aider efficacement. Il est fortement recommandé de créer des fichiers de contexte propres au projet afin d’établir clairement les conventions et le contexte applicables.

- **Chargement hiérarchique et priorité :** L’interface en ligne de commande (CLI) implémente un système de mémoire hiérarchique en chargeant des fichiers de contexte (par exemple `QWEN.md`) depuis plusieurs emplacements. Le contenu des fichiers figurant plus bas dans cette liste (plus spécifiques) remplace généralement ou complète celui des fichiers situés plus haut (plus généraux). L’ordre exact de concaténation et le contexte final peuvent être inspectés à l’aide de la commande `/memory show`. L’ordre de chargement habituel est le suivant :
  1. **Fichier de contexte global :**
     - Emplacement : `~/.qwen/<nom-du-fichier-de-contexte-configuré>` (par exemple `~/.qwen/QWEN.md` dans le répertoire personnel de l’utilisateur).
     - Portée : Fournit des instructions par défaut applicables à tous vos projets.
  2. **Fichiers de contexte à la racine du projet et dans ses répertoires parents :**
     - Emplacement : La CLI recherche le fichier de contexte configuré dans le répertoire de travail courant, puis dans chaque répertoire parent jusqu’à atteindre soit la racine du projet (identifiée par la présence d’un dossier `.git`), soit le répertoire personnel de l’utilisateur.
     - Portée : Fournit un contexte pertinent pour l’ensemble du projet ou pour une partie importante de celui-ci.
- **Concaténation et indication dans l’interface utilisateur :** Le contenu de tous les fichiers de contexte trouvés est concaténé (avec des séparateurs indiquant leur origine et leur chemin) et intégré au message système fourni à l’IA. Le pied de page de la CLI affiche le nombre de fichiers de contexte chargés, offrant ainsi un repère visuel rapide sur le contexte instructif actif.
- **Importation de contenu :** Vous pouvez modulariser vos fichiers de contexte en important d’autres fichiers Markdown à l’aide de la syntaxe `@chemin/vers/fichier.md`. Pour plus de détails, consultez la [documentation du processeur d’importation de mémoire](../configuration/memory).
- **Commandes de gestion de la mémoire :**
  - Utilisez `/memory refresh` pour forcer un nouveau balayage et un rechargement de tous les fichiers de contexte depuis tous les emplacements configurés. Cette commande met à jour le contexte instructif fourni à l’IA.
  - Utilisez `/memory show` pour afficher le contexte instructif combiné actuellement chargé, ce qui vous permet de vérifier la hiérarchie et le contenu utilisés par l’IA.
  - Consultez la [documentation des commandes](../features/commands) pour obtenir tous les détails sur la commande `/memory` et ses sous-commandes (`show` et `refresh`).

En comprenant et en exploitant ces couches de configuration ainsi que la nature hiérarchique des fichiers de contexte, vous pouvez gérer efficacement la mémoire de l’IA et adapter les réponses de Qwen Code à vos besoins et projets spécifiques.

## Sandbox

Qwen Code peut exécuter des opérations potentiellement dangereuses (comme des commandes shell ou des modifications de fichiers) au sein d’un environnement isolé (sandbox) afin de protéger votre système.

Le [sandbox](../features/sandbox) est désactivé par défaut, mais vous pouvez l’activer de plusieurs façons :

- À l’aide du drapeau `--sandbox` ou `-s`.
- En définissant la variable d’environnement `QWEN_SANDBOX`.
- Le sandbox est activé par défaut lorsque vous utilisez `--yolo` ou `--approval-mode=yolo`.

Par défaut, il utilise une image Docker préconstruite nommée `qwen-code-sandbox`.

Pour répondre à des besoins spécifiques de sandboxing liés à un projet, vous pouvez créer un fichier Dockerfile personnalisé à l’emplacement `.qwen/sandbox.Dockerfile` à la racine de votre projet. Ce Dockerfile peut être basé sur l’image de base du sandbox :

FROM qwen-code-sandbox

Ajoutez ici vos dépendances ou configurations personnalisées

Par exemple :

RUN apt-get update && apt-get install -y some-package

# COPIER ./my-config /app/my-config

Lorsque le fichier .qwen/sandbox.Dockerfile existe, vous pouvez utiliser la variable d’environnement BUILD_SANDBOX lors de l’exécution de Qwen Code afin de générer automatiquement l’image personnalisée du bac à sable :

BUILD_SANDBOX=1 qwen -s

Statistiques d’utilisation

Pour nous aider à améliorer Qwen Code, nous collectons des statistiques d’utilisation anonymisées. Ces données nous permettent de comprendre comment l’interface en ligne de commande (CLI) est utilisée, d’identifier les problèmes courants et de prioriser le développement de nouvelles fonctionnalités.

Ce que nous collectons :

• Appels d’outils : Nous enregistrons les noms des outils appelés, leur réussite ou leur échec, ainsi que leur temps d’exécution. Nous ne collectons ni les arguments transmis aux outils, ni les données qu’ils renvoient.
• Requêtes API : Nous enregistrons le modèle utilisé pour chaque requête, sa durée d’exécution et son succès ou son échec. Nous ne collectons ni le contenu des invites (prompts), ni celui des réponses.
• Informations sur la session : Nous collectons des informations relatives à la configuration de la CLI, telles que les outils activés et le mode d’approbation.

Ce que nous NE collectons PAS :

• Données à caractère personnel (PII) : Nous ne collectons aucune information personnelle, telle que votre nom, votre adresse e-mail ou vos clés API.
• Contenu des invites et des réponses : Nous n’enregistrons ni le contenu de vos invites, ni les réponses fournies par le modèle.
• Contenu des fichiers : Nous n’enregistrons pas le contenu des fichiers lus ou écrits par la CLI.

Comment désactiver la collecte :

Vous pouvez désactiver à tout moment la collecte de statistiques d’utilisation en définissant la propriété usageStatisticsEnabled sur false dans la catégorie privacy de votre fichier settings.json :

{
  "privacy": {
    "usageStatisticsEnabled": false
  }
}