CLI installieren und konfigurieren

CodeMender ist ein autonomer KI-Agent für die Codesicherheit, der schwerwiegende Cybersecurity-Schwachstellen in Ihrer Codebasis scannt, verifiziert und behebt. Bevor Sie CodeMender ausführen, laden Sie die CLI herunter und initialisieren Sie die Arbeitsbereichsoptionen.

Architektur- und Sicherheitsmodell

CodeMender verwendet ein lokales Ausführungsmodell:

  • Gehostete Reasoning-Engine: Agentic Reasoning, Threat Modeling und Orchestrierungslogik werden sicher in Google Cloud auf der Gemini Enterprise Agent Platform ausgeführt.
  • Befehlszeile für die lokale Ausführung: Der Quellcode verlässt Ihre Workstation oder Ihren CI/CD-Container nie in großen Mengen. Das lokale cm-Befehlszeilentool führt Dateilesevorgänge, lokale Build-Prüfungen und PoC-Exploit-Bestätigungen (Proof-of-Concept) in Ihrer lokalen Sandbox aus. Dabei werden nur präzise Code-Snippets und Tool-Ausführungsergebnisse über die Interactions API auf der Gemini Enterprise Agent Platform an das Cloud-Backend gesendet.

Umgebung einrichten

Bevor Sie CodeMender verwenden können, müssen Sie Ihr Google Cloud -Projekt einrichten, die CLI herunterladen und installieren, Ihre Anmeldedaten konfigurieren und Ihren Arbeitsbereich initialisieren.

Projekteinrichtung und IAM-Berechtigungen

Bevor Sie die CLI herunterladen und Anmeldedaten konfigurieren, müssen Sie sicherstellen, dass das Zielprojekt Google Cloud mit den erforderlichen APIs und Berechtigungen eingerichtet ist.

Erforderliche APIs

Prüfen Sie, ob die folgenden Google Cloud APIs in Ihrem Projekt aktiviert sind:

  1. Vertex AI API (aiplatform.googleapis.com): Ermöglicht das Streamen und Verwalten aktiver Sitzungen.
  2. Cloud Resource Manager API (cloudresourcemanager.googleapis.com): Validiert Nutzerauthentifizierungsstatus und Projektmetadaten.

Damit Nutzer die CLI-Befehle ausführen können, muss ihnen die folgende IAM-Rolle zugewiesen werden:

  • Vertex AI User (roles/aiplatform.user): Ermöglicht Nutzern das Erstellen, Streamen und Verwalten aktiver Sitzungen.

CodeMender CLI herunterladen und installieren

Die CodeMender CLI-Binärdateien werden in Artifact Registry gehostet. Wählen Sie den Tab für Ihr Betriebssystem aus, um die CLI herunterzuladen und zu installieren.

Linux x86_64

So laden Sie die CodeMender CLI für Linux (x86_64) herunter und installieren sie:

  1. Laden Sie das Paket mit einer der folgenden Methoden herunter:
    • gcloud CLI:Führen Sie den folgenden Befehl aus: 
      gcloud artifacts generic download \
  --project=cmoc-prod \
  --location=us \
  --repository=codemender-cli-production \
  --package=cm \
  --version=stable \
  --name=cm-linux-amd64.zip \
  --destination=./
    • curl:Führen Sie den folgenden Befehl aus: 
      curl -L -o cm-linux-amd64.zip "https://artifactregistry.googleapis.com/download/v1/projects/cmoc-prod/locations/us/repositories/codemender-cli-production/files/cm%3Astable%3Acm-linux-amd64.zip:download?alt=media"
  2. Installieren Sie die Befehlszeile: 
    unzip cm-linux-amd64.zip
chmod +x cm
sudo mv cm /usr/local/bin/cm

Linux ARM64

