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 dauerhafte Konfiguration. Es gibt vier Speicherorte für diese Dateien:

Das .qwen-Verzeichnis in Ihrem Projekt

Zusätzlich zu einer Projekteinstellungsdatei kann das .qwen-Verzeichnis eines Projekts andere projektspezifische Dateien enthalten, die für den Betrieb von Qwen Code relevant sind, z. B.:

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

Migrationskonfiguration

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

Konsolidierungsrichtlinie für disableAutoUpdate und disableUpdateNag

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

Verfügbare Einstellungen in settings.json

Die Einstellungen sind in Kategorien organisiert. Die meisten Einstellungen sollten in das entsprechende Objekt der obersten Kategorie in Ihrer settings.json-Datei eingefügt werden. Einige wenige Einstellungen der obersten Ebene wie proxy und plansDirectory bleiben aus Kompatibilitätsgründen direkte Stammschlüssel.

general

output

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
      }
    }
  }
}

max_tokens (adaptive Output-Token):

Wenn samplingParams.max_tokens nicht gesetzt ist, verwendet Qwen Code eine adaptive Output-Token-Strategie, um die GPU-Ressourcennutzung zu optimieren:

1. Anfragen beginnen mit einem Standard-Limit von 8K Output-Token
2. Wenn die Antwort abgeschnitten wird (das Modell erreicht das Limit), wiederholt Qwen Code automatisch mit 64K Token
3. Die partielle Ausgabe wird verworfen und durch die vollständige Antwort des Wiederholungsversuchs ersetzt

Dies ist für Benutzer transparent – Sie können kurzzeitig einen Wiederholungsindikator sehen, falls eine Eskalation auftritt. Da 99 % der Antworten unter 5K Token liegen, kommt der Wiederholungsversuch selten vor (<1 % der Anfragen).

Um dieses Verhalten zu überschreiben, setzen Sie entweder samplingParams.max_tokens in Ihren Einstellungen oder verwenden Sie die Umgebungsvariable QWEN_CODE_MAX_OUTPUT_TOKENS.

toolResultContentFormat:

Steuert, wie reine Text-Tool-Ergebnisse in OpenAI-kompatiblen Anfragen serialisiert werden. Der Standardwert "parts"" behält die übliche Content-Part-Array-Struktur bei. Setzen Sie "string" nur für Legacy-OpenAI-kompatible Laufzeiten, deren Tool-Vorlagen Text-Content-Parts ignorieren, wie z. B. ältere GLM-5.1 vLLM/SGLang-Vorlagen. Von Tools zurückgegebene Medien werden weiterhin von splitToolMedia gesteuert.

contextWindowSize:

Überschreibt die Standard-Kontextfenstergröße für das ausgewählte Modell. Qwen Code bestimmt das Kontextfenster anhand integrierter Standardwerte basierend auf dem Modellnamen-Matching, mit einem konstanten Fallback-Wert. Verwenden Sie diese Einstellung, wenn das effektive Kontextlimit eines Anbieters von Qwen Codes Standard abweicht. Dieser Wert definiert die angenommene maximale Kontextkapazität des Modells, nicht ein Token-Limit pro Anfrage.

Wenn das ausgewählte Modell in modelProviders definiert ist, setzen Sie contextWindowSize in den generationConfig dieses Anbietereintrags, nicht im übergeordneten model.generationConfig. Provider-Modell-Einträge sind versiegelt, sodass übergeordnete Generierungseinstellungen fehlende Provider-Felder nicht auffüllen.

modalities:

Überschreibt die automatisch erkannten Eingabemodalitäten für das ausgewählte Modell. Qwen Code erkennt automatisch unterstützte Modalitäten (Bild, PDF, Audio, Video) basierend auf Mustervergleichen des Modellnamens. Verwenden Sie diese Einstellung, wenn die automatische Erkennung falsch 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 }. Lassen Sie einen Schlüssel weg oder setzen Sie ihn auf false für nicht unterstützte Typen.

customHeaders:

Ermöglicht das Hinzufügen benutzerdefinierter HTTP-Header zu allen API-Anfragen. Dies ist nützlich für Anfrageverfolgung, Überwachung, API-Gateway-Routing oder wenn verschiedene Modelle unterschiedliche Header benötigen. Für Provider-Modelle definieren Sie customHeaders in modelProviders[].generationConfig.customHeaders. Für Laufzeitmodelle ohne passenden Provider-Eintrag definieren Sie es in model.generationConfig.customHeaders. Es findet kein Merging zwischen den beiden Ebenen statt.

Das Feld extra_body ermöglicht das Hinzufügen benutzerdefinierter Parameter zum Anfragebody, der an die API gesendet wird. Dies ist nützlich für anbieterspezifische Optionen, die nicht von den Standardkonfigurationsfeldern abgedeckt werden. Hinweis: Dieses Feld wird nur für OpenAI-kompatible Provider (openai, qwen-oauth) unterstützt. Für Anthropic- und Gemini-Provider wird es ignoriert. Für Provider-Modelle definieren Sie extra_body in modelProviders[].generationConfig.extra_body. Für Laufzeitmodelle ohne passenden Provider-Eintrag definieren Sie es in model.generationConfig.extra_body.

model.openAILoggingDir Beispiele:

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

fastModel

context

Fehlerbehebung für die Dateisuchleistung

Wenn Sie Leistungsprobleme bei der Dateisuche (z. B. mit @-Vervollständigungen) haben, insbesondere in Projekten mit einer sehr großen Anzahl von Dateien, können Sie die folgenden Maßnahmen in der empfohlenen Reihenfolge ausprobieren:

1. Eine Ignorieren-Datei verwenden: Erstellen Sie eine .qwenignore oder eine konfigurierte benutzerdefinierte Ignorieren-Datei im Stammverzeichnis Ihres Projekts, um Verzeichnisse auszuschließen, die eine große Anzahl von Dateien enthalten, auf die Sie nicht verweisen müssen (z. B. Build-Artefakte, Logs, node_modules). Die Reduzierung der Gesamtzahl der durchsuchten Dateien ist der effektivste Weg, um die Leistung zu verbessern.
2. Fuzzy-Suche deaktivieren: Falls das Ignorieren von Dateien nicht ausreicht, können Sie die Fuzzy-Suche deaktivieren, indem Sie enableFuzzySearch in Ihrer settings.json-Datei auf false setzen. Dadurch wird ein einfacherer, nicht-fuzzy Matching-Algorithmus verwendet, der schneller sein kann.
3. Rekursive Dateisuche deaktivieren: Als letzte Möglichkeit können Sie die rekursive Dateisuche vollständig deaktivieren, indem Sie enableRecursiveFileSearch auf false setzen. Dies ist die schnellste Option, da eine rekursive Durchsuchung Ihres Projekts vermieden wird. Dies bedeutet jedoch, dass Sie den vollständigen Pfad zu Dateien eingeben müssen, wenn Sie @-Vervollständigungen verwenden.

tools

memory

Siehe Speicher für Details zur Funktionsweise des automatischen Speichers und zur Verwendung der Befehle /memory, /remember und /dream.

permissions

Das Berechtigungssystem bietet eine feinkörnige Kontrolle darüber, welche Tools ausgeführt werden dürfen, welche eine Bestätigung erfordern und welche blockiert sind.

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

Die erste passende Regel gewinnt. Regeln verwenden das Format "ToolName" oder "ToolName(spezifizierer)".

Toolname-Aliase (alle funktionieren in Regeln):

Meta-Kategorien:

Einige Regelnamen decken automatisch mehrere Tools ab:

[!important] Read(/path/**) passt auf alle vier Lese-Tools (Dateilesen, grep, glob und Verzeichnisliste). Um nur das Dateilesen einzuschränken, verwenden Sie ReadFile(/path/**) oder read_file(/path/**).

Beispiele für Regelsyntax:

Umgehung von Shell-Befehlen verhindern:

Die Berechtigungsregeln für Read, Edit und WebFetch werden auch durchgesetzt, wenn der Agent entsprechende 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 den Datei-/Netzwerkregeln nicht betroffen.

Migration von alten 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] Verwenden Sie /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 Unternehmensumgebungen einzuschränken.

Die gleiche Sperrliste kann auch über das CLI-Flag --disabled-slash-commands (durch Kommas getrennt oder wiederholt) und die Umgebungsvariable QWEN_DISABLED_SLASH_COMMANDS bereitgestellt werden; Werte aus allen drei Quellen werden vereinigt.

Beispiel – integrierte Befehle für eine Sandbox-Umgebung 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 Sperrliste aus ihrem eigenen Bereich nicht verkleinern, und die deaktivierten Befehle werden weder in der Autovervollständigung angezeigt noch bei Eingabe ausgeführt.

[!note] Diese Einstellung steuert nur Slash-Befehle (z.B. /auth, /mcp). Sie hat keine Auswirkungen auf Tool-Berechtigungen – siehe dazu permissions.deny. Sie fängt auch keine Tastaturkürzel wie Strg+C oder Esc ab.

mcp

[!note] Sicherheitshinweis für MCP-Server: Diese Einstellungen verwenden einfachen String-Abgleich auf MCP-Servernamen, der geändert werden kann. Wenn Sie als Systemadministrator verhindern möchten, dass Benutzer dies umgehen, sollten Sie die mcpServers auf Systemebene so konfigurieren, dass der Benutzer keine eigenen MCP-Server konfigurieren kann. Dies sollte nicht als abgesicherter Sicherheitsmechanismus betrachtet werden.

lsp

[!warning] Experimentelle Funktion: Die LSP-Unterstützung ist derzeit experimentell und standardmäßig deaktiviert. Aktivieren Sie sie mit dem Befehlszeilen-Flag --experimental-lsp.

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

Die Konfiguration des LSP-Servers erfolgt über .lsp.json-Dateien im Stammverzeichnis Ihres Projekts, nicht über settings.json. Weitere Konfigurationsdetails und Beispiele finden Sie in der LSP-Dokumentation.

security

advanced

experimental

mcpServers

Konfiguriert Verbindungen zu einem oder mehreren Model‑Context‑Protocol (MCP)‑Servern zum Auffinden und Verwenden benutzerdefinierter Tools. Qwen Code versucht, eine Verbindung zu jedem konfigurierten MCP‑Server herzustellen, um verfügbare Tools zu erkennen. Wenn mehrere MCP‑Server ein Tool mit demselben Namen bereitstellen, werden die Toolnamen mit dem von Ihnen in der Konfiguration definierten Server‑Alias versehen (z. B. serverAlias__actualToolName), um Konflikte zu vermeiden. Beachten Sie, dass das System aus Kompatibilitätsgründen bestimmte Schemaeigenschaften aus MCP‑Tooldefinitionen entfernen kann. Mindestens eines von command, url oder httpUrl muss angegeben werden. Wenn mehrere angegeben werden, gilt folgende Prioritätsreihenfolge: httpUrl, dann url, dann command.

Telemetrie

Konfiguriert die Protokollierung und Metriksammlung für Qwen Code. Weitere Informationen finden Sie unter Telemetrie.

Beispiel settings.json

Hier ist ein Beispiel einer settings.json-Datei mit der verschachtelten Struktur, neu seit 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,
    "includeSensitiveSpanAttributes": false
  },
  "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 führt einen Verlauf der von Ihnen ausgeführten Shell-Befehle. Um Konflikte zwischen verschiedenen Projekten zu vermeiden, wird dieser Verlauf in einem projektspezifischen Verzeichnis innerhalb Ihres Benutzer-Home-Ordners gespeichert.

• Ort: ~/.qwen/tmp/<project_hash>/shell_history
  • <project_hash> ist ein eindeutiger Bezeichner, der aus dem Stammverzeichnis Ihres 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 authentifizierungsbezogene Variablen (wie OPENAI_*) und den empfohlenen Ansatz mit .qwen/.env siehe Authentifizierung.

Tabelle der Umgebungsvariablen

Befehlszeilenargumente

Direkt beim Ausführen der CLI übergebene Argumente können andere Konfigurationen für diese Sitzung überschreiben.

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

Tabelle der Befehlszeilenargumente

Kontextdateien (Hierarchischer Anweisungskontext)

Obwohl sie nicht streng zur Konfiguration des Verhaltens der CLI gehören, sind Kontextdateien (standardmäßig QWEN.md, aber über die Einstellung context.fileName konfigurierbar) entscheidend für die Konfiguration des Anweisungskontexts (auch als “Speicher” bezeichnet). Diese leistungsstarke Funktion ermöglicht es Ihnen, projektspezifische Anweisungen, Codierungsstilrichtlinien oder andere relevante Hintergrundinformationen an die KI zu geben, wodurch ihre Antworten maßgeschneiderter und genauer auf Ihre Bedürfnisse zugeschnitten werden. Die CLI enthält UI-Elemente, wie z. B. einen Indikator in der Fußzeile, der die Anzahl der geladenen Kontextdateien anzeigt, um Sie über den aktiven Kontext zu informieren.

• Zweck: Diese Markdown-Dateien enthalten Anweisungen, Richtlinien oder Kontext, den das Qwen-Modell während Ihrer Interaktionen kennen soll. Das System ist darauf ausgelegt, diesen Anweisungskontext hierarchisch zu verwalten.

Beispiel für den Inhalt einer Kontextdatei (z. B. QWEN.md)

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

# Projekt: Meine geniale TypeScript-Bibliothek

## Allgemeine Anweisungen:
- Generiere neuen TypeScript-Code bitte gemäß dem bestehenden Codierungsstil.
- Stelle sicher, dass alle neuen Funktionen und Klassen JSDoc-Kommentare haben.
- Bevorzuge funktionale Programmierparadigmen, wo angemessen.
- Der gesamte Code sollte mit TypeScript 5.0 und Node.js 22+ kompatibel sein.

## Codierungsstil:
- Verwende 2 Leerzeichen für die Einrückung.
- Schnittstellennamen sollten mit `I` beginnen (z. B. `IUserService`).
- Private Klassenmitglieder sollten mit einem Unterstrich (`_`) beginnen.
- Verwende immer strikte Gleichheit (`===` und `!==`).

## Spezifische Komponente: `src/api/client.ts`
- Diese Datei verwaltet alle ausgehenden API-Anfragen.
- Wenn neue API-Aufruffunktionen hinzugefügt werden, stelle sicher, dass sie robuste Fehlerbehandlung und Protokollierung enthalten.
- Verwende das vorhandene `fetchWithRetry`-Dienstprogramm für alle GET-Anfragen.

## Bezüglich Abhängigkeiten:
- Vermeide die Einführung neuer externer Abhängigkeiten, es sei denn, es ist unbedingt notwendig.
- Wenn eine neue Abhängigkeit erforderlich ist, gib bitte den Grund an.

Dieses Beispiel zeigt, wie Sie allgemeinen Projektkontext, spezifische Codierungskonventionen und sogar Notizen zu bestimmten Dateien oder Komponenten bereitstellen können. Je relevanter und präziser Ihre Kontextdateien sind, desto besser kann die KI Sie unterstützen. Projektspezifische Kontextdateien werden dringend empfohlen, um Konventionen und Kontext festzulegen.

• Hierarchisches Laden und Vorrang: Die CLI implementiert ein hierarchisches Speichersystem, indem sie Kontextdateien (z. B. QWEN.md) von mehreren Speicherorten lädt. Inhalte aus Dateien, die in dieser Liste weiter unten stehen (spezifischer), überschreiben oder ergänzen in der Regel Inhalte aus Dateien weiter oben (allgemeiner). Die genaue Verkettungsreihenfolge und der endgültige Kontext können über das /memory-Dialogfeld eingesehen werden. Die typische Ladereihenfolge ist:
  1. Globale Kontextdatei:
     • Speicherort: ~/.qwen/<konfigurierter-Kontextdateiname> (z. B. ~/.qwen/QWEN.md in Ihrem Benutzerhome-Verzeichnis).
     • Gültigkeitsbereich: Stellt Standardanweisungen für alle Ihre Projekte bereit.
  2. Projektstamm & übergeordnete Kontextdateien:
     • Speicherort: Die CLI sucht im aktuellen Arbeitsverzeichnis und dann in jedem übergeordneten Verzeichnis bis zum Projektstamm (identifiziert durch einen .git-Ordner) oder Ihrem Home-Verzeichnis nach der konfigurierten Kontextdatei.
     • Gültigkeitsbereich: 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 ihre Herkunft und den Pfad angeben) und als Teil des System-Prompts bereitgestellt. Die CLI-Fußzeile zeigt die Anzahl der geladenen Kontextdateien an und gibt Ihnen so einen schnellen visuellen Hinweis auf den aktiven Anweisungskontext.
• Importieren von Inhalten: Sie können Ihre Kontextdateien modularisieren, indem Sie andere Markdown-Dateien mit der Syntax @pfad/zu/datei.md importieren. Weitere Details finden Sie in der Speicher-Dokumentation.
• Befehle zur Speicherverwaltung:
  • Verwenden Sie /memory, um das Speicherverwaltungsdialogfeld zu öffnen.
  • Aktualisieren Sie den Speicher über das Dialogfeld, um Kontextdateien von allen konfigurierten Speicherorten erneut zu scannen und zu laden.
  • Die vollständigen Details zum Befehl /memory finden Sie in der Befehls-Dokumentation.

Durch das Verständnis und die Nutzung dieser Konfigurationsebenen und der hierarchischen Natur von Kontextdateien können Sie den Speicher der KI effektiv verwalten und die Antworten von Qwen Code auf Ihre spezifischen Anforderungen und Projekte zuschneiden.

Sandbox

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

Sandbox ist standardmäßig deaktiviert, aber Sie können sie auf verschiedene Weise aktivieren:

• Verwenden des Flags --sandbox oder -s.
• Setzen der Umgebungsvariablen QWEN_SANDBOX.
• 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 ü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-, Schreib- und Bearbeitungswerkzeuge mit den Berechtigungen des aktuellen Prozesses ausführen – Qwen Code gibt in diesem Fall eine Warnung auf stderr aus. Unterdrücken Sie diese mit QWEN_CODE_SUPPRESS_YOLO_WARNING=1, sobald Sie den Kompromiss geprüft haben. Standardmäßig verwendet es ein vorgefertigtes Docker-Image qwen-code-sandbox.

Für projektspezifische Sandbox-Anforderungen können Sie im Stammverzeichnis Ihres Projekts eine benutzerdefinierte Dockerdatei unter .qwen/sandbox.Dockerfile erstellen. Diese Dockerdatei 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 existiert, können Sie beim Ausführen von Qwen Code die Umgebungsvariable BUILD_SANDBOX verwenden, um automatisch das benutzerdefinierte Sandbox-Image zu erstellen:

BUILD_SANDBOX=1 qwen -s

Nutzungsstatistiken

Um Qwen Code zu verbessern, sammeln wir anonymisierte Nutzungsstatistiken. Diese Daten helfen uns zu verstehen, wie die CLI verwendet wird, häufige Probleme zu identifizieren und neue Funktionen zu priorisieren.

Was wir sammeln:

• Tool-Aufrufe: Wir protokollieren die Namen der aufgerufenen Tools, ob sie erfolgreich sind oder fehlschlagen und wie lange sie zur Ausführung benötigen. Wir sammeln 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 sammeln nicht den Inhalt der Eingabeaufforderungen oder Antworten.
• Sitzungsinformationen: Wir sammeln Informationen über die Konfiguration der CLI, wie die aktivierten Tools und den Genehmigungsmodus.

Was wir NICHT sammeln:

• Personenbezogene Daten (PII): Wir sammeln keine persönlichen Informationen wie Ihren Namen, Ihre E-Mail-Adresse oder API-Schlüssel.
• Inhalt von Eingabeaufforderungen und Antworten: Wir protokollieren nicht den Inhalt Ihrer Eingabeaufforderungen oder die Antworten des Modells.
• Dateiinhalte: Wir protokollieren nicht den Inhalt von Dateien, die von der CLI gelesen oder geschrieben werden.

So deaktivieren Sie die Datenerfassung:

Sie können die Sammlung von Nutzungsstatistiken jederzeit deaktivieren, indem Sie die Eigenschaft usageStatisticsEnabled unter der Kategorie privacy in Ihrer settings.json-Datei auf false setzen:

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