Coding-Agent-Telemetrie: Was wird übertragen?

Welche Daten die Telemetrie von Coding-Agenten tatsächlich erfasst

Die Telemetrie von Coding-Agenten umfasst vier separate Datenflüsse, die unter einem gemeinsamen Begriff zusammengefasst werden. Jeder dieser Datenflüsse wird separat gesteuert. Bei der Modellinferenz werden Ihre Prompts und Ihr Code an den Anbieter übermittelt, der das Modell bereitstellt. Keine Einstellung kann das deaktivieren. Produktanalysen und Absturzberichte gehen an den Anbieter und häufig zusätzlich an ein Logging-Unternehmen, das der Anbieter bezahlt. Ob Daten zum Training gespeichert werden, ist eine Vertragsfrage und keine Netzwerkfrage. Der vierte Datenfluss wird häufig übersehen: Jede Integration, die Sie hinzufügen, kann eine Verbindung zu einem Host öffnen, den Sie nicht selbst ausgewählt haben.

Eine Liste der aktuellen Standardwerte der Anbieter veraltet bei diesem Thema besonders schnell. Eine neue Version kann einen Standardwert ändern. Eine neue Funktion kann ein Ziel hinzufügen, das von keinem vorhandenen Schalter abgedeckt wird. Die dauerhaft anwendbare Vorgehensweise ist daher ein Audit, das Sie mit jedem Agenten wiederholen können: Lesen Sie die Dokumentation des Anbieters. Prüfen Sie, welche Konfiguration auf diesem Rechner tatsächlich angewendet wurde. Überwachen Sie den Prozess direkt auf dem Rechner. Wählen Sie anschließend die Kontrollen aus, für die Sie den erforderlichen Aufwand in Kauf nehmen. Jeden folgenden Befehl führen Sie auf Ihrem eigenen Rechner und für Ihren eigenen Netzwerkverkehr aus.

Die vier Kategorien und warum sie unterschiedliche Kontrollen erfordern

Modell-Inferenzverkehr ist unvermeidbar. Der Agent sendet Ihre Eingabeaufforderung, die gelesenen Dateien, die Ausgabe der ausgeführten Befehle und den selbst erzeugten Text an einen Modell-Endpunkt. Das ist die vorgesehene Funktionsweise des Produkts. Die einzige tatsächliche Entscheidung besteht darin, wer diese Daten empfängt: eine von einem anderen Anbieter betriebene API oder ein Modell, das Sie selbst betreiben. Ein Cloud-Konto eines Unternehmens (Bedrock, Vertex, Foundry) verlagert den Empfänger, beseitigt den Datenfluss aber nicht. Nichts im restlichen Beitrag reduziert den Inferenzverkehr. Halten Sie ihn daher gedanklich von den drei anderen Kategorien getrennt.

Produktanalyse und Absturzberichte sind ein anderer Datenfluss zu anderen Hosts. Nutzungszähler, Latenzwerte, Abfragen von Feature-Flags und Stacktraces gehen normalerweise an Hostnamen, die nichts mit der Modell-API zu tun haben, und häufig an einen Fehler-Tracker eines Drittanbieters. Anbieter dokumentieren diese Daten meist als "Metriken" und "Fehlerberichte" und stellen normalerweise eine Umgebungsvariable pro Kategorie bereit. Das Volumen ist sehr gering. Byte-Zählungen werden es daher niemals aufdecken. Sie suchen nach Hostnamen, nicht nach Bandbreite.

Aufbewahrung und Training sind Richtlinien, keine Pakete. Ob der Anbieter Ihre Eingaben speichert, wie lange er sie speichert und ob er damit ein künftiges Modell trainiert, steht in den Bedingungen Ihres Tarifs. Verbraucher- und Geschäftstarife unterscheiden sich normalerweise, und eine Vereinbarung ohne Aufbewahrung ist üblicherweise ein separater Vertrag. Mit tcpdump können Sie dies nicht überprüfen, weil die Pakete in beiden Fällen identisch aussehen. Lesen Sie die Bedingungen. Wenn dies für Ihren Arbeitgeber relevant ist, lassen Sie es sich schriftlich bestätigen.

