Qwen Code Konfiguration

Konfigurationsebenen

Die Konfiguration wird in der folgenden Prioritätsreihenfolge angewendet (niedrigere Nummern werden von höheren Nummern überschrieben):

Einstellungsdateien

Qwen Code verwendet JSON-Einstellungsdateien für die persistente Konfiguration. Es gibt vier Speicherorte für diese Dateien:

Das .qwen-Verzeichnis in deinem Projekt

Zusätzlich zur Projekt-Einstellungsdatei kann das .qwen-Verzeichnis eines Projekts weitere projektspezifische Dateien enthalten, die sich auf den Betrieb von Qwen Code beziehen, wie z. B.:

• Benutzerdefinierte Sandbox-Profile (z. B. .qwen/sandbox-macos-custom.sb, .qwen/sandbox.Dockerfile).
• Agent Skills unter .qwen/skills/ (jeder Skill ist ein Verzeichnis, das eine SKILL.md enthält).

Konfigurationsmigration

Qwen Code migriert veraltete Konfigurationseinstellungen automatisch in das neue Format. Alte Einstellungsdateien werden vor der Migration gesichert. Die folgenden Einstellungen wurden von einer negativen (disable*) zu einer positiven (enable*) Benennung umbenannt:

Konsolidierungsrichtlinie für disableAutoUpdate und disableUpdateNag

Wenn beide veralteten Einstellungen mit unterschiedlichen Werten vorhanden sind, folgt die Migration dieser Richtlinie: Wenn entweder disableAutoUpdate oder disableUpdateNag auf true gesetzt ist, wird enableAutoUpdate auf false gesetzt:

Verfügbare Einstellungen in settings.json

Die Einstellungen sind in Kategorien organisiert. Alle Einstellungen sollten innerhalb ihres entsprechenden Top-Level-Kategorieobjekts in deiner settings.json-Datei platziert werden.

general

output

ui

ide

privacy

model

Beispiel für 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
      }
    }
  }
}

max_tokens (adaptive Ausgabe-Tokens):

Wenn samplingParams.max_tokens nicht gesetzt ist, verwendet Qwen Code eine adaptive Strategie für Ausgabe-Tokens, um die GPU-Ressourcennutzung zu optimieren:

1. Requests beginnen mit einem Standardlimit von 8K Ausgabe-Tokens
2. Wenn die Antwort abgeschnitten wird (das Modell erreicht das Limit), wiederholt Qwen Code den Vorgang automatisch mit 64K Tokens
3. Die teilweise Ausgabe wird verworfen und durch die vollständige Antwort aus dem Retry ersetzt

Dies geschieht transparent für Benutzer – du siehst möglicherweise kurz einen Retry-Indikator, wenn eine Eskalation erfolgt. Da 99 % der Antworten unter 5K Tokens liegen, tritt der Retry selten auf (<1 % der Requests).

Um dieses Verhalten zu überschreiben, setze entweder samplingParams.max_tokens in deinen Einstellungen oder verwende die Umgebungsvariable QWEN_CODE_MAX_OUTPUT_TOKENS.

contextWindowSize:

Überschreibt die standardmäßige Context-Window-Größe für das ausgewählte Modell. Qwen Code ermittelt die Context-Window-Größe anhand interner Standards basierend auf Modellnamens-Matching, mit einem konstanten Fallback-Wert. Verwende diese Einstellung, wenn das effektive Context-Limit eines Providers von Qwen Codes Standard abweicht. Dieser Wert definiert die angenommene maximale Context-Kapazität des Modells, nicht ein Token-Limit pro Request.

modalities:

Überschreibt die automatisch erkannten Eingabe-Modalitäten für das ausgewählte Modell. Qwen Code erkennt unterstützte Modalitäten (Bild, PDF, Audio, Video) automatisch basierend auf Modellnamens-Mustern. Verwende diese Einstellung, wenn die Auto-Erkennung fehlerhaft ist – z. B. um pdf für ein Modell zu aktivieren, das es unterstützt, aber nicht erkannt wird. Format: { "image": true, "pdf": true, "audio": true, "video": true }. Lasse einen Schlüssel weg oder setze ihn auf false für nicht unterstützte Typen.