So laden Sie die CodeMender CLI für Linux (ARM64) herunter und installieren sie:

  1. Laden Sie das Paket mit einer der folgenden Methoden herunter:
    • gcloud CLI:Führen Sie den folgenden Befehl aus: 
      gcloud artifacts generic download \
  --project=cmoc-prod \
  --location=us \
  --repository=codemender-cli-production \
  --package=cm \
  --version=stable \
  --name=cm-linux-arm64.zip \
  --destination=./
    • curl:Führen Sie den folgenden Befehl aus: 
      curl -L -o cm-linux-arm64.zip "https://artifactregistry.googleapis.com/download/v1/projects/cmoc-prod/locations/us/repositories/codemender-cli-production/files/cm%3Astable%3Acm-linux-arm64.zip:download?alt=media"
  2. Installieren Sie die Befehlszeile: 
    unzip cm-linux-arm64.zip
chmod +x cm
sudo mv cm /usr/local/bin/cm

macOS Intel

So laden Sie die CodeMender CLI für macOS (Intel) herunter und installieren sie:

  1. Laden Sie das Paket mit einer der folgenden Methoden herunter:
    • gcloud CLI:Führen Sie den folgenden Befehl aus: 
      gcloud artifacts generic download \
  --project=cmoc-prod \
  --location=us \
  --repository=codemender-cli-production \
  --package=cm \
  --version=stable \
  --name=cm-darwin-amd64.zip \
  --destination=./
    • curl:Führen Sie den folgenden Befehl aus: 
      curl -L -o cm-darwin-amd64.zip "https://artifactregistry.googleapis.com/download/v1/projects/cmoc-prod/locations/us/repositories/codemender-cli-production/files/cm%3Astable%3Acm-darwin-amd64.zip:download?alt=media"
  2. Installieren Sie die Befehlszeile: 
    unzip cm-darwin-amd64.zip
chmod +x cm
mv cm /usr/local/bin/cm

macOS mit Apple Silicon

So laden Sie die CodeMender-Befehlszeile für macOS (Apple Silicon) herunter und installieren sie:

  1. Laden Sie das Paket mit einer der folgenden Methoden herunter:
    • gcloud CLI:Führen Sie den folgenden Befehl aus: 
      gcloud artifacts generic download \
  --project=cmoc-prod \
  --location=us \
  --repository=codemender-cli-production \
  --package=cm \
  --version=stable \
  --name=cm-darwin-arm64.zip \
  --destination=./
    • curl:Führen Sie den folgenden Befehl aus: 
      curl -L -o cm-darwin-arm64.zip "https://artifactregistry.googleapis.com/download/v1/projects/cmoc-prod/locations/us/repositories/codemender-cli-production/files/cm%3Astable%3Acm-darwin-arm64.zip:download?alt=media"
  2. Installieren Sie die Befehlszeile: 
    unzip cm-darwin-arm64.zip
chmod +x cm
mv cm /usr/local/bin/cm

Windows x86_64

So laden Sie die CodeMender-Befehlszeile für Windows (x86_64) herunter und installieren sie:

  1. Laden Sie das Paket mit einer der folgenden Methoden herunter:
    • gcloud CLI:Führen Sie den folgenden Befehl in PowerShell aus: 
      gcloud artifacts generic download `
  --project=cmoc-prod `
  --location=us `
  --repository=codemender-cli-production `
  --package=cm `
  --version=stable `
  --name=cm-windows-amd64.zip `
  --destination=./
    • PowerShell:Führen Sie den folgenden Befehl aus: 
      Invoke-WebRequest -Uri "https://artifactregistry.googleapis.com/download/v1/projects/cmoc-prod/locations/us/repositories/codemender-cli-production/files/cm%3Astable%3Acm-windows-amd64.zip:download?alt=media" -OutFile cm-windows-amd64.zip
  2. Installieren Sie die Befehlszeile: 
    Expand-Archive -Path cm-windows-amd64.zip -DestinationPath ./
# Move cm.exe to a permanent folder and add it to your system PATH (e.g. Environmental Variables)

Windows ARM64

So laden Sie die CodeMender CLI für Windows (ARM64) herunter und installieren sie:

  1. Laden Sie das Paket mit einer der folgenden Methoden herunter:
    • gcloud CLI:Führen Sie den folgenden Befehl in PowerShell aus: 
      gcloud artifacts generic download `
  --project=cmoc-prod `
  --location=us `
  --repository=codemender-cli-production `
  --package=cm `
  --version=stable `
  --name=cm-windows-arm64.zip `
  --destination=./
    • PowerShell:Führen Sie den folgenden Befehl aus: 
      Invoke-WebRequest -Uri "https://artifactregistry.googleapis.com/download/v1/projects/cmoc-prod/locations/us/repositories/codemender-cli-production/files/cm%3Astable%3Acm-windows-arm64.zip:download?alt=media" -OutFile cm-windows-arm64.zip
  2. Installieren Sie die Befehlszeile: 
    Expand-Archive -Path cm-windows-arm64.zip -DestinationPath ./