Integrationen fügen unauffällig einen zusätzlichen Hop hinzu. Ein MCP-Server (Model Context Protocol), ein Plugin-Marktplatz, eine Prüfung auf automatische Updates, ein Websuchwerkzeug oder eine Sicherheitsprüfung, die vor dem Abruf eine URL auflöst: Jede dieser Funktionen sendet eine Anfrage an einen Host, der nicht der Modell-Endpunkt ist. Hier treten die Überraschungen auf. Ein Harness kann Aufgaben, die Sie für lokal hielten, über einen eigenen Dienst leiten. Ein Release kann damit beginnen, ohne dass Sie eine einzige Zeile Ihrer Konfiguration ändern. Behandeln Sie jedes hinzugefügte Werkzeug als neues Ziel, bis Sie seinen Datenverkehr im Netzwerk beobachtet haben.

Schritt 1: Was dokumentiert der Anbieter?

Öffnen Sie die Referenz zu den Einstellungen und die Seite zur Datennutzung für Ihren Agenten. Lesen Sie beide Seiten mit einer Wortliste: Metriken, Analytics, Fehlerberichte, Abstürze, Feedback, Umfragen, Update-Prüfungen, Sicherheitsprüfungen, Marketplace. Jedes dieser Wörter bezeichnet normalerweise einen eigenen Schalter. Notieren Sie die exakten Variablennamen, weil Schritt 2 danach sucht.

Ein Begriff führt Sie dabei in die Irre. Bei mehreren Agenten bezeichnet „Telemetry“ in der Dokumentation einen OpenTelemetry-Export, den Sie so konfigurieren, dass Metriken an einen von Ihnen betriebenen Collector gesendet werden. Das ist das Gegenteil davon, Daten an den Anbieter zu senden. Claude Code ist ein solcher Fall: Das Setzen von CLAUDE_CODE_ENABLE_TELEMETRY=1 startet einen Export an den Endpunkt, den Sie in OTEL_EXPORTER_OTLP_ENDPOINT angeben. Dieser Export hat nichts mit den eigenen Analytics des Anbieters zu tun, für die es eine separate Opt-out-Einstellung gibt. Ermitteln Sie die Datenflussrichtung, bevor Sie eine Einstellung ändern.

Rechnen Sie mit einem Hauptschalter, aber auch mit Lücken. Stand August 2026 deaktiviert CLAUDE_CODE_DISABLE_NONESSENTIAL_TRAFFIC in Claude Code gemeinsam Metriken, Fehlerberichte, den Feedback-Befehl und Sitzungsumfragen. In derselben Dokumentation steht außerdem, dass diese Einstellung die WebFetch-Domänensicherheitsprüfung nicht abdeckt. Diese sendet den Hostnamen, den Sie abrufen möchten, an die API des Anbieters und verfügt über eine eigene Einstellung. Das ist kein Vorwurf gegen ein bestimmtes Produkt. Es beschreibt das grundsätzliche Problem: Ein Hauptschalter deckt die Kategorien ab, die zum Zeitpunkt seiner Dokumentation existierten.

Auch der Opt-out hat möglicherweise Nachteile. In derselben Dokumentation steht, dass das Deaktivieren der Telemetrie auch die Auswertung von Feature Flags deaktiviert, von der einige Funktionen abhängen. Ein aus Datenschutzgründen umgelegter Schalter kann daher eine von Ihnen verwendete Funktion deaktivieren, ohne dass eine Fehlermeldung den Zusammenhang erklärt. Lesen Sie den Satz neben dem Schalter, nicht nur dessen Namen.

Schritt 2: Welche Konfiguration wurde tatsächlich angewendet?

