Qwen Code Konfiguration

Konfigurationsebenen

Die Konfiguration wird in der folgenden Prioritätsreihenfolge angewendet (niedrigere Zahlen werden durch höhere Zahlen ü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 zum Beispiel:

• 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 ältere 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 Legacy-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. Die meisten Einstellungen sollten in das entsprechende Top-Level-Kategorieobjekt in deiner settings.json-Datei eingefügt werden. Einige Top-Level-Einstellungen wie proxy und plansDirectory bleiben aus Kompatibilitätsgründen direkte Root-Keys.

general

output

review

Diese Einstellungen werden nur aus Operator-Scopes gelesen (User, System und SystemDefaults); Werte in einer Workspace-.qwen/settings.json werden ignoriert, sodass ein Repository keine Review-Policy für seine Reviewer setzen kann.

ui

ide

privacy

model

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

timeout (Request-Timeout):

timeout ist das Timeout pro Request in Millisekunden (Standard 120000). Setze es auf 0, um das Request-Timeout zu deaktivieren – entsprechend der Konvention QWEN_STREAM_IDLE_TIMEOUT_MS=0 – anstatt den Request abzubrechen. Es kann auch über die Umgebungsvariable QWEN_CODE_API_TIMEOUT_MS gesetzt werden. Dies ist verschieden von den beiden Stream-Guards unten.

Stream-Guards (OpenAI-kompatible und Anthropic-Provider):

Zwei Guards begrenzen eine Streaming-Antwort, jeder akzeptiert 0 zum Deaktivieren. Der Gemini-Generator implementiert sie nicht, was die unten beschriebene tröpfchenweise Form für Gemini-Modelle unbegrenzt lässt.

• streamIdleTimeoutMs (Standard 240000) begrenzt die Inaktivität zwischen gestreamten Chunks: Ein Stream, der so lange schweigt, wird als wiederholbares ETIMEDOUT abgebrochen. Für Provider-basierte Modelle setze ihn unter der passenden modelProviders[providerId][].generationConfig; für Runtime-Modelle verwende model.generationConfig. Ein expliziter Modellwert hat Vorrang vor QWEN_STREAM_IDLE_TIMEOUT_MS, und 0 deaktiviert den Idle-Guard.
• QWEN_STREAM_MAX_LIFETIME_MS (Standard 900000) begrenzt die gesamte Upstream-Wartezeit einer Streaming-Antwort unabhängig vom Chunk-Fluss – die Obergrenze für einen tröpfchenweisen Stream, der nie abschließen kann, sich nie zurücksetzen kann.

streamMaxLifetimeMs bleibt nur über QWEN_STREAM_MAX_LIFETIME_MS oder für Embedder über ContentGeneratorConfig.streamMaxLifetimeMs verfügbar; das Schreiben in settings.json hat keine Wirkung. Die 15-Minuten-Lifetime-Obergrenze begrenzt weiterhin einen Stream, dessen Idle-Timeout darüber angehoben wurde. Hebe die Lifetime-Umgebungsvariable ebenfalls an oder setze sie auf 0, wenn du ein längeres Fenster benötigst. Das alleinige Deaktivieren von streamIdleTimeoutMs deaktiviert diese Lifetime-Obergrenze nicht.

max_tokens (Output-Token-Limit):

Wenn weder samplingParams.max_tokens noch QWEN_CODE_MAX_OUTPUT_TOKENS gesetzt ist, verwendet Qwen Code in der Regel das deklarierte Output-Limit des ausgewählten Modells als Standard-Output-Limit für den Request. Wenn die Antwort dennoch dieses Limit erreicht, kann Qwen Code einen Retry mit einem erhöhten Limit (mit einer Untergrenze von 64K) durchführen und dann über Fortsetzungs-Turns hinweg fortfahren.

Für OpenAI-kompatible Provider ist samplingParams auch ein Escape Hatch für das Wire-Format: Wenn es gesetzt ist, werden seine Schlüssel unverändert durchgereicht und Qwen Code synthetisiert keinen max_tokens-Standardwert. Verwende dies für provider-spezifische Parameter wie max_completion_tokens.

Um ein festes Output-Limit zu erzwingen, setze samplingParams.max_tokens in deinen Einstellungen oder verwende die Umgebungsvariable QWEN_CODE_MAX_OUTPUT_TOKENS. Explizite Limits deaktivieren die automatische Eskalation der Output-Token.

toolResultContentFormat:

Steuert, wie reine Text-Tool-Ergebnisse in OpenAI-kompatiblen Requests serialisiert werden. Der Standardwert "parts" behält die Standardform des Content-Part-Arrays bei. Setze "string" nur für Legacy-OpenAI-kompatible Runtimes, deren Tool-Templates Text-Content-Parts ignorieren, wie z. B. ältere GLM-5.1 vLLM/SGLang-Templates. Von Tools zurückgegebene Medien werden weiterhin durch splitToolMedia gesteuert.

contextWindowSize:

Überschreibt die Standardgröße des Context Windows für das ausgewählte Modell. Qwen Code bestimmt das Context Window anhand eingebauter Standardwerte basierend auf Model-Namens-Matching, mit einem konstanten Fallback-Wert. Verwende diese Einstellung, wenn das effektive Context-Limit eines Providers von der Qwen Code-Standardvorgabe abweicht. Dieser Wert definiert die angenommene maximale Context-Kapazität des Modells, nicht ein Token-Limit pro Request.

Wenn das ausgewählte Modell in modelProviders definiert ist, setze contextWindowSize in der generationConfig dieses Provider-Eintrags anstelle der Top-Level-model.generationConfig. Provider-Model-Einträge sind versiegelt (sealed), daher füllen Top-Level-Generation-Einstellungen fehlende Provider-Felder nicht auf.

modalities:

Überschreibt die automatisch erkannten Input-Modalitäten für das ausgewählte Modell. Qwen Code erkennt unterstützte Modalitäten (Bild, PDF, Audio, Video) automatisch basierend auf Model-Namens-Mustern. Verwende diese Einstellung, wenn die automatische Erkennung inkorrekt ist – zum Beispiel, 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 erfordern. Für Provider-Modelle definiere customHeaders in modelProviders[].generationConfig.customHeaders. Für Runtime-Modelle ohne passenden Provider-Eintrag definiere es in model.generationConfig.customHeaders. Zwischen den beiden Ebenen erfolgt kein Merging.

Das Feld extra_body ermöglicht das Hinzufügen benutzerdefinierter Parameter zum an die API gesendeten Request-Body. Dies ist nützlich für provider-spezifische Optionen, die nicht von den Standard-Konfigurationsfeldern abgedeckt werden. Hinweis: Dieses Feld wird für OpenAI-kompatible Provider (openai, qwen-oauth) und die OpenAI Responses API (openai-responses) unterstützt. Es wird für Anthropic- und Gemini-Provider ignoriert. Auf dem openai-responses-Wire wird der Legacy-Key enable_thinking in reasoning.effort übersetzt, anstatt unverändert weitergeleitet zu werden – verwende für diesen Provider stattdessen direkt reasoning.effort. Für Provider-Modelle definiere extra_body in modelProviders[].generationConfig.extra_body. Für Runtime-Modelle ohne passenden Provider-Eintrag definiere es in model.generationConfig.extra_body.

Beispiele für model.openAILoggingDir:

• "~/qwen-logs" - Loggt in das Verzeichnis ~/qwen-logs
• "./custom-logs" - Loggt in ./custom-logs relativ zum aktuellen Verzeichnis
• "/tmp/openai-logs" - Loggt in den absoluten Pfad /tmp/openai-logs

fastModel

advisorModel

visionModel

compactionModel

imageModel

visionBridgeTimeoutMs

voiceModel

modelFallbacks

modelPricing

context

Fehlerbehebung bei der Performance der Dateisuche

Wenn du Performance-Probleme bei der Dateisuche hast (z. B. bei @-Completions), insbesondere in Projekten mit einer sehr großen Anzahl von Dateien, kannst du Folgendes in der empfohlenen Reihenfolge ausprobieren:

1. Ignore-Datei verwenden: Erstelle eine .qwenignore oder eine konfigurierte benutzerdefinierte Ignore-Datei in deinem Projekt-Root, 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 Performance zu verbessern.
2. Fuzzy Search deaktivieren: 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-fuzzy Matching-Algorithmus verwendet, was schneller sein kann.
3. Rekursive Dateisuche deaktivieren: Als letzte Möglichkeit kannst du die rekursive Dateisuche vollständig deaktivieren, indem du enableRecursiveFileSearch auf false setzt. Dies ist die schnellste Option, da ein rekursives Durchsuchen deines Projekts vermieden wird. Das bedeutet jedoch, dass du bei der Verwendung von @-Completions den vollständigen Pfad zu den Dateien eingeben musst.

tools

memory

Siehe Memory für Details zur Funktionsweise von Auto-Memory und zur Verwendung der Befehle /memory, /remember und /dream.

agents

permissions

Das Permission-System 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 dieser Namen funktioniert in Regeln):

