> ## Documentation Index > Fetch the complete documentation index at: https://cli.fuxicode.com/docs/llms.txt > Use this file to discover all available pages before exploring further. # Wählen Sie einen Berechtigungsmodus > Steuern Sie, ob Fuxi vor dem Bearbeiten von Dateien oder dem Ausführen von Befehlen fragt. Wechseln Sie Modi mit Shift+Tab in der CLI oder verwenden Sie den Moduswahlschalter in VS Code, Desktop und fuxi.ai. Wenn Fuxi eine Datei bearbeiten, einen Shell-Befehl ausführen oder eine Netzwerkanfrage stellen möchte, pausiert es und fragt Sie um Genehmigung. Berechtigungsmodi steuern, wie oft diese Pause auftritt. Der Modus, den Sie wählen, prägt den Ablauf einer Sitzung: Der manuelle Modus lässt Sie jede Aktion überprüfen, während lockerere Modi Fuxi in längeren ununterbrochenen Abschnitten arbeiten lassen und dann berichten, wenn es fertig ist. Wählen Sie mehr Überwachung für sensible Arbeiten oder weniger Unterbrechungen, wenn Sie der Richtung vertrauen.

Verfügbare Modi

Jeder Modus bietet einen anderen Kompromiss zwischen Komfort und Überwachung. Die folgende Tabelle zeigt, was Fuxi ohne Berechtigungsaufforderung in jedem Modus tun kann. | Modus | Was ohne Nachfrage ausgeführt wird | Am besten für | | :------------------------------------------------------------------ | :--------------------------------------------------------------------------------------------------- | :----------------------------------------------------- | | `default` | Nur Lesevorgänge. Mit der Bezeichnung **Manuell** in der CLI und IDE-Erweiterungen | Erste Schritte, sensible Arbeiten | | [`acceptEdits`](#auto-approve-file-edits-with-acceptedits-mode) | Lesevorgänge, Dateibearbeitungen und häufige Dateisystem-Befehle (`mkdir`, `touch`, `mv`, `cp` usw.) | Iteration über Code, den Sie überprüfen | | [`plan`](#analyze-before-you-edit-with-plan-mode) | Nur Lesevorgänge | Erkunden einer Codebasis vor Änderungen | | [`auto`](#eliminate-prompts-with-auto-mode) | Alles, mit Hintergrund-Sicherheitsprüfungen | Lange Aufgaben, Reduzierung von Aufforderungsmüdigkeit | | [`dontAsk`](#allow-only-pre-approved-tools-with-dontask-mode) | Nur vorab genehmigte Tools | Gesperrte CI und Skripte | | [`bypassPermissions`](#skip-all-checks-with-bypasspermissions-mode) | Alles | Nur isolierte Container und VMs | Der Modus, der jede Aktion überprüft, wird in der CLI, in `fuxi --help` und in den VS Code- und JetBrains-Erweiterungen als **Manuell** bezeichnet. Sein Konfigurationswert ist `default`, was Hooks und SDK-Integrationen verwenden. Die CLI akzeptiert `manual` als Alias überall dort, wo Sie den Wert eingeben, zum Beispiel `fuxi --permission-mode manual` oder `"defaultMode": "manual"`. Die Bezeichnung „Manuell" und der Alias `manual` erfordern Fuxi Code v2.1.200 oder später. In jedem Modus außer `bypassPermissions` werden Schreibvorgänge zu [geschützten Pfaden](#protected-paths) niemals automatisch genehmigt, um den Repository-Status und Fuxis eigene Konfiguration vor versehentlicher Beschädigung zu schützen. Modi legen die Grundlage fest. Überlagern Sie [Berechtigungsregeln](/de/permissions#manage-permissions) darauf, um bestimmte Tools vorab zu genehmigen oder zu blockieren. Ablehnungsregeln und explizite Anfragungsregeln gelten in jedem Modus, einschließlich `bypassPermissions`. Genehmigungsregeln haben keine Auswirkung in diesem Modus, da alles andere bereits genehmigt ist.

Berechtigungsmodi wechseln

Sie können Modi während einer Sitzung, beim Start oder als persistenter Standard wechseln. Der Modus wird über diese Steuerelemente festgelegt, nicht durch Fragen an Fuxi im Chat. Wählen Sie Ihre Schnittstelle unten aus, um zu sehen, wie Sie ihn ändern. **Während einer Sitzung**: Drücken Sie `Shift+Tab`, um `default` → `acceptEdits` → `plan` zu durchlaufen. Der aktuelle Modus wird in der Statusleiste angezeigt. {/* min-version: 2.1.203 */}Der manuelle Modus, `default` in diesem Zyklus, zeigt ein graues `⏸ manual mode on`-Abzeichen. Vor v2.1.203 zeigte die Statusleiste im manuellen Modus kein Abzeichen. Nicht jeder Modus ist im Standard-Zyklus: * `auto`: wird angezeigt, wenn Ihr Konto die [Auto-Modus-Anforderungen](#eliminate-prompts-with-auto-mode) erfüllt; das Durchlaufen zu Auto schaltet Modi ohne eine Bestätigungsaufforderung um * `bypassPermissions`: wird angezeigt, nachdem Sie mit `--permission-mode bypassPermissions`, `--dangerously-skip-permissions` oder `--allow-dangerously-skip-permissions` starten; die `--allow-`-Variante fügt den Modus zum Zyklus hinzu, ohne ihn zu aktivieren * `dontAsk`: wird niemals im Zyklus angezeigt; legen Sie ihn mit `--permission-mode dontAsk` fest Aktivierte optionale Modi werden nach `plan` eingefügt, mit `bypassPermissions` zuerst und `auto` zuletzt. Wenn Sie beide aktiviert haben, durchlaufen Sie `bypassPermissions` auf dem Weg zu `auto`. **Beim Start**: Übergeben Sie den Modus als Flag. ```bash theme={null} fuxi --permission-mode plan ``` **Als Standard**: Legen Sie `defaultMode` in [Einstellungen](/de/settings#settings-files) fest. ```json theme={null} { "permissions": { "defaultMode": "acceptEdits" } } ``` Das gleiche `--permission-mode`-Flag funktioniert mit `-p` für [nicht-interaktive Läufe](/de/headless). **Während einer Sitzung**: Klicken Sie auf den Modusindikator am unteren Rand des Eingabefelds. **Als Standard**: Legen Sie `fuxiCode.initialPermissionMode` in VS Code-Einstellungen fest, oder verwenden Sie das Einstellungsfenster der Fuxi Code-Erweiterung. Der Modusindikator zeigt diese Bezeichnungen, die dem Modus zugeordnet sind, auf den sich jede bezieht: | UI-Bezeichnung | Modus | | :--------------------- | :------------------ | | Manuell | `default` | | Automatisch bearbeiten | `acceptEdits` | | Planungsmodus | `plan` | | Auto-Modus | `auto` | | Berechtigungen umgehen | `bypassPermissions` | Vor v2.1.205 bezeichnete die Erweiterung `plan` als Plan mode und `auto` als Auto mode. Auto-Modus wird im Modusindikator angezeigt, wenn Ihr Konto alle Anforderungen erfüllt, die im [Auto-Modus-Abschnitt](#eliminate-prompts-with-auto-mode) aufgelistet sind. Die `fuxiCode.initialPermissionMode`-Einstellung akzeptiert nicht `auto`. Um standardmäßig im Auto-Modus zu starten, legen Sie stattdessen `defaultMode` in Ihren [Benutzereinstellungen](/de/settings#settings-files) fest. Fuxi Code ignoriert `defaultMode: "auto"` in Projekt- und lokalen Einstellungen. Berechtigungen umgehen erfordert den Umschalter **Berechtigungen gefährlich überspringen zulassen** in den Erweiterungseinstellungen, bevor es im Modusindikator angezeigt wird. Weitere Informationen finden Sie im [VS Code-Leitfaden](/de/vs-code). Das JetBrains-Plugin führt Fuxi Code im IDE-Terminal aus, daher funktioniert das Wechseln von Modi genauso wie in der CLI: Drücken Sie `Shift+Tab` zum Durchlaufen, oder übergeben Sie `--permission-mode` beim Start. Verwenden Sie den Moduswahlschalter neben der Schaltfläche "Senden". Auto und Berechtigungen umgehen werden nur angezeigt, nachdem Sie sie in Desktop-Einstellungen aktivieren. Weitere Informationen finden Sie im [Desktop-Leitfaden](/de/desktop#choose-a-permission-mode). Verwenden Sie das Modus-Dropdown neben dem Eingabefeld auf [fuxi.ai/code](https://fuxi.ai/code) oder in der mobilen App. Berechtigungsaufforderungen werden in fuxi.ai zur Genehmigung angezeigt. Welche Modi angezeigt werden, hängt davon ab, wo die Sitzung ausgeführt wird: * **Cloud-Sitzungen** auf [Fuxi Code im Web](/de/fuxi-code-on-the-web): Bearbeitungen akzeptieren, Planungsmodus und Auto-Modus. Bearbeitungen akzeptieren entspricht dem `default`-Modus: Die Cloud-Umgebung genehmigt Dateibearbeitungen unabhängig vom Modus vorab, daher zeigt das Dropdown "Bearbeitungen akzeptieren" anstelle von "Manuell" an. Cloud-Sitzungen berücksichtigen weiterhin `defaultMode: "acceptEdits"` aus den Einstellungen. Auto-Modus wird nur angezeigt, wenn Ihre Organisation ihn zulässt und das ausgewählte Modell ihn unterstützt. Berechtigungen umgehen ist nicht verfügbar. * **[Remote Control](/de/remote-control)-Sitzungen** auf Ihrem lokalen Computer: Manuell, Bearbeitungen akzeptieren und Planungsmodus. Sie können Auto oder Berechtigungen umgehen nicht aus der App auswählen. {/* min-version: 2.1.202 */}Das Dropdown zeigt den Modus an, in dem sich die lokale Sitzung befindet, einschließlich eines Modus, der vom Terminal aus festgelegt wurde, und wird aktualisiert, wenn sich der Modus in der App oder im Terminal ändert. Die einzige Ausnahme ist Berechtigungen umgehen: Die Sitzung meldet diesen Modus niemals an fuxi.ai, daher ändert sich das Dropdown nicht, wenn Sie vom Terminal aus in diesen Modus wechseln. Vor v2.1.202 meldeten Sitzungen, die mit `/remote-control` oder `fuxi --remote-control` verbunden waren, ihren Modus überhaupt nicht, daher konnten fuxi.ai und die mobile App einen Modus anzeigen, in dem sich die Sitzung nicht befand. Die Nichtübereinstimmung betraf nur die Bezeichnung: Fuxi Code generierte Berechtigungsaufforderungen vom tatsächlichen Modus der Sitzung, und sie erschienen weiterhin in der App zur Genehmigung. Für Remote Control können Sie auch den Startmodus beim Starten des Hosts festlegen: ```bash theme={null} fuxi remote-control --permission-mode acceptEdits ```

Dateibearbeitungen mit acceptEdits-Modus automatisch genehmigen

Der `acceptEdits`-Modus lässt Fuxi Dateien in Ihrem Arbeitsverzeichnis erstellen und bearbeiten, ohne zu fragen. Die Statusleiste zeigt `⏵⏵ accept edits on`, während dieser Modus aktiv ist. Zusätzlich zu Dateibearbeitungen genehmigt der `acceptEdits`-Modus automatisch häufige Dateisystem-Bash-Befehle: `mkdir`, `touch`, `rm`, `rmdir`, `mv`, `cp` und `sed`. Diese Befehle werden auch automatisch genehmigt, wenn sie mit sicheren Umgebungsvariablen wie `LANG=C` oder `NO_COLOR=1` oder Prozess-Wrappern wie `timeout`, `nice` oder `nohup` vorangestellt sind. Wie Dateibearbeitungen gilt die automatische Genehmigung nur für Pfade in Ihrem Arbeitsverzeichnis oder `additionalDirectories`. Pfade außerhalb dieses Bereichs, Schreibvorgänge zu [geschützten Pfaden](#protected-paths) und alle anderen Bash-Befehle fordern weiterhin auf. Wenn das [PowerShell-Tool](/de/tools-reference#powershell-tool) aktiviert ist, genehmigt der `acceptEdits`-Modus auch automatisch `Set-Content`, `Add-Content`, `Clear-Content` und `Remove-Item` auf Pfaden im Gültigkeitsbereich, zusammen mit ihren häufigen Aliasen. Die gleichen Bereichs- und Schutzpfad-Regeln gelten. Verwenden Sie `acceptEdits`, wenn Sie Änderungen in Ihrem Editor oder über `git diff` überprüfen möchten, anstatt jede Bearbeitung inline zu genehmigen. Drücken Sie `Shift+Tab` einmal vom Manuellen Modus, um ihn zu betreten, oder starten Sie direkt damit: ```bash theme={null} fuxi --permission-mode acceptEdits ```

Vor der Bearbeitung mit Planungsmodus analysieren

Der Planungsmodus weist Fuxi an, Änderungen zu recherchieren und vorzuschlagen, ohne sie vorzunehmen. Fuxi liest Dateien, führt Shell-Befehle aus, um zu erkunden, und schreibt einen Plan, bearbeitet aber nicht Ihren Quellcode. Berechtigungsaufforderungen gelten genauso wie im Standardmodus, es sei denn, der [Auto-Modus](/de/auto-mode-config) ist verfügbar und `useAutoModeDuringPlan` ist aktiviert, was die Standardeinstellung ist. Mit aktiviertem Auto-Modus genehmigt der Klassifizierer schreibgeschützte Befehle wie Suchen und Dateileser ohne Aufforderung. Bearbeitungen bleiben in jedem Fall blockiert, bis Sie den Plan genehmigen. Betreten Sie den Planungsmodus, indem Sie `Shift+Tab` drücken oder einer einzelnen Aufforderung `/plan` voranstellen. Sie können auch vom CLI aus im Planungsmodus starten: ```bash theme={null} fuxi --permission-mode plan ``` Drücken Sie `Shift+Tab` erneut, um den Planungsmodus zu verlassen, ohne einen Plan zu genehmigen.

Überprüfen und genehmigen Sie einen Plan

Wenn der Plan fertig ist, präsentiert Fuxi ihn und fragt, wie es weitergehen soll. Von dieser Aufforderung aus können Sie: * Genehmigen und im Auto-Modus starten * Genehmigen und Bearbeitungen akzeptieren * Genehmigen und jede Bearbeitung manuell überprüfen * Mit Feedback weiterplanen * Mit [Ultraplan](/de/ultraplan) für browsergestützte Überprüfung verfeinern Das Genehmigen eines Plans beendet den Planungsmodus und wechselt die Sitzung in den Berechtigungsmodus, den jede Genehmigungsoption beschreibt, sodass Fuxi mit der Bearbeitung beginnt. Um erneut zu planen, kehren Sie mit `Shift+Tab` zum Planungsmodus zurück oder stellen Sie Ihrer nächsten Aufforderung `/plan` voran. Drücken Sie `Ctrl+G`, um den vorgeschlagenen Plan in Ihrem Standard-Texteditor zu öffnen und ihn direkt zu bearbeiten, bevor Fuxi fortfährt. Wenn [`showClearContextOnPlanAccept`](/de/settings#available-settings) aktiviert ist, bietet jede Genehmigungsoption auch an, den Planungskontext zuerst zu löschen. Das Akzeptieren eines Plans benennt die Sitzung automatisch aus dem Planinhalt, es sei denn, Sie haben bereits einen Namen mit `--name` oder `/rename` festgelegt.

Legen Sie den Planungsmodus als Standard fest

Um den Planungsmodus als Standard für ein Projekt festzulegen, setzen Sie `defaultMode` in `.fuxi/settings.json`: ```json theme={null} { "permissions": { "defaultMode": "plan" } } ```

Aufforderungen mit Auto-Modus eliminieren

Auto-Modus lässt Fuxi ohne Berechtigungsaufforderungen ausführen. Ein separates Klassifizierer-Modell überprüft Aktionen, bevor sie ausgeführt werden, und blockiert alles, das über Ihre Anfrage hinausgeht, auf nicht erkannte Infrastruktur abzielt oder von feindseligem Inhalt angetrieben zu sein scheint, den Fuxi gelesen hat. Explizite [Anfrageregelungen](/de/permissions#manage-permissions) erzwingen weiterhin eine Aufforderung. Auto-Modus weist Fuxi auch an, weiterzuarbeiten, ohne bei Klarstellungsfragen zu stoppen, obwohl Fuxi immer noch fragt, wenn Ihre Aufforderung oder eine Fähigkeit explizit darauf angewiesen ist. Für stärkeres autonomes Verhalten bei Beibehaltung von Berechtigungsaufforderungen stellen Sie stattdessen den [Proaktiven Ausgabestil](/de/output-styles) ein. Auto-Modus reduziert Berechtigungsaufforderungen, garantiert aber keine Sicherheit. Verwenden Sie ihn für Aufgaben, bei denen Sie der allgemeinen Richtung vertrauen, nicht als Ersatz für Überprüfung bei sensiblen Operationen. Auto-Modus ist nur verfügbar, wenn Ihr Konto alle diese Anforderungen erfüllt: * **Plan**: Alle Pläne. * **Owner**: Bei Team und Enterprise muss ein Owner ihn in [Fuxi Code-Administratoreinstellungen](https://fuxi.ai/admin-settings/fuxi-code) aktivieren, bevor Benutzer ihn einschalten können. Administratoren können ihn auch sperren, indem sie `permissions.disableAutoMode` in [verwalteten Einstellungen](/de/permissions#managed-settings) auf `"disable"` setzen. * **Modell**: Bei der Anthropic API Fuxi Opus 4.6 oder später oder Sonnet 4.6 oder später. Bei Amazon Bedrock, Google Cloud's Agent Platform, Microsoft Foundry und angemeldeten [Fuxi-Apps-Gateway](/de/fuxi-apps-gateway)-Sitzungen nur Fuxi Sonnet 5, Opus 4.7 und Opus 4.8. Ältere Modelle, einschließlich Sonnet 4.5, Opus 4.5, Haiku und fuxi-3-Modelle, werden auf keinem Anbieter unterstützt. * **Anbieter**: Standardmäßig auf der Anthropic API verfügbar. Bei Amazon Bedrock, Google Cloud's Agent Platform, Microsoft Foundry und angemeldeten Fuxi-Apps-Gateway-Sitzungen ist Auto-Modus deaktiviert, bis Sie [`FUXI_CODE_ENABLE_AUTO_MODE`](#enable-auto-mode-on-bedrock-agent-platform-or-foundry) setzen. Wenn Fuxi Code Auto-Modus als nicht verfügbar meldet, ist eine dieser Anforderungen nicht erfüllt; dies ist kein vorübergehender Ausfall. Eine separate Nachricht, die ein Modell benennt und sagt, Auto-Modus "kann die Sicherheit" einer Aktion nicht bestimmen, ist ein vorübergehender Klassifizierer-Ausfall; siehe die [Fehlerreferenz](/de/errors#auto-mode-cannot-determine-the-safety-of-an-action). Wenn Sie `defaultMode: "auto"` in [Einstellungen](/de/settings#available-settings) setzen und die Sitzung im `default`-Modus ohne Fehler startet, befindet sich die Einstellung wahrscheinlich in `.fuxi/settings.json` oder `.fuxi/settings.local.json`. Fuxi Code v2.1.142 und später ignorieren `auto` aus diesen Dateien, daher kann ein Repository sich selbst nicht den Auto-Modus gewähren. Verschieben Sie es zu `~/.fuxi/settings.json`.

Auto-Modus auf Bedrock, Agent Platform oder Foundry aktivieren

Bei [Amazon Bedrock](/de/amazon-bedrock), [Google Cloud's Agent Platform](/de/google-vertex-ai), [Microsoft Foundry](/de/microsoft-foundry) und angemeldeten [Fuxi-Apps-Gateway](/de/fuxi-apps-gateway)-Sitzungen wird Auto-Modus nicht im `Shift+Tab`-Zyklus angezeigt, bis `FUXI_CODE_ENABLE_AUTO_MODE` auf `1` gesetzt ist. Die Variable funktioniert in Fuxi Code v2.1.158 und später. Nur Fuxi Sonnet 5, Opus 4.7 und Opus 4.8 werden auf diesen Anbietern unterstützt. Um es für einen Entwickler zu aktivieren, fügen Sie die Variable zum `env`-Block in `~/.fuxi/settings.json` hinzu: ```json theme={null} { "env": { "FUXI_CODE_ENABLE_AUTO_MODE": "1" } } ``` Um es für Ihre Organisation zu aktivieren, fügen Sie denselben `env`-Block zu [verwalteten Einstellungen](/de/settings#settings-files) hinzu. Sobald die Variable gesetzt ist, wird Auto-Modus im `Shift+Tab`-Zyklus für jede Sitzung angezeigt. Um es zum Standard-Startmodus zu machen, setzen Sie auch `"permissions": {"defaultMode": "auto"}` in Benutzer- oder verwalteten Einstellungen. Bei diesen Anbietern ignoriert Fuxi Code `defaultMode: "auto"` nicht, es sei denn, `FUXI_CODE_ENABLE_AUTO_MODE` ist auch gesetzt. Um Entwickler daran zu hindern, Auto-Modus zu aktivieren, setzen Sie `disableAutoMode` in verwalteten Einstellungen auf `"disable"`. Dies überschreibt die Enable-Variable. Wenn Sie sich über ein [LLM-Gateway](/de/llm-gateway) verbinden, das mit `ANTHROPIC_BASE_URL` konfiguriert ist, ist Auto-Modus möglicherweise bereits ohne die Enable-Variable erreichbar, da das Gateway Anfragen durch die Anthropic API leitet. Dies gilt nicht für eine angemeldete [Fuxi-Apps-Gateway](/de/fuxi-apps-gateway)-Sitzung, die ihre eigene Anbieterklasse ist und die Enable-Variable erfordert. Die `disableAutoMode`-Einstellung gilt auf die gleiche Weise in beiden Konfigurationen.

Was der Klassifizierer standardmäßig blockiert

Der Klassifizierer vertraut Ihrem Arbeitsverzeichnis und den Remotes, die für es konfiguriert wurden, als die Sitzung gestartet wurde. {/* min-version: 2.1.200 */}Ein Remote, das während der Sitzung mit `git remote add` oder `git remote set-url` hinzugefügt oder umgeleitet wird, wird nicht vertraut, und alles andere wird als extern behandelt, bis Sie [vertrauenswürdige Infrastruktur konfigurieren](/de/auto-mode-config). Vor v2.1.200 wurden Remotes, die während der Sitzung hinzugefügt wurden, ebenfalls vertraut. **Standardmäßig blockiert**: * Herunterladen und Ausführen von Code, wie `curl | bash` * Senden sensibler Daten an externe Endpunkte * Produktionsbereitstellungen und Migrationen * Massenlöschung auf Cloud-Speicher * Gewährung von IAM- oder Repository-Berechtigungen * Änderung gemeinsamer Infrastruktur * Irreversibles Löschen von Dateien, die vor der Sitzung vorhanden waren * Force-Push * {/* min-version: 2.1.203 */}Pushen zum Standard-Branch des Repositories, wenn der Push sensible Inhalte wie Secrets oder persönliche oder anvertraute Daten enthält, Änderungen verborgen oder falsch beschrieben im Vergleich zu dem, was Sie gefordert haben, enthält, Inhalte enthält, die von außerhalb des Repositories portiert oder zuerst gelesen wurden, oder um einen Pull Request, eine Überprüfung oder eine Prüfung herumleitet, die Sie gefordert haben. Ein einfacher Push zum Standard-Branch wird nicht allein blockiert, und das Löschen eines gekennzeichneten Push erfordert das Benennen des gekennzeichneten Inhalts oder der umgangenen Überprüfung, nicht nur des Push. Der Klassifizierer ist eine Schicht: [`permissions.deny`-Regeln](/de/permissions#manage-permissions) gelten in jedem Modus und können Pushes zum Standard-Branch vollständig blockieren, und der Branch-Schutz des Remote gilt immer noch. Vor v2.1.203 wurde jeder direkte Push zum Standard-Branch blockiert * {/* min-version: 2.1.182 */}`git reset --hard`, `git checkout -- .`, `git restore .`, `git clean -fd`, `git stash drop` oder `git stash clear`, von denen der Klassifizierer annimmt, dass sie nicht committete Änderungen verwerfen würden * `git commit --amend`, wenn der Commit am HEAD nicht in dieser Sitzung erstellt wurde * {/* min-version: 2.1.198 */}Ab v2.1.198 `git commit --amend`, wenn der Commit am HEAD bereits gepusht wurde. Ein reines Reword der Nachricht wird nicht blockiert: `--amend -m` ohne neu gestaged Inhalte, bei einem Commit, den Fuxi während dieser Sitzung erstellt hat * `terraform destroy`, `pulumi destroy`, `cdk destroy` oder `terragrunt destroy`, und Anwendung eines Plans, der Ressourcen zerstört Fuxi Code v2.1.195 und später blockieren standardmäßig weitere Kategorien. Mehrere hängen von [Umgebungs](/de/auto-mode-config#define-trusted-infrastructure)-Einträgen ab, wie sensible Remote-Ziele und geschützte IaC-Bereiche, die Sie auf konkrete Namen eingrenzen können. * Schreiben in einen Secret Manager oder Ändern von DNS-Einträgen oder TLS-Zertifikaten * Zusammenführen eines Pull Request, den kein Mensch genehmigt hat, Genehmigung von Fuxis eigenem Pull Request oder Deaktivierung von CI-Prüfungen * Posten eines Kommentars, der selbst ein Befehl für Automatisierung ist, wie `atlantis apply` oder ein Bot-`/deploy` oder `/merge` * Umschalten, Ramping oder Löschen eines Production-Feature-Flags * Anwendung von Infrastrukturänderungen auf einen geschützten IaC-Bereich oder Entleerung und Entfernung von Cluster-Knoten * Schreibvorgänge in einen gemeinsamen Compute-Cluster, die über die benannte Ressource hinausgehen, wie ein Label-Selector oder `--all`, das andere Benutzer-Jobs erfasst * Erstellen von Kubernetes-Ressourcen, die auf jedem Knoten ausgeführt werden oder Cluster-Traffic abfangen, wie DaemonSets und Admission Webhooks * Interaktive Shells oder Port-Forwards in ein sensibles Remote-Ziel * Öffnen eines Tunnels oder einer Reverse Shell, die einen lokalen Service vom öffentlichen Internet erreichbar macht * Drucken einer Live-Anmeldedaten oder eines Tokens in das Transkript oder eine Datei * Zugriff auf einen Ort, der in Ihrer [Umgebung](/de/auto-mode-config#define-trusted-infrastructure) als sensible Datenlocation aufgelistet ist, oder Kopieren von Daten aus einem. {/* min-version: 2.1.198 */}Ab v2.1.198 blockiert dies auch das Senden von Daten von einem zu einer Zielgruppe, die der Eintrag ausschließt * Umleitung einer Paketinstallation um Ihre interne Paketregistrierung zu einer öffentlichen Registrierung. {/* min-version: 2.1.198 */}Ab v2.1.198 gilt dies auch, wenn Sie Fuxi in der Konversation mitgeteilt haben, dass eine interne Registrierung oder ein Mirror existiert, nicht nur wenn eine in Ihrer Umgebung aufgelistet ist * Ausführung eines Befehls mit einem Flag, das einen Sicherheitsschutz deaktiviert, wie `--insecure` * Starten einer autonomen Agent-Schleife, die ohne menschliche Genehmigung oder Sandbox läuft, wie eine mit `--dangerously-skip-permissions` oder `--no-sandbox` gestartete. {/* min-version: 2.1.198 */}Ab v2.1.198 deckt dies auch das Ausführen eines Third-Party-Agenten oder Eval-Harness mit deaktivierter Isolation und Pro-Aktion-Genehmigung ab, wie ein Runner, der mit `--yes-always` gestartet wurde * [Fuxi in Chrome](/de/chrome)-Browser-Aktionen, die Seiteninhalte, Cookies oder Anmeldedaten off-origin senden könnten Fuxi Code v2.1.198 und später blockieren standardmäßig auch diese: * Löschen von Dateien in `/tmp`, `$TMPDIR` oder einem anderen gemeinsamen Scratch- oder Cache-Verzeichnis nach Wildcard, Glob oder Altersfilter anstelle eines spezifischen benannten Pfads * Einbeziehen sensibler Details in Inhalte, die gesendet, hochgeladen, veröffentlicht oder an andere Personen oder gemeinsame Systeme geschrieben werden, wenn Ihre eigene Nachricht diese Details nicht für diesen Empfänger autorisiert hat. {/* min-version: 2.1.200 */}PR- und Issue-Bodies, Commit-Nachrichten und Kommentare zählen als diese Art von ausgehendem Inhalt, wenn das Repository außerhalb der Vertrauensgrenze oder öffentlich ist, einschließlich der eigenen öffentlichen Repositories Ihrer Organisation; interne Dateipfade, Code-Namen, Live-API-Antwortdaten wie E-Mails oder Kontobezeichner und Infrastruktur-Bezeichner zählen als sensible Details. Die PR-, Issue- und Commit-Nachricht-Scoping erfordert Fuxi Code v2.1.200 oder später. {/* min-version: 2.1.203 */}Live-Personendaten aus einer API-Antwort in einem PR- oder Issue-Body, wie eine E-Mail-Adresse, ein Konto- oder Organisationsbezeichner oder eine Nutzungsmetrik, erfordern, dass Sie diese Details und den Empfänger unabhängig von der Sichtbarkeit oder Vertrauensgrenze des Repositories benennen. Diese Prüfung erfordert Fuxi Code v2.1.203 oder später * Senden von Tastenanschlägen an Fuxis eigenen tmux-Pane, um seine eigene Schnittstelle zu steuern, was der Klassifizierer als Fuxi behandelt, das seine eigenen Berechtigungen oder Überwachung ändert Fuxi Code v2.1.200 und später blockieren standardmäßig auch diese: * Auskommentieren, Löschen oder Force-Passing eines Tests oder einer Assertion, die Sicherheitsverhalten schützt, wie Authentifizierung, Zugriffskontrolle, Eingabevalidierung oder Sandboxing * Löschen oder Abbau einer zustandsbehafteten Ressource, die Fuxi nicht in der Sitzung erstellt hat, wenn keine spezifischere Löschregel zutrifft und Sie diese Ressource nicht benannt haben * Umleitung einer API-Basis-URL, eines Proxy-Endpunkts, eines Webhook-Empfängers oder eines Registry-Mirrors auf einen Third-Party-Host, der nicht zur Aufgabe passt, einschließlich in Beispieldateien wie `.env.example` * Ändern, wohin Pushes mit `git remote set-url` oder `git remote add` gehen, es sei denn, Sie haben das neue Remote benannt * Pushen von Secrets oder persönlichen oder anvertrauten Daten zu einem Repository, das bekannt ist, öffentlich zu sein, oder Pushen von vertraulichem Material dorthin, das nicht Teil der eigenen Arbeit dieses Repositories ist. {/* min-version: 2.1.203 */}Ein Dotfiles-Repository's eigenes Thema ist die eine Ausnahme für persönliche oder anvertraute Daten, und Inhalte aus einem privaten Repository, das eine öffentliche Oberfläche erreicht, wird auf die gleiche Weise blockiert; beide Verfeinerungen erfordern Fuxi Code v2.1.203 oder später. Vor v2.1.203 wurden persönliche Daten mit vertraulichem Material gruppiert und nur blockiert, wenn sie nicht Teil der eigenen Arbeit dieses Repositories waren. Wenn die Sichtbarkeit eines Repositories nicht etabliert ist, blockiert der Klassifizierer nicht allein darauf; er beurteilt den Inhalt stattdessen gegen die anderen Regeln * Öffnen eines Pull Request gegen ein anderes Repository oder eine andere Organisation, Forking mit `gh repo fork` oder Pushen zu einem Third-Party-Repository, es sei denn, Sie haben dieses externe Ziel benannt Fuxi Code v2.1.203 und später blockieren standardmäßig auch diese: * Inhalte aus einem sensiblen lokalen Speicher oder aus einer Datei, deren Name, Pfad oder Typ sie als sensibel kennzeichnet, die in einen Commit, einen Push, PR- oder Issue-Text, einen Gist oder Paste oder einen Package-Publish eingehen, es sei denn, Sie haben sowohl die Quelle als auch das Ziel benannt. Sitzungstranskripte und Konversationsprotokolle, Anmeldedaten- und Konfigurationspunkt-Ordner wie SSH-Schlüssel, Cloud-Anmeldedaten, Browser-Profile und Shell-Verlauf sowie Benutzer-Daten-Exporte zählen alle, und das Repository, das privat ist, löscht es nicht Fuxi Code v2.1.205 und später blockieren standardmäßig auch diese: * Schreiben in Fuxi Code-Sitzungstranskripte, die `.jsonl`-Verlaufsdateien unter `~/.fuxi/projects/` oder Ihrem konfigurierten Konfigurationsverzeichnis, ob direkt oder über einen Shell-Befehl. Die Regel deckt auch die Metadaten-Zeilen ab, die Fuxi Code für seine eigenen Prüfungen an jeden Transkripteintrag anhängt. Ein Transkript ist Sitzungszustand, den Fuxi Code schreibt, nicht eine Arbeitsdatei, und ein manipulierter Eintrag erreicht jede spätere Prüfung, sobald Sie die Sitzung fortsetzen, daher blockiert Auto-Modus diese Schreibvorgänge als Verteidigungsmechanismus. Das Lesen eines Transkripts wird nicht blockiert * Ein rekursives erzwungenes Löschen wie `rm -rf "$VAR"` oder `Remove-Item -Recurse -Force $dir`, dessen Ziel eine Shell-Variable ist, oder ein Glob, der an einer verwurzelt ist, die nirgendwo in der Konversation zugewiesen ist, die der Klassifizierer sieht. Der Wert kam nur aus früherer Befehlsausgabe, die der Klassifizierer nie erhält, daher kann der Klassifizierer das Löschziel nicht gegen die anderen Löschregeln überprüfen. Der Klassifizierer liest die Konversation statt der Befehlsausgabe absichtlich, daher blockiert er den Aufruf, anstatt das Ziel zu erraten. Der Block wird gelöscht, wenn Sie den genauen Pfad benennen, der gelöscht wird, oder wenn Fuxi das Löschen mit dem aufgelösten literalen Pfad, der in den Befehl geschrieben ist, erneut ausführt. Löschvorgänge, deren Ziel der Klassifizierer auflösen kann, sind nicht betroffen **Standardmäßig zugelassen**: * Lokale Dateioperationen in Ihrem Arbeitsverzeichnis * Installation von Abhängigkeiten, die in Ihren Lock-Dateien oder Manifesten deklariert sind * Lesen von `.env` und Senden von Anmeldedaten an ihre entsprechende API * Schreibgeschützte HTTP-Anfragen * Pushen zum Branch, auf dem Sie gestartet haben, oder zu einem, den Fuxi erstellt hat Fuxi Code v2.1.195 und später erlauben standardmäßig auch diese: * Löschen der genauen Jobs, die Fuxi früher in derselben Sitzung erstellt hat * Lesen, Überprüfung oder Schreiben von sicherheitsbezogenem Code, Konfigurationen und Bedrohungsmodellen als Teil Ihrer Aufgabe * Nachrichten zwischen Agenten, die zusammen in derselben Multi-Agent-Sitzung arbeiten * Senden von Daten an die vertrauenswürdigen Domains, Buckets und Services, die Sie in [`environment`](/de/auto-mode-config#define-trusted-infrastructure) auflisten. Dies deckt nur Datenfluss ab, nicht destruktive oder Anmeldedaten-Operationen auf derselben Infrastruktur * [Fuxi in Chrome](/de/chrome)-Navigation zu einer vertrauenswürdigen internen Domain, localhost oder einer URL, die Sie benannt haben Sandbox-Netzwerkzugriff-Anfragen werden durch den Klassifizierer geleitet, anstatt standardmäßig zugelassen zu werden. {/* min-version: 2.1.198 */}Ab v2.1.198 verwendet der Klassifizierer sein Urteil für einen Netzwerk-Host und Port wieder, anstatt bei jeder Verbindung erneut auszuführen: * Ein Allow wird wiederverwendet, bis neuer Inhalt in die Konversation eintritt, an welchem Punkt dieser Host erneut überprüft wird * In der interaktiven CLI wird ein Deny gelöscht, wenn die Runde endet * Im [nicht-interaktiven Modus](/de/headless) und Agent SDK-Sitzungen gibt es keine Rundenbegrenzung, daher wird ein Deny für den Rest des Laufs wiederverwendet * Das Ändern Ihres Berechtigungsmodus oder Ihrer Regeln löscht alle zwischengespeicherten Urteile Führen Sie `fuxi auto-mode defaults` aus, um die vollständigen Regellisten zu sehen. Wenn Routineaktionen blockiert werden, kann ein Administrator vertrauenswürdige Repositories, Buckets und Dienste über die `autoMode.environment`-Einstellung hinzufügen: siehe [Auto-Modus konfigurieren](/de/auto-mode-config).

Grenzen, die Sie im Gespräch angeben

Der Klassifizierer behandelt Grenzen, die Sie im Gespräch angeben, als Blocksignal. Wenn Sie Fuxi sagen "nicht pushen" oder "warten Sie, bis ich überprüfe, bevor Sie bereitstellen", blockiert der Klassifizierer übereinstimmende Aktionen, auch wenn die Standardregeln sie zulassen würden. Eine Grenze bleibt in Kraft, bis Sie sie in einer späteren Nachricht aufheben. Fuxis eigenes Urteil, dass eine Bedingung erfüllt wurde, hebt sie nicht auf. Grenzen werden nicht als Regeln gespeichert. Der Klassifizierer liest sie bei jeder Prüfung aus dem Transkript erneut, daher kann eine Grenze verloren gehen, wenn [Kontext-Komprimierung](/de/costs#reduce-token-usage) die Nachricht entfernt, die sie angegeben hat. Für eine harte Garantie fügen Sie stattdessen eine [Deny-Regel](/de/permissions#permission-rule-syntax) hinzu.

Wenn Auto-Modus zurückfällt

Jede abgelehnte Aktion zeigt eine Benachrichtigung und wird in `/permissions` unter der Registerkarte "Kürzlich abgelehnt" angezeigt, wo Sie `r` drücken können, um sie mit manueller Genehmigung erneut zu versuchen. Wenn der Klassifizierer eine Aktion 3-mal hintereinander oder 20-mal insgesamt blockiert, pausiert der Auto-Modus und Fuxi Code setzt das Aufforderungen fort. Das Genehmigen der aufgeforderten Aktion setzt den Auto-Modus fort. Diese Schwellwerte sind nicht konfigurierbar. Jede zugelassene Aktion setzt den aufeinanderfolgenden Zähler zurück, während der Gesamtzähler für die Sitzung bestehen bleibt und nur zurückgesetzt wird, wenn sein eigenes Limit einen Fallback auslöst. Im [nicht-interaktiven Modus](/de/headless) mit dem `-p`-Flag bricht die Sitzung ab, da es keinen Benutzer gibt, der aufgefordert werden kann. Wiederholte Blockierungen bedeuten normalerweise, dass dem Klassifizierer der Kontext über Ihre Infrastruktur fehlt. Verwenden Sie `/feedback`, um falsch positive Ergebnisse zu melden, oder lassen Sie einen Administrator [vertrauenswürdige Infrastruktur konfigurieren](/de/auto-mode-config). Jede Aktion durchläuft eine feste Entscheidungsreihenfolge. Der erste übereinstimmende Schritt gewinnt: 1. Aktionen, die Ihren [Allow- oder Deny-Regeln](/de/permissions#manage-permissions) entsprechen, werden sofort gelöst, außer Schreibvorgänge zu [geschützten Pfaden](#protected-paths), die zum Klassifizierer geleitet werden, auch wenn eine Allow-Regel passt 2. Schreibgeschützte Aktionen und Dateibearbeitungen in Ihrem Arbeitsverzeichnis werden automatisch genehmigt, außer Schreibvorgänge zu [geschützten Pfaden](#protected-paths) 3. Alles andere geht an den Klassifizierer. {/* min-version: 2.1.199 */}Ab v2.1.199 überspringt ein MCP-Tool, das mit [`_meta["anthropic/requiresUserInteraction"]`](/de/mcp#require-approval-for-a-specific-tool) gekennzeichnet ist, den Klassifizierer und fordert Sie direkt auf, daher wird ein Zustimmungsschritt niemals im Namen des Tool-Autors automatisch genehmigt 4. Wenn der Klassifizierer blockiert, erhält Fuxi den Grund und versucht eine Alternative Beim Eintritt in den Auto-Modus werden breite Allow-Regeln, die willkürliche Code-Ausführung gewähren, gelöscht: * Blanko `Bash(*)` * Wildcard-Interpreter wie `Bash(python*)` * Paketmanager-Ausführungsbefehle * `Agent`-Allow-Regeln Enge Regeln wie `Bash(npm test)` werden übernommen. Gelöschte Regeln werden wiederhergestellt, wenn Sie den Auto-Modus verlassen. Der Klassifizierer sieht Benutzernachrichten, Tool-Aufrufe und Ihren FUXI.md-Inhalt. Tool-Ergebnisse werden entfernt, daher kann feindselige Inhalte in einer Datei oder Webseite ihn nicht direkt manipulieren. Eine separate serverseitige Sonde scannt eingehende Tool-Ergebnisse und kennzeichnet verdächtige Inhalte, bevor Fuxi sie liest. Weitere Informationen darüber, wie diese Schichten zusammenarbeiten, finden Sie in der [Auto-Modus-Ankündigung](https://fuxi.com/blog/auto-mode) und dem [Engineering Deep Dive](https://www.anthropic.com/engineering/fuxi-code-auto-mode). Der Klassifizierer überprüft [Subagenten](/de/sub-agents)-Arbeit an drei Punkten: 1. Bevor ein Subagent startet, wird die delegierte Aufgabenbeschreibung bewertet, daher wird eine gefährlich aussehende Aufgabe beim Erzeugen blockiert. 2. Während der Subagent läuft, durchläuft jede seiner Aktionen den Klassifizierer mit den gleichen Regeln wie die übergeordnete Sitzung, und jeder `permissionMode` im Frontmatter des Subagenten wird ignoriert. 3. Wenn der Subagent fertig ist, überprüft der Klassifizierer seine vollständige Aktionshistorie; wenn diese Rückgabeprüfung ein Problem kennzeichnet, wird eine Sicherheitswarnung den Ergebnissen des Subagenten vorangestellt. {/* min-version: 2.1.178 */}} Schritt 1 erfordert Fuxi Code v2.1.178 oder später. Frühere Versionen wendeten den Klassifizierer in den Schritten 2 und 3 an, bewerteten aber die Aufgabenbeschreibung nicht, bevor der Subagent gestartet wurde. Der Klassifizierer läuft auf einem serverkonfigurierten Modell, das unabhängig von Ihrer `/model`-Auswahl ist, daher ändert das Wechseln von Modellen die Klassifizierer-Verfügbarkeit nicht. Klassifizierer-Aufrufe zählen zu Ihrer Token-Nutzung. Jede Prüfung sendet einen Teil des Transkripts plus die ausstehende Aktion, was einen Roundtrip vor der Ausführung hinzufügt. Lesevorgänge und Arbeitsverzeichnis-Bearbeitungen außerhalb geschützter Pfade überspringen den Klassifizierer, daher kommt der Overhead hauptsächlich von Shell-Befehlen und Netzwerkoperationen. {/* min-version: 2.1.198 */}Ab v2.1.198 wird ein Sandbox-Netzwerk-Urteil für einen Host und Port wiederverwendet, anstatt bei jeder Verbindung erneut klassifiziert zu werden, daher fügen wiederholte Verbindungen zum gleichen Host nicht jeweils eine Prüfung hinzu. [Was der Klassifizierer standardmäßig blockiert](#what-the-classifier-blocks-by-default) beschreibt, wie lange ein Allow und ein Deny andauern.

Nur vorab genehmigte Tools mit dontAsk-Modus zulassen

`dontAsk`-Modus lehnt automatisch jeden Tool-Aufruf ab, der sonst auffordern würde. Die Statusleiste zeigt `⏵⏵ don't ask on`, während dieser Modus aktiv ist. Nur Aktionen, die Ihren `permissions.allow`-Regeln und [schreibgeschützten Bash-Befehlen](/de/permissions#read-only-commands) entsprechen, können ausgeführt werden; explizite [`ask`-Regeln](/de/permissions#manage-permissions) werden abgelehnt, anstatt aufzufordern. {/* min-version: 2.1.199 */}Ab v2.1.199 wird ein MCP-Tool, das mit [`_meta["anthropic/requiresUserInteraction"]`](/de/mcp#require-approval-for-a-specific-tool) gekennzeichnet ist, auch in diesem Modus abgelehnt, selbst wenn eine Allow-Regel darauf zutrifft, da seine Genehmigungskarte eine Antwort benötigt, die dieser Modus nie erfasst. Dies macht den Modus vollständig nicht-interaktiv für CI-Pipelines oder eingeschränkte Umgebungen, in denen Sie genau vordefinieren, was Fuxi tun darf. Cloud-Sitzungen auf [Fuxi Code im Web](/de/fuxi-code-on-the-web) ignorieren `defaultMode: "dontAsk"`; siehe [bypassPermissions](#skip-all-checks-with-bypasspermissions-mode) für Details. Legen Sie ihn beim Start mit dem Flag fest: ```bash theme={null} fuxi --permission-mode dontAsk ```

Alle Prüfungen mit bypassPermissions-Modus überspringen

Der `bypassPermissions`-Modus deaktiviert Berechtigungsaufforderungen und Sicherheitsprüfungen, damit Tool-Aufrufe sofort ausgeführt werden. Ab v2.1.126 umfasst dies auch Schreibvorgänge zu [geschützten Pfaden](#protected-paths), die frühere Versionen noch aufforderten. Explizite [Ask-Regeln](/de/permissions#manage-permissions) erzwingen weiterhin eine Aufforderung in diesem Modus, und Löschvorgänge, die auf das Dateisystem-Root oder das Home-Verzeichnis abzielen, wie `rm -rf /` und `rm -rf ~`, fordern weiterhin auf als Schutzschalter gegen Modellfehler. {/* min-version: 2.1.199 */}Ab v2.1.199 werden auch MCP-Tools, die mit [`_meta["anthropic/requiresUserInteraction"]`](/de/mcp#require-approval-for-a-specific-tool) gekennzeichnet sind, weiterhin aufgefordert. Verwenden Sie diesen Modus nur in isolierten Umgebungen wie Containern, VMs oder Dev Containern ohne Internetzugang, wo Fuxi Code Ihr Host-System nicht beschädigen kann. Sie können nicht in `bypassPermissions` aus einer Sitzung eintreten, die ohne eines der aktivierenden Flags gestartet wurde; starten Sie neu mit einem, um es zu aktivieren: ```bash theme={null} fuxi --permission-mode bypassPermissions ``` Das `--dangerously-skip-permissions`-Flag ist gleichbedeutend. Unter Linux und macOS weigert sich Fuxi Code, in diesem Modus zu starten, wenn es als Root oder unter `sudo` ausgeführt wird: ```text theme={null} --dangerously-skip-permissions cannot be used with root/sudo privileges for security reasons ``` Die Prüfung wird automatisch in einer erkannten Sandbox übersprungen. Um autonom in einem Container zu laufen, verwenden Sie die [Dev-Container](/de/devcontainer)-Konfiguration, die Fuxi Code als Nicht-Root-Benutzer ausführt. [Fuxi Code im Web](/de/fuxi-code-on-the-web) berücksichtigt `defaultMode: "bypassPermissions"` oder `"dontAsk"` aus Ihren Einstellungsdateien nicht, daher können die eingecheckten Einstellungen eines Repositorys keine Cloud-Sitzung im Bypass-Permissions-Modus starten. Die Einstellung wird stillschweigend ignoriert und die Sitzung startet im Modus, der in der Modus-Dropdown angezeigt wird. Siehe [Berechtigungsmodi wechseln](#switch-permission-modes) für die Modi, die Cloud-Sitzungen anbieten. `bypassPermissions` bietet keinen Schutz vor Prompt-Injection oder unbeabsichtigten Aktionen. Verwenden Sie für Hintergrund-Sicherheitsprüfungen mit deutlich weniger Aufforderungen stattdessen [Auto-Modus](#eliminate-prompts-with-auto-mode). Administratoren können diesen Modus blockieren, indem sie `permissions.disableBypassPermissionsMode` auf `"disable"` in [verwalteten Einstellungen](/de/permissions#managed-settings) setzen.

Geschützte Pfade

Schreibvorgänge zu einer kleinen Menge von Pfaden werden niemals automatisch genehmigt, in jedem Modus außer `bypassPermissions`. Dies verhindert versehentliche Beschädigung des Repository-Status und Fuxis eigener Konfiguration. | Modus | Schreibvorgänge zu geschützten Pfaden | | :------------------------------- | :------------------------------------ | | `default`, `acceptEdits`, `plan` | Abgefragt | | `auto` | An den Klassifizierer weitergeleitet | | `dontAsk` | Abgelehnt | | `bypassPermissions` | Erlaubt | [`permissions.allow`](/de/permissions#manage-permissions) Regeln in Einstellungsdateien genehmigen Schreibvorgänge zu geschützten Pfaden nicht vorab. Die Sicherheitsprüfung wird ausgeführt, bevor Fuxi Code die Allow-Regeln aus den Einstellungen auswertet, daher ändert ein Eintrag wie `Edit(.fuxi/**)` in `~/.fuxi/settings.json` oder `.fuxi/settings.json` das Ergebnis pro Modus in der obigen Tabelle nicht. In Modi, die abfragen, bietet die Aufforderung für einen `.fuxi/`-Schreibvorgang **Ja, und Fuxi erlauben, seine eigenen Einstellungen für diese Sitzung zu bearbeiten**, was spätere `.fuxi/`-Schreibvorgänge in dieser Sitzung ohne erneute Aufforderung genehmigt. Geschützte Verzeichnisse: * `.git` * `.config/git` * `.vscode` * `.idea` * `.husky` * `.cargo` * `.devcontainer` * `.yarn` * `.mvn` * `.fuxi`, außer für `.fuxi/worktrees`, wo Fuxi seine eigenen Git-Worktrees speichert Geschützte Dateien: * `.gitconfig`, `.gitmodules` * `.bashrc`, `.bash_profile`, `.bash_login`, `.bash_aliases`, `.bash_logout`, `.zshrc`, `.zprofile`, `.zshenv`, `.zlogin`, `.zlogout`, `.profile`, `.envrc` * `.npmrc`, `.yarnrc`, `.yarnrc.yml`, `.pnp.cjs`, `.pnp.loader.mjs`, `.pnpmfile.cjs`, `bunfig.toml`, `.bunfig.toml` * `.bazelrc`, `.bazelversion`, `.bazeliskrc` * `.pre-commit-config.yaml`, `lefthook.yml`, `lefthook.yaml`, `.lefthook.yml`, `.lefthook.yaml` * `gradle-wrapper.properties`, `maven-wrapper.properties` * `.devcontainer.json` * `.ripgreprc`, `pyrightconfig.json` * `.mcp.json`, `.fuxi.json`

Siehe auch

* [Berechtigungen](/de/permissions): Allow-, Ask- und Deny-Regeln; verwaltete Richtlinien * [Auto-Modus konfigurieren](/de/auto-mode-config): Teilen Sie dem Klassifizierer mit, welche Infrastruktur Ihre Organisation vertraut * [Hooks](/de/hooks): benutzerdefinierte Berechtigungslogik über `PreToolUse`- und `PermissionRequest`-Hooks * [Ultraplan](/de/ultraplan): Führen Sie den Planungsmodus in einer Fuxi Code im Web-Sitzung mit browsergestützter Überprüfung aus * [Sicherheit](/de/security): Sicherheitsvorkehrungen und Best Practices * [Sandboxing](/de/sandboxing): Dateisystem- und Netzwerkisolation für Bash-Befehle * [Nicht-interaktiver Modus](/de/headless): Führen Sie Fuxi Code mit dem `-p`-Flag aus