Eine Einstellung, die Sie geschrieben haben, ist nicht automatisch eine Einstellung, die angewendet wurde. Agents führen die Konfiguration aus mehreren Dateien zusammen. Eine dieser Dateien befindet sich möglicherweise in dem Repository, das Sie gerade von einer anderen Person geklont haben. Beginnen Sie mit der Umgebung Ihrer eigenen Shell.

env | grep -Ei 'telemetry|otel|analytics|error_report|do_not_track|proxy'

Geben Sie anschließend jede Einstellungsdatei aus, die das Tool liest, und zwar in der Reihenfolge, die in der Dokumentation angegeben ist. Für Claude Code sind das im August 2026 die Benutzerdatei, die beiden Projektdateien und ein Verzeichnis für verwaltete Richtlinien unter Linux.

for f in ~/.claude/settings.json .claude/settings.json .claude/settings.local.json; do
  echo "== $f"; [ -f "$f" ] && cat "$f"
done
ls -l /etc/claude-code/ 2>/dev/null

Eine Projektdatei, die mit einem git clone eingetroffen ist, enthält eine Konfiguration, die von einer anderen Person geschrieben wurde. Sie kann eine Einstellung wieder aktivieren, die Sie in Ihrer Benutzerdatei deaktiviert haben. Wenn der Agent einen Statusbefehl unterstützt, der die geladenen Quellen auflistet, ist das die schnellste verlässliche Prüfung: Claude Code gibt die geladenen Einstellungsquellen in /status aus.

Die zuverlässigste Prüfung liest den laufenden Prozess statt einer Datei. Weisen Sie dem Agenten zunächst ein eigenes Linux-Benutzerkonto zu. Dadurch werden alle Befehle in diesem Beitrag kürzer. Lesen Sie anschließend die Umgebung aus, mit der der Prozess gestartet wurde.

pgrep -u agent -a node
sudo tr '\0' '\n' < /proc/$(pgrep -u agent -n node)/environ | grep -Ei 'telemetry|proxy|otel'

/proc/<pid>/environ zeigt die Variablen, die der Prozess zum Zeitpunkt von exec hatte. Damit wird der Fall erkannt, in dem Ihr .bashrc-Export einen von systemd gestarteten Dienst nicht erreicht hat. Fehlt hier eine von Ihnen gesetzte Variable, war sie nie aktiv, unabhängig davon, was Ihre Dotfiles angeben.

Schritt 3: Mit welchen Hosts verbindet sich der Agent?

Beginnen Sie mit offenen Sockets, gefiltert nach dem Benutzerkonto, unter dem der Agent ausgeführt wird.

sudo ss -tnpe state established

-e fügt jeder Zeile ein Feld uid: hinzu. Dadurch können Sie die Verbindungen des Agents von denen Ihres Browsers unterscheiden, ohne Prozessnamen zu prüfen. Notieren Sie die Remote-Adressen und ermitteln Sie anschließend die zugehörigen Namen. Die zuverlässigste Quelle für diese Namen ist der TLS-Handshake (Transport Layer Security). Jede neue Verbindung beginnt mit einem ClientHello, das ein SNI-Feld (Server Name Indication) enthält. Darin steht der Hostname, den der Client angefordert hat.

sudo apt install -y tshark
sudo tshark -i any -f 'tcp port 443' -Y 'tls.handshake.type == 1' \
  -T fields -e ip.dst -e tls.handshake.extensions_server_name

Sie erhalten eine Zeile pro neuer Verbindung. Das ist genau die gewünschte Übersicht: die Model-API, der Update-Server, der Analytics-Host, der Fehler-Tracker und alles, was eine Integration hinzugefügt hat. Eine leere Namensspalte bedeutet, dass der Client ECH (Encrypted Client Hello) verwendet. Der Hostname ist dann im Netzwerkverkehr nicht sichtbar. Verwenden Sie in diesem Fall die Ziel-IP-Adresse, eine Reverse-DNS-Abfrage oder den Proxy aus Schritt 4.

