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,
      "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 (nur OpenAI-kompatible Provider):

Zwei Guards begrenzen eine Streaming-Antwort, jeder akzeptiert 0 zum Deaktivieren. Keiner wird von den Anthropic/Gemini-Generatoren implementiert, die die unten beschriebene tröpfchenweise Form unbegrenzt lassen.

• QWEN_STREAM_IDLE_TIMEOUT_MS (Standard 240000) begrenzt die Inaktivität zwischen gestreamten Chunks: Ein Stream, der so lange schweigt, wird als wiederholbares ETIMEDOUT abgebrochen.
• 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.

Dies sind ausschließlich Umgebungsvariablen (oder für Embedder ContentGeneratorConfig.streamIdleTimeoutMs / streamMaxLifetimeMs) – es gibt keinen settings.json-Key; "streamMaxLifetimeMs" in settings.json zu schreiben hat keine Wirkung. Upgrade-Hinweise: Ein Deployment, das zuvor QWEN_STREAM_IDLE_TIMEOUT_MS=0 gesetzt hat – oder streamIdleTimeoutMs: 0 in ContentGeneratorConfig übergeben hat – um Stream-Abbrüche zu deaktivieren, benötigt jetzt auch QWEN_STREAM_MAX_LIFETIME_MS=0 (oder streamMaxLifetimeMs: 0), um dies beizubehalten; und die 15-Minuten-Lifetime-Obergrenze begrenzt auch einen Stream, dessen Idle-Timeout darüber angehoben wurde (z. B. QWEN_STREAM_IDLE_TIMEOUT_MS=1800000) – hebe die Obergrenze ebenfalls an oder setze sie auf 0, wenn du ein längeres Fenster benötigst.

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 nur für OpenAI-kompatible Provider (openai, qwen-oauth) unterstützt. Es wird für Anthropic- und Gemini-Provider ignoriert. 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.

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.

Telemetrie

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

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

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 eurer 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.
• Sitzungsinformationen: 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.