customHeaders:

Ermöglicht das Hinzufügen benutzerdefinierter HTTP-Header zu allen API-Requests. Dies ist nützlich für Request-Tracing, Monitoring, API-Gateway-Routing oder wenn verschiedene Modelle unterschiedliche Header benötigen. Wenn customHeaders in modelProviders[].generationConfig.customHeaders definiert ist, wird es direkt verwendet; andernfalls werden Header aus model.generationConfig.customHeaders verwendet. Es findet kein Merging zwischen den beiden Ebenen statt.

Das Feld extra_body ermöglicht das Hinzufügen benutzerdefinierter Parameter zum Request-Body, der an die API gesendet wird. Dies ist nützlich für providerspezifische Optionen, die nicht von den Standardkonfigurationsfeldern abgedeckt werden. Hinweis: Dieses Feld wird nur für OpenAI-kompatible Provider (openai, qwen-oauth) unterstützt. Es wird für Anthropic- und Gemini-Provider ignoriert. Wenn extra_body in modelProviders[].generationConfig.extra_body definiert ist, wird es direkt verwendet; andernfalls werden Werte aus model.generationConfig.extra_body verwendet.

Beispiele für model.openAILoggingDir:

• "~/qwen-logs" - Logs im Verzeichnis ~/qwen-logs
• "./custom-logs" - Logs in ./custom-logs relativ zum aktuellen Verzeichnis
• "/tmp/openai-logs" - Logs im absoluten Pfad /tmp/openai-logs

fastModel

context

Fehlerbehebung bei der Dateisuchleistung

Wenn du Leistungsprobleme bei der Dateisuche hast (z. B. bei @-Vervollständigungen), insbesondere in Projekten mit einer sehr großen Anzahl von Dateien, kannst du folgende Schritte in der empfohlenen Reihenfolge versuchen:

1. Verwende .qwenignore: Erstelle eine .qwenignore-Datei im Projektstamm, um Verzeichnisse auszuschließen, die eine große Anzahl von Dateien enthalten, auf die du nicht verweisen musst (z. B. Build-Artefakte, Logs, node_modules). Die Reduzierung der Gesamtzahl der durchsuchten Dateien ist der effektivste Weg, um die Leistung zu verbessern.
2. Deaktiviere Fuzzy Search: Wenn das Ignorieren von Dateien nicht ausreicht, kannst du die Fuzzy-Suche deaktivieren, indem du enableFuzzySearch in deiner settings.json-Datei auf false setzt. Dadurch wird ein einfacherer, nicht-fuzziger Matching-Algorithmus verwendet, der schneller sein kann.
3. Deaktiviere rekursive Dateisuche: Als letzten Ausweg kannst du die rekursive Dateisuche vollständig deaktivieren, indem du enableRecursiveFileSearch auf false setzt. Dies ist die schnellste Option, da sie einen rekursiven Durchlauf deines Projekts vermeidet. Das bedeutet jedoch, dass du bei der Verwendung von @-Vervollständigungen den vollständigen Pfad zu Dateien eingeben musst.

tools

permissions

Das Berechtigungssystem bietet eine feingranulare Kontrolle darüber, welche Tools ausgeführt werden können, welche eine Bestätigung erfordern und welche blockiert sind.

Entscheidungspriorität (höchste zuerst): deny > ask > allow > (Standard/interaktiver Modus)

Die erste übereinstimmende Regel gewinnt. Regeln verwenden das Format "ToolName" oder "ToolName(Spezifizierer)".

Tool-Namen-Aliase (jeder davon funktioniert in Regeln):

Metakategorien:

Einige Regelnamen decken automatisch mehrere Tools ab:

[!important] Read(/path/**) stimmt mit allen vier Read-Tools überein (Datei lesen, grep, glob und Verzeichnisauflistung). Um nur das Lesen von Dateien einzuschränken, verwende ReadFile(/path/**) oder read_file(/path/**).

Beispiele für Regelsyntax:

Pfadmuster-Präfixe:

Verhinderung der Umgehung von Shell-Befehlen:

Berechtigungsregeln für Read, Edit und WebFetch werden auch durchgesetzt, wenn der Agent äquivalente Shell-Befehle ausführt. Wenn sich beispielsweise Read(./.env) in deny befindet, kann der Agent dies nicht über cat .env in einem Shell-Befehl umgehen. Unterstützte Shell-Befehle umfassen cat, grep, curl, wget, cp, mv, rm, chmod und viele mehr. Unbekannte/sichere Befehle (z. B. git) sind von Datei-/Netzwerkregeln nicht betroffen.

Migration von veralteten Einstellungen:

Beispielkonfiguration:

{
  "permissions": {
    "allow": ["Bash(git *)", "Bash(npm run *)", "Read(//Users/alice/code/**)"],
    "ask": ["Bash(git push *)", "Edit"],
    "deny": ["Bash(rm -rf *)", "Read(.env)", "WebFetch(malicious.com)"]
  }
}

[!tip] Verwende /permissions in der interaktiven CLI, um Regeln anzuzeigen, hinzuzufügen und zu entfernen, ohne settings.json direkt zu bearbeiten.

mcp

lsp

[!warning] Experimentelles Feature: Die LSP-Unterstützung ist derzeit experimentell und standardmäßig deaktiviert. Aktiviere sie mit dem Befehlszeilenflag --experimental-lsp.

Das Language Server Protocol (LSP) bietet Code-Intelligence-Funktionen wie Gehe-zu-Definition, Referenzen suchen und Diagnosen.

Die Konfiguration des LSP-Servers erfolgt über .lsp.json-Dateien im Projektstammverzeichnis, nicht über settings.json. Siehe die LSP-Dokumentation für Konfigurationsdetails und Beispiele.

security

advanced

mcpServers

Konfiguriert Verbindungen zu einem oder mehreren Model-Context Protocol (MCP)-Servern zum Entdecken und Verwenden benutzerdefinierter Tools. Qwen Code versucht, eine Verbindung zu jedem konfigurierten MCP-Server herzustellen, um verfügbare Tools zu entdecken. Wenn mehrere MCP-Server ein Tool mit demselben Namen bereitstellen, werden die Tool-Namen mit dem Server-Alias vorangestellt, den du in der Konfiguration definiert hast (z. B. serverAlias__actualToolName), um Konflikte zu vermeiden. Beachte, dass das System aus Kompatibilitätsgründen bestimmte Schema-Eigenschaften aus MCP-Tool-Definitionen entfernen kann. Mindestens einer der Werte command, url oder httpUrl muss angegeben werden. Wenn mehrere angegeben sind, ist die Prioritätsreihenfolge httpUrl, dann url, dann command.

telemetry

Konfiguriert Logging und Metrikerfassung für Qwen Code. Weitere Informationen findest du unter Telemetry.

Beispiel für settings.json

Hier ist ein Beispiel für eine settings.json-Datei mit der verschachtelten Struktur, neu ab v0.3.0:

{
  "general": {
    "vimMode": true,
    "preferredEditor": "code"
  },
  "ui": {
    "theme": "GitHub",
    "hideTips": false,
    "customWittyPhrases": [
      "You forget a thousand things every day. Make sure this is one of 'em",
      "Connecting to 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"]
  }
}

Shell-Verlauf

Die CLI speichert einen Verlauf der von dir ausgeführten Shell-Befehle. Um Konflikte zwischen verschiedenen Projekten zu vermeiden, wird dieser Verlauf in einem projektspezifischen Verzeichnis innerhalb deines Benutzer-Home-Ordners gespeichert.

• Speicherort: ~/.qwen/tmp/<project_hash>/shell_history
  • <project_hash> ist eine eindeutige Kennung, die aus dem Root-Pfad deines Projekts generiert wird.
  • Der Verlauf