Die DNS-Ansicht (Domain Name System) ist eine nützliche Gegenprüfung. Sie zeigt auch Namen, die der Agent aufgelöst hat, wenn die zugehörigen Verbindungen nicht abgeschlossen wurden.

sudo tcpdump -ni any -l 'udp port 53'

Jede Abfragezeile endet mit dem Record-Typ und dem Namen im Format A? host.example.net. (39). Erfassen Sie den Datenverkehr auf any und nicht auf der externen Schnittstelle. Bei systemd-resolved kommuniziert die Anwendung mit einem lokalen Stub-Listener auf 127.0.0.53. Nur dieser Stub kommuniziert mit dem externen Netzwerk. Wenn während der Agent eindeutig arbeitet überhaupt kein DNS-Datenverkehr zu sehen ist, führt diese Laufzeitumgebung DNS-over-HTTPS selbst aus. Nur Schritt 4 liefert dann die Namen.

Erfassen Sie den Datenverkehr, während der Agent tatsächliche Aufgaben ausführt. Starten Sie eine Sitzung. Lassen Sie ihn eine Datei lesen, einen Befehl ausführen oder an einer Aufgabe scheitern. Datenverkehr, der nur einmal beim Start oder erst beim Auslösen einer Ausnahme entsteht, erscheint in einer Erfassung im Leerlauf nicht. Eine solche Erfassung führt bei einem Audit am häufigsten zu einer plausiblen, aber falschen Antwort.

Schritt 4: Was befindet sich in den Requests?

Hostnamen zeigen, wer beteiligt ist. Um zu sehen, welche Inhalte übertragen werden, schalten Sie einen Proxy, den Sie kontrollieren, vor den Agent und vertrauen dessen Certificate Authority (CA) nur für diese Laufzeit. mitmproxy ist dafür das übliche Tool. Das Projekt empfiehlt die Standalone-Binärdateien von mitmproxy.org und dokumentiert uv tool install mitmproxy als Variante über das Python-Paket.

mitmdump -w /tmp/agent-flows.mitm

Beim ersten Start wird eine CA in ~/.mitmproxy/ geschrieben. mitmproxy-ca-cert.pem ist das Zertifikat selbst. Setzen Sie in der Shell, aus der Sie den Agent starten, den Client auf den Proxy und dieses Zertifikat.

export HTTP_PROXY=http://127.0.0.1:8080
export HTTPS_PROXY=http://127.0.0.1:8080
export NODE_EXTRA_CA_CERTS="$HOME/.mitmproxy/mitmproxy-ca-cert.pem"
export REQUESTS_CA_BUNDLE="$HOME/.mitmproxy/mitmproxy-ca-cert.pem"
export SSL_CERT_FILE="$HOME/.mitmproxy/mitmproxy-ca-cert.pem"

Viele Agent-CLIs sind Node-Programme. Node liest NODE_EXTRA_CA_CERTS beim Start des Prozesses. Exportieren Sie die Variable daher vor dem Start des Agent und nicht nachträglich in einem anderen Terminal. Python-Clients lesen REQUESTS_CA_BUNDLE oder SSL_CERT_FILE. Ein Go-Binary, das die Standardbibliothek verwendet, liest unter Linux SSL_CERT_FILE. Prüfen Sie mit curl, ob der Pfad funktioniert, bevor Sie den Agent als Ursache vermuten.

curl -sS -o /dev/null -w '%{http_code}\n' https://example.com

Bei einem funktionierenden Proxy wird 200 ausgegeben, und der Request erscheint in der Ausgabe von mitmdump. Eine nicht vertrauenswürdige CA führt zu curl: (60) SSL certificate problem: self-signed certificate in certificate chain. Bei einem Node-Agent lautet der entsprechende Fehlercode SELF_SIGNED_CERT_IN_CHAIN. Lesen Sie die gespeicherten Flows anschließend mit dem Konsolen-Viewer. Dort können Sie einen Request öffnen und seine Header und seinen Body lesen.