Meta-Kategorien:

Einige Regelnamen decken automatisch mehrere Tools ab:

[!important] Read(/path/**) trifft auf alle vier Read-Tools zu (Datei lesen, grep, glob und Verzeichnisauflistung). Um nur das Lesen von Dateien einzuschränken, verwende ReadFile(/path/**) oder read_file(/path/**).

Beispiele für die Regel-Syntax:

Präfixe für Pfadmuster:

Verhinderung von Shell-Befehlsumgehungen:

Permission-Regeln für Read, Edit und WebFetch werden auch durchgesetzt, wenn der Agent äquivalente Shell-Befehle ausführt. Wenn beispielsweise Read(./.env) in deny enthalten ist, 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 weitere. Unbekannte/sichere Befehle (z. B. git) sind von Datei-/Netzwerkregeln nicht betroffen.

Migration von Legacy-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.

slashCommands

Steuert, welche Slash-Befehle in der CLI verfügbar sind. Nützlich, um die Befehlsoberfläche in Multi-Tenant- oder Enterprise-Deployments einzuschränken.

Dieselbe Denylist kann auch über den CLI-Flag --disabled-slash-commands (kommagetrennt oder wiederholt) und die Umgebungsvariable QWEN_DISABLED_SLASH_COMMANDS bereitgestellt werden; Werte aus allen drei Quellen werden zusammengeführt.

Beispiel – Built-ins für ein sandboxed Deployment sperren:

{
  "slashCommands": {
    "disabled": ["auth", "mcp", "extensions", "ide", "quit"]
  }
}

Mit diesen Werten in einer systemweiten settings.json (/etc/qwen-code/settings.json oder QWEN_CODE_SYSTEM_SETTINGS_PATH) können Benutzer die Denylist nicht aus ihrem eigenen Scope verkleinern, und die deaktivierten Befehle erscheinen weder in der Autovervollständigung noch werden sie bei Eingabe ausgeführt.

[!note] Diese Einstellung beschränkt nur Slash-Befehle (z. B. /auth, /mcp). Sie beeinflusst nicht die Tool-Permissions – siehe dafür permissions.deny. Sie fängt auch keine Tastenkombinationen wie Ctrl+C oder Esc ab.

skills

Steuert, welche Skills dem Modell zur Verfügung gestellt werden.

Die Priorität ist skills.disabled > skills.enabled > skills.defaultDisabled. Ein Benutzer kann beispielsweise einen Skill in defaultDisabled setzen und ein Projekt kann denselben Namen zu enabled hinzufügen; ein hartes disabled auf beliebiger Ebene gewinnt dennoch.

Jede Liste enthält literale Skill-Namen, die nach dem Trimmen case-insensitive abgeglichen werden, ohne Glob-Unterstützung. skills.enabled annulliert einen skills.defaultDisabled-Eintrag nur, wenn beide Einträge gleich geschrieben sind, weil dieser Schritt die Einträge selbst vergleicht, anstatt sie zu einem Skill aufzulösen — sodass ein Extension-Skill, der sowohl aus dem Standard genommen als auch aktiviert werden muss, in beiden Listen als rust:pdf geschrieben wird. Siehe Extension Skills, warum die beiden obigen Listen beide Schreibweisen akzeptieren und diese nicht.

mcp

lsp

[!warning] Experimentelles Feature: LSP-Support ist derzeit experimentell und standardmäßig deaktiviert. Aktiviere ihn mit dem --experimental-lsp Command-Line-Flag.

Das Language Server Protocol (LSP) bietet Code-Intelligence-Features wie Go-to-Definition, Referenzen suchen und Diagnostics.

Die LSP-Server-Konfiguration erfolgt über .lsp.json-Dateien in deinem Projekt-Root-Verzeichnis, nicht über settings.json. Siehe die LSP-Dokumentation für Konfigurationsdetails und Beispiele.

security

serve

Persistente Sub-Session-Concurrency-Einstellungen für qwen serve. Änderungen erfordern einen Neustart des Daemons. Nicht-positive oder nicht-ganzzahlige Concurrency-Limits erzeugen eine Warnung und fallen auf ihre eingebauten Standardwerte zurück.

advanced

experimental

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 den Tool-Namen der 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 eine der Optionen command, url oder httpUrl muss angegeben werden. Wenn mehrere angegeben sind, ist die Prioritätenreihenfolge httpUrl, dann url, dann command.

telemetry

Konfiguriert das Logging und die Metrikerfassung für Qwen Code. Weitere Informationen findest du unter telemetry.

outboundCorrelation

⚠️ Sicherheitsrelevant. Steuert, welche clientseitigen Korrelationsdaten Qwen Code in ausgehende LLM-API-Requests schreibt – eine separate Genehmigungsentscheidung als telemetry.*, das die Daten regelt, die in dein EIGENES Observability-Backend fließen. Alle Werte sind standardmäßig ausgeschaltet.

{
  "outboundCorrelation": {
    "allowDynamicHeaderValues": true
  }
}

allowDynamicHeaderValues ist nur der Genehmigungsschalter. Welche Hosts den Wert erhalten und wie der Header heißt, wird dort entschieden, wo der Header lebt — modelProviders[].generationConfig.customHeaders, siehe Dynamic values in customHeaders. Dieses Scoping ist der Grund, warum es hier keine Host-Allowlist gibt: Du hast den Endpunkt bereits gewählt, als du die baseUrl des Providers geschrieben hast, und Provider, die den Header nicht senden sollen, tragen ihn einfach nicht.

Wenn ein Provider-Eintrag einen Platzhalter hat, während dies ausgeschaltet ist, wird der Header verworfen und eine Warnung, die beide nennt, beim Start ausgegeben – sodass ein Gateway, das deine Requests ablehnt, niemals ein stilles Rätsel sein sollte.

Datenschutzhinweis: Ein expandierter Wert ist ein stabiler Pro-Konversation-Identifikator. Setze ihn nur bei einem Provider, an den du bereits deine Prompt-Inhalte sendest.

Beispiel settings.json

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

{
  "proxy": "http://localhost:7890",
  "plansDirectory": "./.qwen/plans",
  "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",
    "sandboxImage": "ghcr.io/qwenlm/qwen-code:0.14.1",
    "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,
    "userId": "user-079458",
    "includeSensitiveSpanAttributes": false,
    "sensitiveSpanAttributeMaxLength": 1048576
  },
  "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 Shell-Befehle, die du ausführst. Um Konflikte zwischen verschiedenen Projekten zu vermeiden, wird dieser Verlauf in einem projektspezifischen Verzeichnis innerhalb deines Home-Verzeichnisses gespeichert.

• Speicherort: ~/.qwen/tmp/<project_hash>/shell_history
  • <project_hash> ist ein eindeutiger Bezeichner, der aus dem Root-Pfad deines Projekts generiert wird.
  • Der Verlauf wird in einer Datei namens shell_history gespeichert.

Umgebungsvariablen & .env-Dateien

Umgebungsvariablen sind eine gängige Methode zur Konfiguration von Anwendungen, insbesondere für sensible Informationen (wie Tokens) oder für Einstellungen, die sich zwischen verschiedenen Umgebungen ändern können.

Qwen Code kann Umgebungsvariablen automatisch aus .env-Dateien laden. Für authentifizierungsrelevante Variablen (wie OPENAI_*) und den empfohlenen .qwen/.env-Ansatz siehe Authentication.

Tabelle der Umgebungsvariablen

Standalone-Update-Downloadquelle

Setze QWEN_UPDATE_BASE_URL, um ein benutzerdefiniertes HTTPS-Release-Root für Standalone-Updates zu verwenden:

export QWEN_UPDATE_BASE_URL="https://downloads.example.com/qwen-code"
qwen update

Für Version 0.23.0 lädt der Updater das Plattform-Archiv, SHA256SUMS und SHA256SUMS.sig von <base-url>/v0.23.0/ herunter. Hoste diese Dateien unter denselben Namen und demselben Verzeichnis-Layout wie ein offizielles Release. Bestehende Prüfsummen- und Signaturprüfungen gelten weiterhin, einschließlich QWEN_REQUIRE_SIGNATURE=1, wenn eine Signatur erforderlich ist.

Die URL muss HTTPS verwenden und darf keine Credentials, einen Query-String oder ein Fragment enthalten. Umgebende Whitespaces und abschließende Schrägstriche werden entfernt. Ein leerer oder nur aus Whitespaces bestehender Wert behält die eingebauten Downloadquellen und ihre Fallback-Reihenfolge bei. Wenn ein benutzerdefiniertes Root gesetzt ist, fällt ein fehlgeschlagener Download nicht auf die eingebauten Quellen zurück.

Konfiguriere diese Variable in der startenden Shell oder einer .env-Datei auf Benutzerebene. Sie wird aus Projekt-.env- und .qwen/.env-Dateien sowie aus dem env-Abschnitt der obersten Ebene in settings.json auf jedem Scope abgelehnt. Ein .env-Wert auf Benutzerebene wird beim Start geladen; starte Qwen Code nach der Änderung neu.

Diese Einstellung gilt für qwen update, /update und automatische Standalone-Updates. Sie ändert nicht die npm-Registry-Versionserkennung. Sie ist getrennt von der QWEN_INSTALL_BASE_URL des Installers, die direkt auf ein versionsspezifisches Verzeichnis zeigt.

Befehlszeilenargumente

Argumente, die direkt beim Ausführen der CLI übergeben werden, können andere Konfigurationen für diese spezifische Sitzung überschreiben.

Für die Auswahl des Sandbox-Images gilt folgende Priorität: --sandbox-image > QWEN_SANDBOX_IMAGE > tools.sandboxImage > integriertes Standard-Image.

Tabelle der Befehlszeilenargumente

Kontextdateien (Hierarchischer Instruktionskontext)

Auch wenn Kontextdateien nicht streng genommen die Verhaltensweise der CLI konfigurieren (standardmäßig QWEN.md, konfigurierbar über die context.fileName-Einstellung), sind sie entscheidend für die Konfiguration des Instruktionskontextes (auch “Memory” genannt). Mit dieser leistungsstarken Funktion kannst du der KI projektspezifische Anweisungen, Coding-Style-Guides oder beliebige relevante Hintergrundinformationen geben, wodurch ihre Antworten besser auf deine Bedürfnisse zugeschnitten und genauer werden. Die CLI enthält UI-Elemente, wie z. B. eine Anzeige im Footer, die die Anzahl der geladenen Kontextdateien zeigt, um dich über den aktiven Kontext zu informieren.

• Zweck: Diese Markdown-Dateien enthalten Anweisungen, Richtlinien oder Kontext, den das Qwen-Modell während deiner Interaktionen kennen soll. Das System ist so konzipiert, dass es diesen Instruktionskontext hierarchisch verwaltet.

Beispielinhalt einer Kontextdatei (z. B. QWEN.md)

Hier ist ein konzeptionelles Beispiel dafür, was eine Kontextdatei im Stammverzeichnis eines TypeScript-Projekts enthalten könnte:

# Project: My Awesome TypeScript Library

## General Instructions:
- When generating new TypeScript code, please follow the existing coding style.
- Ensure all new functions and classes have JSDoc comments.
- Prefer functional programming paradigms where appropriate.
- All code should be compatible with TypeScript 5.0 and Node.js 22+.

## Coding Style:
- Use 2 spaces for indentation.
- Interface names should be prefixed with `I` (e.g., `IUserService`).
- Private class members should be prefixed with an underscore (`_`).
- Always use strict equality (`===` and `!==`).

## Specific Component: `src/api/client.ts`
- This file handles all outbound API requests.
- When adding new API call functions, ensure they include robust error handling and logging.
- Use the existing `fetchWithRetry` utility for all GET requests.

## Regarding Dependencies:
- Avoid introducing new external dependencies unless absolutely necessary.
- If a new dependency is required, please state the reason.

Dieses Beispiel zeigt, wie du allgemeinen Projektkontext, spezifische Coding-Konventionen und sogar Notizen zu bestimmten Dateien oder Komponenten bereitstellen kannst. Je relevanter und präziser deine Kontextdateien sind, desto besser kann die KI dich unterstützen. Projektspezifische Kontextdateien werden dringend empfohlen, um Konventionen und Kontext zu etablieren.

• Hierarchisches Laden und Priorität: Die CLI implementiert ein hierarchisches Memory-System, indem sie Kontextdateien (z. B. QWEN.md) aus verschiedenen Verzeichnissen lädt. Inhalte aus Dateien weiter unten in dieser Liste (spezifischer) überschreiben oder ergänzen in der Regel Inhalte aus Dateien weiter oben (allgemeiner). Die genaue Verkettungsreihenfolge und der finale Kontext können im /memory-Dialog eingesehen werden. Die typische Ladereihenfolge ist:
  1. Globale Kontextdatei:
     • Speicherort: ~/.qwen/<configured-context-filename> (z. B. ~/.qwen/QWEN.md in deinem Benutzer-Home-Verzeichnis).
     • Geltungsbereich: Stellt Standardanweisungen für alle deine Projekte bereit.
  2. Kontextdateien im Projekt-Root und übergeordneten Verzeichnissen:
     • Speicherort: Die CLI sucht im aktuellen Arbeitsverzeichnis nach der konfigurierten Kontextdatei und dann in jedem übergeordneten Verzeichnis bis entweder zum Projekt-Root (erkennbar an einem .git-Ordner) oder zu deinem Home-Verzeichnis.
     • Geltungsbereich: Stellt Kontext bereit, der für das gesamte Projekt oder einen wesentlichen Teil davon relevant ist.
• Verkettung & UI-Anzeige: Die Inhalte aller gefundenen Kontextdateien werden verkettet (mit Trennzeichen, die auf ihre Herkunft und ihren Pfad hinweisen) und als Teil des System-Prompts bereitgestellt. Der CLI-Footer zeigt die Anzahl der geladenen Kontextdateien an und gibt dir so einen schnellen visuellen Hinweis auf den aktiven Instruktionskontext.
• Inhalte importieren: Du kannst deine Kontextdateien modularisieren, indem du andere Markdown-Dateien mit der Syntax @path/to/file.md importierst. Weitere Details findest du in der Memory-Dokumentation.
• Befehle zur Memory-Verwaltung:
  • Verwende /memory, um den Dialog zur Memory-Verwaltung zu öffnen.
  • Aktualisiere den Memory-Status über den Dialog, um Kontextdateien aus allen konfigurierten Verzeichnissen erneut zu scannen und neu zu laden.
  • Siehe die Befehlsdokumentation für vollständige Details zum /memory-Befehl.

Indem du diese Konfigurationsebenen und die hierarchische Natur von Kontextdateien verstehst und nutzt, kannst du den Memory der KI effektiv verwalten und die Antworten von Qwen Code genau auf deine spezifischen Bedürfnisse und Projekte zuschneiden.

Sandbox

Qwen Code kann potenziell unsichere Operationen (wie Shell-Befehle und Dateiänderungen) in einer Sandbox-Umgebung ausführen, um dein System zu schützen.

Die Sandbox ist standardmäßig deaktiviert, du kannst sie jedoch auf verschiedene Arten aktivieren:

• Verwendung des --sandbox- oder -s-Flags.
• Setzen der QWEN_SANDBOX-Umgebungsvariable.
• Setzen von tools.sandbox in den Einstellungen.

⚠️ --yolo aktiviert nicht automatisch eine Sandbox. Der YOLO-Modus genehmigt nur Tool-Aufrufe automatisch; die Sandbox muss weiterhin explizit über --sandbox, QWEN_SANDBOX oder tools.sandbox aktiviert werden. Bei Headless-/nicht-interaktiven Ausführungen mit --yolo (oder --approval-mode=yolo) und ohne Sandbox kann das Modell Shell-, Write- und Edit-Tools mit den Berechtigungen des aktuellen Prozesses ausführen – Qwen Code gibt in diesem Fall eine Warnung auf stderr aus. Unterdrücke diese mit QWEN_CODE_SUPPRESS_YOLO_WARNING=1, sobald du die Kompromisse geprüft hast.

Standardmäßig wird ein vorgefertigtes qwen-code-sandbox Docker-Image verwendet.

Für projektspezifische Sandbox-Anforderungen kannst du ein benutzerdefiniertes Dockerfile unter .qwen/sandbox.Dockerfile im Stammverzeichnis deines Projekts erstellen. Dieses Dockerfile kann auf dem Basis-Sandbox-Image basieren:

FROM qwen-code-sandbox
# Add your custom dependencies or configurations here
# For example:
# RUN apt-get update && apt-get install -y some-package
# COPY ./my-config /app/my-config

Wenn .qwen/sandbox.Dockerfile vorhanden ist, kannst du beim Ausführen von Qwen Code die Umgebungsvariable BUILD_SANDBOX verwenden, um das benutzerdefinierte Sandbox-Image automatisch zu bauen:

BUILD_SANDBOX=1 qwen -s

Nutzungsstatistiken

Um uns bei der Verbesserung von Qwen Code zu unterstützen, erfassen wir anonymisierte Nutzungsstatistiken. Diese Daten helfen uns zu verstehen, wie die CLI genutzt wird, häufige Probleme zu identifizieren und neue Funktionen zu priorisieren.

Was wir erfassen:

• Tool-Aufrufe: Wir protokollieren die Namen und Kategorien (native oder MCP) der aufgerufenen Tools, ihren Terminal-Status (success, error oder cancelled) und wie lange ihre Ausführung dauert. Wir erfassen nicht die an die Tools übergebenen Argumente oder die von ihnen zurückgegebenen Daten.
• API-Anfragen: Wir protokollieren das für jede Anfrage verwendete Modell, die Dauer der Anfrage und ob sie erfolgreich war. Wir erfassen nicht den Inhalt der Prompts oder Antworten.
• Session-Informationen: Wir erfassen Informationen über die Konfiguration der CLI, wie z. B. die aktivierten Tools und den Genehmigungsmodus.

Was wir NICHT erfassen:

• Personenbezogene Daten (PII): Wir erfassen keine persönlichen Informationen wie deinen Namen, deine E-Mail-Adresse oder API-Keys.
• Prompt- und Antwortinhalte: Wir protokollieren nicht den Inhalt deiner Prompts oder die Antworten des Modells.
• Dateiinhalte: Wir protokollieren nicht den Inhalt von Dateien, die von der CLI gelesen oder geschrieben werden.

So kannst du die Erfassung deaktivieren:

Du kannst die Erfassung von Nutzungsstatistiken jederzeit deaktivieren, indem du die Eigenschaft usageStatisticsEnabled in der Kategorie privacy in deiner settings.json-Datei auf false setzt:

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

Alternativ kannst du QWEN_USAGE_STATISTICS_ENABLED=false (oder 0) in der Umgebung setzen. Die Umgebungsvariable hat Vorrang vor der Einstellung. Starte Qwen Code nach der Änderung eines der beiden Werte neu.