# Move cm.exe to a permanent folder and add it to your system PATH (e.g. Environmental Variables)

Google Cloud -Anmeldedaten konfigurieren

Da die CodeMender-Befehlszeile über die Interactions API mit der in der Cloud gehosteten Reasoning Engine interagiert, müssen Sie Google Cloud Standardanmeldedaten für Anwendungen (Application Default Credentials, ADC) in Ihrer Umgebung konfigurieren.

Führen Sie zur Authentifizierung den folgenden Befehl aus und folgen Sie den Anmeldeaufforderungen:

gcloud auth application-default login

Arbeitsbereich initialisieren

Nach der Authentifizierung müssen Sie CodeMender in Ihrer lokalen Umgebung initialisieren. Durch die Initialisierung von CodeMender wird Ihr lokaler Arbeitsbereich vorbereitet, indem Dateien zur Statusverfolgung erstellt und Verbindungseinstellungen für die cloudbasierte Reasoning Engine eingerichtet werden.

Führen Sie cm init im Stammverzeichnis Ihrer Codebasis aus, um Dateien für die lokale Statusverfolgung zu erstellen und Basiskonfigurationen festzulegen:

cm init

Verwenden Sie das Flag „--verify“, um die Verbindung zur cloudbasierten Reasoning Engine zu testen und die Arbeitsbereichseinstellungen zu überprüfen:

cm init --verify

Konfigurationsparameter (config.yaml)

Das primäre Ziel von config.yaml ist es, das Verhalten des CodeMender-Agents an die Sicherheits-, Umgebungs- und Leistungsanforderungen Ihres lokalen Systems anzupassen.

Da der gehostete KI-Agent lokale Befehle (z. B. zum Erstellen von Code, Ausführen von Tests oder Bearbeiten von Dateien) über Ihren lokalen Daemon-Client ausführt, dient diese Konfigurationsdatei als Grenze, die definiert, was der Agent tun darf und was nicht.

Nutzung

  • Speicherort:Standardmäßig sucht die CLI in Ihrem initialisierten Arbeitsbereich (in der Regel .codemender/config.yaml) oder in einem globalen Konfigurationsverzeichnis wie ~/.config/codemender/config.yaml nach dieser Datei.
  • Ausführung:Wenn Sie Befehle wie cm find, cm verify oder cm fix ausführen, liest der lokale Client diese Datei, um Sicherheitsparameter festzulegen, Systemumgehungen anzuwenden und anzugeben, welche Dateien oder Verzeichnisse ignoriert werden sollen.

Standardeinstellungen für Core