mitmproxy -r /tmp/agent-flows.mitm

Vier Ergebnisse sind besonders relevant. Sie sehen die Requests. Dann lesen Sie sie und entscheiden. Der Agent startet wegen eines Zertifikatsfehlers nicht. Das ist ein Trust-Problem in dieser Laufzeit und kein Befund über den Anbieter. Sie sehen nur die Model-API. Dann sind die anderen Kategorien deaktiviert oder werden durch ein Ereignis ausgelöst, das Sie nicht erzeugt haben. Oder Sie sehen überhaupt nichts, obwohl der Agent offensichtlich funktioniert. Dann ignoriert der Client Proxy-Umgebungsvariablen oder pinnt seine Zertifikate. Keine Anwendungseinstellung kann Ihnen in diesem Fall zuverlässig die Wahrheit mitteilen. Dieses letzte Ergebnis ist am wichtigsten. Es führt zurück zu Schritt 3, weil sich eine Packet-Capture nicht davon abbringen lässt, eine Verbindung zu sehen.

Kontrollen, von schwach bis stark

Opt-out-Einstellungen. Sie sind am günstigsten und am schwächsten, weil sie darauf beruhen, dass der Anbieter sie berücksichtigt, und weil sie eine bereits vorhandene Kategorie abdecken. Setzen Sie sie an einer Stelle, an der sie einen Reboot und ein neues Terminal überstehen, also in der Benutzereinstellungsdatei oder in Ihrem Shell-Profil. Fügen Sie dabei auch DO_NOT_TRACK=1 hinzu: Viele Befehlszeilenwerkzeuge respektieren diese Konvention, darunter einige Agents, und sie kostet nichts. Führen Sie anschließend nach dem nächsten Update Schritt 3 erneut aus, weil sich dann die Abdeckung ändert.

Ausgehende Verbindungen einschränken. Hier hören Sie auf zu bitten und beginnen durchzusetzen. Führen Sie den Agent unter einem eigenen Benutzer aus. Erlauben Sie diesem Benutzer anschließend Loopback und DNS und verwerfen Sie alles andere. Dafür wird eine eigene Tabelle angelegt. Vorhandene Firewall-Regeln bleiben dadurch unverändert.

table inet agentegress {
  chain output {
    type filter hook output priority filter; policy accept;
    meta skuid "agent" ip daddr 127.0.0.0/8 accept
    meta skuid "agent" udp dport 53 accept
    meta skuid "agent" counter log prefix "agent-egress-drop " drop
  }
}

Wenden Sie die Regel mit sudo nft -f /etc/nftables.d/agent.nft an, beobachten Sie den Zähler mit sudo nft list table inet agentegress und lesen Sie die verworfenen Verbindungen mit sudo journalctl -k -g agent-egress-drop aus. Ein steigender Verwerfungszähler zusammen mit einem nicht erwarteten Hostnamen ist genau das Ziel dieser Maßnahme. Zwei wichtige Einschränkungen: meta skuid vergleicht den Benutzer, dem der Socket gehört. Die Regel gilt daher nur, solange dieses Konto nicht zu einem anderen Benutzer wechseln kann. Passwortloses sudo für den Agent macht aus dieser Regel lediglich eine Empfehlung. Wenn Sie UDP 53 für beliebige DNS-Server geöffnet lassen, bleibt außerdem ein Kanal bestehen, über den Daten in Abfragenamen nach außen übertragen werden können. Schließen Sie ihn daher ebenfalls, falls es Ihr Bedrohungsmodell erfordert. Verweisen Sie dazu den Resolver des Agents auf einen von Ihnen betriebenen Host. Hostname-Allowlists gehören in einen Proxy und nicht in nftables, weil API-Endpunkte hinter Content Delivery Networks liegen, deren IP-Adressen sich ändern, ohne dass Sie darauf Einfluss haben. Diese Kontrolle verursacht zusätzliche Ausfälle und Wartungsaufwand: Paketinstallationen, git über SSH und die eigene Update-Prüfung des Agents schlagen fehl, bis Sie sie erlauben. Diese Liste müssen Sie anschließend selbst pflegen. Wenn Sie dies auf einem Server statt auf einem Laptop einrichten, bildet dieselbe Benutzer- und Firewall-Struktur die Grundlage für Claude Code sicher auf einem VPS ausführen.

Eine Wegwerfmaschine. Geben Sie dem Agent eine virtuelle Maschine (VM), die keine für Sie wichtigen Zugangsdaten enthält und am Ende der Aufgabe gelöscht wird. Dadurch wird nicht reduziert, was der Agent sendet. Reduziert wird, worauf der Agent zum Senden zugreifen kann. Das ist in der Regel das eigentliche Risiko. Kombinieren Sie diese Maßnahme mit den oben genannten Regeln für ausgehende Verbindungen, weil eine frische VM mit uneingeschränktem Internetzugriff weiterhin jeden Host in Ihrer Erfassung erreicht. Die Methode und den Zustand, den Sie jedes Mal neu erstellen müssen, behandelt Coding-Agents in einer Wegwerf-VM ausführen. Die Frage zur Dimensionierung wird in einen Coding-Agent auf einem VPS ausführen behandelt.

Das Modell selbst hosten. Dies ist die einzige Kontrolle, die den Inferenzdatenverkehr entfernt, weil der Prompt Ihre Hardware nicht verlässt. Die Kosten sind erheblich: Ein geschlossenes Modell können Sie nicht selbst hosten. Sie müssen daher offene Gewichte auswählen, bei schwierigen Aufgaben eine geringere Leistungsfähigkeit akzeptieren und die erforderliche Hardware bereitstellen. Diese Abwägung wird in ob Sie Claude selbst hosten können erläutert. Die Unterschiede in der Leistungsfähigkeit der wichtigsten Agents behandelt wie sich Claude Code, Cursor, Codex und Copilot unterscheiden.

Keine dieser vier Kontrollen ändert, welche Dateien der Agent auf der Festplatte lesen darf. Der Inferenzdatenverkehr enthält alles, was er liest. Wenn sich eine .env-Datei im Arbeitsverzeichnis befindet, wird sie an das Modell gesendet, sobald der Agent nach einem Variablennamen sucht. Diese Daten außerhalb der Reichweite zu halten, ist eine separate Aufgabe. Sie wird in Geheimnisse aus dem Kontext eines AI-Agents heraushalten behandelt.

Nach jedem Update prüfen

1. Vergleichen Sie die Einstellungs- und Datennutzungsseiten des Anbieters mit Ihren letzten Aufzeichnungen. Achten Sie dabei auf neue Schalter und neu benannte Dienste.
2. Lesen Sie die Prozessumgebung erneut aus /proc/<pid>/environ aus. Bestätigen Sie, dass Ihre Opt-outs weiterhin auf den laufenden Prozess angewendet werden.
3. Geben Sie die Einstellungsdateien des Projekts erneut aus. Ein git pull kann eine Konfigurationsdatei einbinden, die ein Kollege geändert hat.
4. Führen Sie die SNI-Aufzeichnung während einer vollständigen Sitzung mit realer Arbeit aus. Vergleichen Sie die Hostnamenliste mit Ihrer letzten Liste.
5. Prüfen Sie den Drop-Zähler der Firewall. Ein neues Ziel erscheint dort normalerweise, bevor Sie es an einer anderen Stelle bemerken.

Das dauert etwa zehn Minuten. Es ist der einzige Teil des Prozesses, der nicht veraltet. Ein im August 2026 überprüfter Standardwert ist eine Tatsache über August 2026. Die Aufzeichnung ist eine Tatsache über heute.