Das bedeuten die wichtigsten Standardparameter:

  • human_confirmation: true (oder require_confirmation: true)

    • Was das bedeutet:Standardmäßig kann CodeMender keine Dateien auf Ihrer Festplatte ändern oder Shell-Befehle ausführen, ohne Sie explizit im Terminal um eine [Y/n]-Bestätigung zu bitten.
    • Warum ist das die Standardeinstellung? CodeMender kann spekulative Patches generieren oder versuchen, Exploit-Skripts auszuführen, um eine Sicherheitslücke zu bestätigen. Durch die erzwungene Bestätigung durch den Nutzer werden versehentliche Systemänderungen oder die unbefugte Code-Ausführung in Ihrer lokalen Umgebung verhindert.
    • Umgehen:Für nicht interaktive CI/CD-Pipelines kann dieser Wert auf false festgelegt werden.

  • confirm_writes: false

    • Bedeutung:Deaktiviert interaktive Aufforderungen für Dateimodifikationen. Der CodeMender-Agent kann Sicherheitspatches schreiben und Quelldateien direkt auf Ihrer lokalen Festplatte ändern, ohne auf die Genehmigung durch einen Menschen zu warten.
    • Warum ist das die Standardeinstellung? Standardmäßig wird diese Sicherheitsvorkehrung in CodeMender auf true festgelegt, um einen Workflow mit menschlicher Überprüfung zu erzwingen. Da CodeMender auf Ihrer lokalen Codebasis agiert, wird durch die erforderliche manuelle Bestätigung (z. B. Write? [Y/n]) verhindert, dass der Agent spekulative, falsche oder destruktive Änderungen an Ihren Quelldateien vornimmt. Sie sollten dies nur auf false umstellen, wenn Sie in isolierten, temporären Sandboxes oder automatisierten, Headless-CI/CD-Pipelines ausgeführt werden.

  • include: [".py", ".java", ".go", ".js", ".ts", ".c", ".cc", ".cpp", ".h", ".rb", ".php"]

    • Bedeutung:Definiert die explizite Liste der Dateiendungen, die Sie CodeMender zum Aufnehmen und Analysieren beim Scannen Ihres Arbeitsbereichs autorisieren. CodeMender überspringt automatisch alle Dateien in Ihrem Repository, deren Erweiterung nicht in dieser Liste angegeben ist.
    • Warum ist das die Standardeinstellung? Diese Liste enthält standardmäßig die wichtigsten Programmiersprachen, um die Effizienz des Scans zu maximieren und zu verhindern, dass der Agent Zeit und Tokens für irrelevante Textdateien, Build-Artefakte oder Binärdateien verschwendet. Da moderne Anwendungen jedoch häufig Sicherheitslücken in Bereitstellungskonfigurationen oder Automatisierungstools enthalten, empfehlen wir dringend, diese Standardliste manuell zu erweitern, um Konfigurationsdateien, Scriptformate und IaC-Dateien (z. B. Shell-Scripts, XML-, YAML-, Properties- und JSON-Dateien) aufzunehmen, damit CodeMender sie nicht stillschweigend ignoriert.

  • exclude_paths: ["node_modules", "vendor", "dist", "bin"]

    • Bedeutung:CodeMender überspringt diese Verzeichnisse beim Scannen des Arbeitsbereichs und bei der Codeanalyse vollständig.
    • Warum ist das die Standardeinstellung? Große Abhängigkeits- oder Build-Ordner führen zu einer massiven Latenz und Token-Strafe. Wenn diese standardmäßig ausgeschlossen werden, wird eine hohe Leistung und schnelle Reaktionszeiten gewährleistet.

  • project_paths: []

    • Bedeutung:Eine Liste von Verzeichnispfaden, auf die CodeMender während der Ausführung des Tools zugreifen (lesen/schreiben) kann.
    • Warum ist das der Standardwert? Standardmäßig ist das Feld leer. Dadurch wird der Agent auf das Scan-Zielverzeichnis, das Arbeitsbereichverzeichnis .codemender und /tmp beschränkt. Wenn für Ihren Build- oder Testprozess der Zugriff auf Dateien außerhalb dieser Verzeichnisse erforderlich ist, müssen Sie diese Pfade hier hinzufügen.

  • sandbox:

    • Bedeutung:Konfigurationsblock für die Sandbox-Umgebung auf Prozessebene.
    • Unterparameter:
      • enabled: true: (boolesch) Aktiviert oder deaktiviert die Sandbox. Wenn Sie diesen Wert auf true (Standard) festlegen, führt der Agent Tools in der lokalen Sandbox aus. Wenn Sie den Wert auf false festlegen, führt der KI‑Agent Tools direkt auf dem Hostsystem ohne Isolation aus.
      • mounts: (Objekt)
        • target_dir: ".": (String) Das Verzeichnis, das als aktiver Arbeitsbereich in der Sandbox bereitgestellt werden soll. Die CLI löst relative Pfade relativ zum Arbeitsbereichs-Root auf.
      • network: (Objekt)
        • profile: "permissive-closed": (String) Profil für ausgehenden Netzwerkzugriff in der Sandbox. Die detaillierte Zulassungsliste für bestimmte Domains oder URL-Muster wird noch nicht unterstützt. Unterstützte Profile:
          • permissive-closed (Standard): Vollständige Netzwerkisolation. Die Sandbox blockiert alle ausgehenden Verbindungen.
          • permissive-open: Ermöglicht vollständigen ausgehenden Netzwerkzugriff.

  • security:

    • Bedeutung:Konfigurationsblock für Sicherheitsrichtlinien.
    • Unterparameter:
      • protected_files: []: (Liste mit Strings) Dateien oder Verzeichnisse auf dem Hostsystem, die Sie schreibgeschützt in der Sandbox einbinden möchten, um sie vor Änderungen zu schützen (z.B. ["~/.ssh/*"]). Unterstützt die Pfaderweiterung (~) und Platzhalter (*).

  • model: "gemini-3.5-flash"

    • Bedeutung:Die Standard-KI-Engine, die die Reasoning-Schleifen im Backend unterstützt.
    • Warum ist das die Standardeinstellung? gemini-3.5-flash bietet das optimale Gleichgewicht zwischen Geschwindigkeit, Kosten und analytischer Argumentation, das für das Vorschlagen von Patches erforderlich ist. Nutzer können dies bei Bedarf auf gemini-3.1-pro überschreiben, um eine detailliertere, komplexere Argumentation zu erhalten.

  • vcs: { type: "git" }

    • Bedeutung:Definiert den Typ des Versionsverwaltungssystems, das in Ihrem Projekt über den Schlüssel vcs verwendet wird. Wenn Sie diese Option nicht konfigurieren, versucht das Tool, Git- oder Mercurial-Repositories automatisch zu erkennen. Wenn Sie vcs auf none setzen, gibt die CLI eine Warnung aus, wird aber ohne VCS-Funktionalität fortgesetzt. CodeMender verwendet diese Einstellung, um spekulative Sicherheitskorrekturen zu verwalten, Änderungen an der Codebasis nachzuverfolgen und in Ihr lokales Repository zu integrieren.
    • Warum ist das die Standardeinstellung? CodeMender unterstützt Git, Mercurial oder benutzerdefinierte VCS-Konfigurationen. Git ist die Standardeinstellung, da es der Branchenstandard für die Versionsverwaltung ist. So wird eine nahtlose Integration von Differenzen und die Sicherheit von Rollbacks gewährleistet.

  • build: { command: "make build && make test" }

    • Bedeutung:Definiert den genauen Shell-Befehl, den CodeMender ausführt, um Ihr Projekt zu kompilieren und zu erstellen sowie Ihre Unit- und Regressionstests auszuführen.
    • Warum ist das die Standardeinstellung? Das Festlegen eines Build- und Testbefehls ist für den Bestätigungsworkflow entscheidend. So kann CodeMender Ihr Projekt kompilieren und Ihre vorhandene Test-Suite in der isolierten Sandbox-Umgebung ausführen, um zu beweisen, dass der generierte Sicherheitspatch die Sicherheitslücke erfolgreich behebt, ohne die vorhandene Anwendungslogik zu beeinträchtigen.

Ausführungs-Sandbox

Um Ihre Workstation vor unbeabsichtigten Dateimodifikationen oder unerwarteten Nebenwirkungen von Tools zu schützen, wird die CodeMender-Befehlszeile standardmäßig in einer Sandbox auf Betriebssystemebene ausgeführt. Sie können das Sandboxing dauerhaft in der Konfiguration deaktivieren oder es mit CLI-Flags pro Befehl umgehen.

Dieses Sandboxing bietet zwar eine erste Schutzschicht auf Ihrer Workstation, aber einen schwächeren Sicherheitsschutz als die Ausführung des Agents auf einer vollständig isolierten virtuellen Maschine (VM):

  • Linux: Verwendet Kernel-Namespaces (CLONE_NEWNS, CLONE_NEWUSER usw.) und seccomp-Filter, um Mount-Punkte zu isolieren und Systemaufrufe einzuschränken.
  • macOS: Verwendet den integrierten sandbox-exec-Mechanismus (Seatbelt).
  • Windows (experimentell): Verwendet die AppContainer-Isolation und Access Control Lists (ACLs). Das Sandboxing unter Windows ist experimentell und erfordert möglicherweise Administratorberechtigungen oder ist mit einigen Systemkonfigurationen nicht kompatibel.

Sandbox-Verhalten