FAQ

Kann ich verhindern, dass mein Coding-Agent meinen Code an das Modell sendet?

Nein. Jede Einstellung, die dies behauptet, beschreibt etwas anderes. Das Senden Ihres Prompts, der vom Agent gelesenen Dateien und der Ausgabe der von ihm ausgeführten Befehle an den Modell-Endpunkt ist die Grundlage der Inferenz. Die einzige Variable ist daher, wer diese Daten empfängt. Sie können den Empfänger ändern, indem Sie den Agent auf ein Cloud-Konto Ihres Unternehmens oder auf ein von Ihnen selbst betriebenes Modell verweisen. Außerdem können Sie die gesendete Datenmenge reduzieren, indem Sie den Lesezugriff des Agent beschränken. Das Deaktivieren von Analysen und Fehlerberichten hat keinerlei Einfluss auf diesen Datenfluss.

Wie sehe ich, mit welchen Hosts sich mein Coding-Agent verbindet?

Führen Sie den Agent unter einem eigenen Linux-Benutzer aus. Zeichnen Sie anschließend während der Verwendung des Agent den TLS ClientHello jeder neuen Verbindung auf: sudo tshark -i any -f 'tcp port 443' -Y 'tls.handshake.type == 1' -T fields -e ip.dst -e tls.handshake.extensions_server_name. Pro Verbindung erscheint eine Zeile mit der Zieladresse und dem angeforderten Hostnamen. Gleichen Sie die Namen mit sudo tcpdump -ni any 'udp port 53' ab. Zeichnen Sie dabei auf any auf, weil ein lokaler Resolver-Stub unter 127.0.0.53 die Anfrage zuerst verarbeitet. Führen Sie die Aufzeichnung durch, während der Agent tatsächlich arbeitet. Start-Pings und Absturzberichte erscheinen bei einer Aufzeichnung im Leerlauf nicht.

Mein Proxy zeigt keinen Netzwerkverkehr, während der Agent arbeitet. Was ist schiefgelaufen?

Entweder ignoriert der Client HTTP_PROXY und HTTPS_PROXY, oder er verwendet Certificate Pinning und lehnt Ihre CA ab. Testen Sie den Pfad zuerst mit curl. Wenn curl über den Proxy das Internet erreicht und der Agent nicht in der Liste der Datenströme erscheint, verwendet der Agent keine Proxy-Umgebungsvariablen. Einige Laufzeitumgebungen benötigen die CA auf eine bestimmte Weise. Node liest NODE_EXTRA_CA_CERTS insbesondere nur beim Prozessstart ein. Wenn Sie die Variable erst nach dem Start des Agent exportieren, hat dies daher keine Wirkung. Wenn der Proxy den Netzwerkverkehr nicht sehen kann, verwenden Sie stattdessen eine Paketaufzeichnung. Keine Anwendungseinstellung kann diese umgehen.

Verhindert das Deaktivieren der Telemetrie, dass mein Code zum Training verwendet wird?

Nein. Analysen und Absturzberichte sind ein anderer Datenfluss als die Inferenz. Durch ihre Deaktivierung werden Nutzungszähler und Stacktraces entfernt, aber jeder Prompt wird weiterhin unverändert an das Modell gesendet. Ob diese Prompts gespeichert werden und ob sie zum Training eines zukünftigen Modells verwendet werden, legen die Bedingungen Ihres Tarifs fest. Tarife für Privatkunden und kommerzielle Tarife unterscheiden sich dabei in der Regel. Das ist eine Vertragsfrage und keine Frage, die sich durch eine Paketaufzeichnung klären lässt. Prüfen Sie daher die Seite zur Datennutzung für Ihren Tarif. Wenn es darauf ankommt, vereinbaren Sie vor der ersten Sitzung einen kommerziellen Vertrag oder eine Vereinbarung zur Speicherung mit einer Aufbewahrungsdauer von null.