Wenn die Sandbox aktiv ist:

  1. Dateisystemisolation: Der Agent kann Dateien nur in zulässigen Verzeichnissen lesen und schreiben. Die Sandbox leitet alle Schreibvorgänge außerhalb dieser Verzeichnisse an ein temporäres In-Memory-Dateisystem (tmpfs) um, ohne dass Ihr Hostsystem beeinträchtigt wird.
  2. Netzwerkisolation: Die Sandbox blockiert standardmäßig den ausgehenden Netzwerkzugriff. So wird verhindert, dass der KI-Agent (oder die von ihm aufgerufenen Build-Tools) unerwartete externe Verbindungen herstellt oder Daten außerhalb des Arbeitsbereichs überträgt.

Netzwerkzugriff während des Builds und der Validierung

Da in der Sandbox standardmäßig die Netzwerkisolation aktiviert ist (sandbox.network.profile wird standardmäßig auf permissive-closed gesetzt), kann der Agent während der Ausführung des Tools nicht auf das Internet zugreifen.

Dies führt zu Einschränkungen für Projekte, bei denen während der Build- oder Überprüfungsschritte externe Abhängigkeiten abgerufen werden müssen (z. B. wenn npm install, pip install oder go get als Teil von build.command ausgeführt wird). Wenn Ihr Build-Prozess versucht, auf externe Webdienste zuzugreifen, schlägt er fehl.

Netzwerkabhängigkeiten verarbeiten

Wenn für Ihr Projekt Netzwerkzugriff für Builds oder Tests erforderlich ist, haben Sie folgende Möglichkeiten:

  • Abhängigkeiten vorab abrufen: Installieren Sie alle erforderlichen Abhängigkeiten auf dem Hostsystem, bevor Sie cm-Befehle ausführen, damit für den Build-Befehl kein Netzwerkzugriff erforderlich ist.

  • Netzwerkzugriff in der Sandbox aktivieren: Ändern Sie das Netzwerkprofil in Ihrem config.yaml, um ausgehende Verbindungen zuzulassen:

    sandbox:
  network:
    profile: "permissive-open"

  • Sandbox umgehen: Führen Sie den Befehl mit dem Flag --unrestricted aus, um die Sandbox und die Dateisystemgrenzen für diese Ausführung vollständig zu deaktivieren.

Sandbox-Konfiguration

Sie können die Sandbox mit den folgenden Optionen konfigurieren und steuern:

  • Persistente Konfiguration (config.yaml): Sie können das Sandbox-Verhalten, die Einbindung des Dateisystems, den Netzwerkzugriff und die Sicherheitsrichtlinien anpassen, indem Sie Ihrer config.yaml-Datei die Blöcke sandbox, execution und security hinzufügen. Weitere Informationen finden Sie unter Konfigurationsparameter.
  • Sandbox über die Befehlszeile (--sandbox) steuern: Sie können die Sandbox für einen einzelnen Lauf explizit aktivieren oder deaktivieren, indem Sie --sandbox=true oder --sandbox=false an cm find, cm verify oder cm fix übergeben.
  • Isolation mit der CLI (--unrestricted) umgehen: Sie können alle Sandbox-Schutzmaßnahmen für einen einzelnen Lauf vorübergehend umgehen, indem Sie das Flag --unrestricted übergeben. Dadurch werden die Grenzen des Dateisystempfads deaktiviert (sodass der Agent auf jeden Pfad auf Ihrem Host zugreifen kann) und die Containerisolierung auf Betriebssystemebene vollständig deaktiviert (einschließlich der Netzwerkisolierung).

Isolationsgrad auswählen

Je nach Sicherheitsanforderungen und Entwicklungsumgebung können Sie das geeignete Isolationsniveau für die Ausführung der CodeMender-Befehlszeile auswählen.

Methode Beschreibung Vorteile Nachteile
Integrierte Sandbox (Betriebssystemebene) Standardmäßig aktiviert. Sie können die Funktion in der config.yaml-Datei deaktivieren oder mit CLI-Flags umgehen. Verwendet integrierte Betriebssystemfunktionen (Namespaces/Seccomp, sandbox-exec, AppContainer (experimentell)), um die Ausführung zu isolieren. Leichtgewichtig: Kein Startaufwand, direkter Zugriff auf lokale Workspace-Tools mit detaillierter Steuerung. Empfohlen für die tägliche lokale Entwicklung. Die Sicherheit basiert auf Funktionen des Betriebssystemkerns. Die Isolation ist geringer als bei einer vollständigen VM. Die Windows-Unterstützung ist experimentell und erfordert möglicherweise Administratorrechte oder ist mit einigen Konfigurationen nicht kompatibel.
Container Ausführen des Agents in einem Container (z. B. Docker) Gute Isolation; standardisierte Umgebung. Erfordert eine Containerlaufzeit, kann ressourcenintensiv sein und lässt keine direkte Interaktion mit Tools auf dem lokalen Computer zu.
Vollständige VMs Der Agent wird auf einer dedizierten VM ausgeführt. Maximale Sicherheit; vollständige Isolation. Hoher Ressourcenaufwand, langsamer Start, keine direkte Interaktion mit Tools auf dem lokalen Computer möglich.

Telemetrie

Um die Produktintegrität zu überwachen und zu verbessern, erheben wir anonyme Telemetriedaten über die CLI. Wir anonymisieren alle erhobenen Daten vollständig. Dazu gehören grundlegende Messwerte zur Nutzung und Leistungsdiagnosen. Bei der Telemetrie werden niemals Quellcode, Dateiinhalte, Ergebnisse, Patches oder Nutzeridentitäten erfasst oder übertragen.

Die Telemetrie ist standardmäßig aktiviert. Wenn Sie die Telemetrie deaktivieren möchten, legen Sie die Umgebungsvariable CM_TELEMETRY_OPT_OUT auf 1 oder true fest.

CLI aktualisieren

CodeMender hat einen integrierten Aktualisierungsmechanismus, der dafür sorgt, dass Sie die neueste Version der CLI verwenden.

Automatische Updateüberprüfungen

Standardmäßig sucht die CodeMender CLI automatisch im Hintergrund nach Updates, wenn Sie Befehle ausführen:

  • Drosselung: Um den Aufwand zu minimieren, wird die automatische Prüfung höchstens einmal alle 24 Stunden ausgeführt.
  • Interaktives Terminal (TTY) erforderlich: Die CLI sucht nur in einem interaktiven Terminal nach Updates und fordert Sie dann auf. In nicht interaktiven Umgebungen (z. B. CI/CD-Pipelines oder Skripts) wird die Prüfung übersprungen und höchstens einmal täglich eine Warnung in stderr protokolliert.
  • Aufforderung: Wenn eine neue Version verfügbar ist, werden Sie auf stderr aufgefordert: none 🆕 A new CodeMender release is available: 1.1.0 Update now? (y/N): Wenn Sie „Ja“ (y oder yes) auswählen, lädt CodeMender das Update herunter, ersetzt die Binärdatei und beendet den Vorgang. Sie müssen den Befehl noch einmal ausführen, um ihn mit der neuen Version auszuführen. Wenn Sie „Nein“ auswählen, wird das Update übersprungen und Ihr ursprünglicher Befehl wird ausgeführt.
  • Offlinetoleranz: Wenn Sie offline sind oder das Release-Repository nicht erreichbar ist, schlägt die Prüfung im Hintergrund fehl und CodeMender führt Ihren Befehl weiter aus.
  • Umgehen: Sie können die automatische Updateprüfung umgehen, indem Sie das Flag --yes oder -y an einen beliebigen Befehl übergeben.

Manuelle Updates (cm update)

Sie können CodeMender zwingen, sofort nach Updates zu suchen und diese anzuwenden, indem Sie den Befehl update ausführen:

cm update

Führen Sie den Befehl cm update aus:

  • Die 24-Stunden-Drosselung wird ignoriert.
  • Das Update wird sofort heruntergeladen und angewendet, ohne dass eine Aufforderung erfolgt (nicht interaktiv).
  • Es ist kein interaktives Terminal erforderlich (sicher für Scripts und Konfigurationsverwaltung).

Wenn die CLI in einem Systemverzeichnis installiert ist, für das erhöhte Berechtigungen erforderlich sind, führen Sie das Update mit sudo aus:

sudo cm update