Claude Code: Hohe CPU-Last auf dem Remote-Mac? Diagnoseleitfaden 2026

Symptom: Claude Code läuft auf dem Remote-Mac, und die CPU-Auslastung bleibt hoch.
Schnellste Prüfung: Ordnen Sie die Aktivität zuerst einer konkreten Aufgabe und ihrer Prozesshierarchie zu; behandeln Sie einen unbekannten Prozess nicht durch Löschen oder erzwungenes Beenden.

Das gilt unabhängig davon, ob Sie gerade Code analysieren, bauen oder testen lassen: Hohe CPU-Last allein beweist weder einen Fehler in Claude Code noch eine Sicherheitsverletzung.

Dieser Leitfaden ist für Sie, wenn Sie Claude Code auf einem Remote-Mac einsetzen und Agent, Build und andere Prozesse auseinanderhalten müssen.
Er richtet sich auch an macOS-Engineers, die nach einer getrennten Terminal-Sitzung weiterlaufende Aufgaben untersuchen.
Kleine Teams mit dauerhaft erreichbaren Macs finden hier ein Vorgehen für sichere Untersuchung, Eingrenzung und Nachkontrolle.

Letzte Aktualisierung: 26.10.2026. Die Angaben wurden anhand der Apple-Dokumentation zur CPU-Aktivität, der Dokumentation zur Prozesshierarchie und der Claude-Code-CLI-Dokumentation geprüft. Die Einordnung des Medienberichts bleibt auf den dort geschilderten Einzelfall begrenzt.

Hohe CPU-Last bei Claude Code auf dem Remote-Mac einordnen

Öffnen Sie die Aktivitätsanzeige und prüfen Sie die CPU-Aktivität zusammen mit der Prozessliste. Apple beschreibt, wie Sie dort CPU-Aktivität anzeigen und Prozesse untersuchen können. Entscheidend ist nicht allein, welcher Prozess oben steht, sondern ob sich dessen Aktivität mit dem laufenden Auftrag erklären lässt. Apple: CPU-Aktivität in der Aktivitätsanzeige anzeigen

Notieren Sie zunächst, was Claude Code zu diesem Zeitpunkt tatsächlich erledigt: Codeanalyse, Dateiänderungen, Build, Tests oder ein anderes Werkzeug. Halten Sie außerdem fest, ob Sie eine einzelne Aufgabe oder mehrere parallele Abläufe gestartet haben. Erst mit diesem Bezug lässt sich beurteilen, ob ein hoher Ressourcenverbrauch zur Arbeit passt oder weiter untersucht werden muss.

Prüfen Sie die Prozesshierarchie, wenn die Zuordnung nicht offensichtlich ist. Ein Build-Werkzeug oder Testprozess kann von einem anderen Prozess gestartet worden sein; ein ähnlich klingender Name beweist jedoch keine direkte Verbindung. Die Aktivitätsanzeige bietet Informationen zu Prozessen und ihrer Hierarchie, mit denen Sie Eltern- und Kindprozesse besser einordnen können. Apple: Prozessinformationen und Hierarchieansicht

Wichtig: Verwenden Sie eine CPU-Anzeige nicht als starre Fehlergrenze. Ob die Aktivität auffällig ist, hängt davon ab, welche Arbeit gerade läuft und welche weiteren Prozesse parallel rechnen.

Laufende Analyse oder Build-Arbeit prüfen

Während Claude Code aktiv arbeitet, untersuchen Sie zuerst den Auftrag und die tatsächlich gestarteten Werkzeuge. Eine Analyse kann gleichzeitig mit Kompilierung, Tests oder einer weiteren Entwicklungsaufgabe stattfinden. Die CPU-Last kann deshalb von mehreren Prozessen gemeinsam stammen, statt allein vom Agenten verursacht zu werden.

Szenario: Eine einzelne Aufgabe läuft noch

Vergleichen Sie die Prozessliste mit dem aktuellen Arbeitsschritt. Wenn gerade ein Build oder eine Testsuite läuft, suchen Sie nach den zugehörigen Prozessen und prüfen Sie, ob deren Aktivität während der Arbeit plausibel bleibt. Claude Code kann über seine CLI genutzt werden; die Dokumentation führt verfügbare CLI-Befehle und Optionen auf. Diese Angaben helfen, den tatsächlich gestarteten Arbeitsablauf zu verstehen, sind aber für sich genommen kein Nachweis dafür, welcher Prozess die CPU beansprucht. Anthropic: CLI-Befehle und Optionen für Claude Code

Beobachten Sie den Ablauf vor und nach einem klaren Arbeitsschritt: Ist die Aufgabe noch aktiv? Hat der Build einen Abschluss gemeldet? Geht die Aktivität der zugehörigen Prozesse danach zurück? Eine Veränderung, die zeitlich zum Abschluss passt, ist aussagekräftiger als eine Momentaufnahme. Bleibt die Last bestehen, gehen Sie zur Prozesszuordnung über, statt Claude Code pauschal neu zu starten.

Szenario: Mehrere Agenten, Builds oder Tests laufen parallel

Behandeln Sie parallele Arbeit zunächst als mehrere getrennte Aufträge. Prüfen Sie Agent, Compiler, Testläufe und andere Entwicklungswerkzeuge einzeln. Werden mehrere Aufgaben gleichzeitig ausgeführt, addieren sich ihre Ressourcenansprüche; die Gesamtlast darf daher nicht ohne Prüfung einem einzelnen Prozess zugeschrieben werden.

Pausieren oder warten Sie, sofern möglich, jeweils nur eine entbehrliche Aufgabe und beobachten Sie danach die Prozessliste erneut. So lässt sich besser erkennen, welche Arbeit zur Belastung beiträgt. Beenden Sie keine gemeinsam genutzte Teamaufgabe, wenn ihre Zuständigkeit und ihr Status ungeklärt sind. Bei geplanten Builds ist es häufig sinnvoller, das Ende abzuwarten und den Verlauf zu dokumentieren, statt laufende Arbeit abrupt zu unterbrechen.

Nach Sitzungsende verbliebene macOS-Hintergrundprozesse untersuchen

Eine geschlossene SSH- oder Terminal-Sitzung ist kein Beleg dafür, dass alle zuvor gestarteten Prozesse ebenfalls beendet wurden. Ein Build, Skript, Testlauf oder eine Automatisierung kann unabhängig davon weiterlaufen. Wenn die CPU-Last nach dem Sitzungsende anhält, erfassen Sie daher zuerst Prozessname, Hierarchie und den bekannten Startauftrag.

Szenario: Die Sitzung ist beendet, die Last bleibt bestehen

Öffnen Sie die Aktivitätsanzeige erneut und prüfen Sie, welche Prozesse noch aktiv sind. Vergleichen Sie ihre Hierarchie mit dem Auftrag, den Sie gestartet hatten. Klären Sie dann, ob es sich um einen laufenden Build, einen geplanten Job, einen Teamprozess oder eine nicht zugeordnete Aktivität handelt. Eine Prozessbezeichnung allein reicht nicht aus, um Herkunft und Zweck festzustellen.

Wenn der Prozess zu einer eigenen Aufgabe gehört, prüfen Sie, ob die Aufgabe regulär beendet werden kann. Apple dokumentiert die verfügbaren Möglichkeiten zum Beenden eines Prozesses in der Aktivitätsanzeige; wählen Sie eine reguläre Beendigung, wenn sie für den konkreten Fall geeignet ist. Ein erzwungenes Beenden kann Arbeit verlieren lassen oder andere Abläufe stören und sollte nicht der erste Schritt sein. Apple: Prozesse in der Aktivitätsanzeige beenden

Ist der Prozess einer Teamaufgabe zugeordnet, bestätigen Sie den Status mit der zuständigen Person oder dem verantwortlichen Dienst. Ist die Herkunft unklar, sichern Sie die Beobachtungen und untersuchen Sie sie nach den Sicherheitsvorgaben Ihrer Organisation. Löschen Sie keine ausführbare Datei und entfernen Sie keine Hintergrundkomponente, bevor Sie geklärt haben, ob sie legitim, verwaltet oder Teil eines laufenden Auftrags ist.

FAQ: CPU-Last und weiterlaufende Prozesse

Wie prüfen Sie CPU-Last, während Claude Code arbeitet?

Sortieren Sie die Prozessliste in der Aktivitätsanzeige nach CPU-Aktivität und vergleichen Sie die sichtbaren Prozesse mit dem aktuellen Auftrag. Prüfen Sie, ob eine Analyse, ein Build oder ein Testlauf aktiv ist und ob Kindprozesse zu diesem Arbeitsablauf passen. Beobachten Sie auch, was nach dem Abschluss geschieht. Ein ähnlich klingender Name ist allein kein Beweis, dass ein Prozess zu Claude Code gehört.

Was tun Sie, wenn nach dem Schließen der SSH-Sitzung noch Prozesse laufen?

Ermitteln Sie zunächst, ob ein Build, Skript oder Testlauf absichtlich weiterarbeitet. Notieren Sie Prozessname und Hierarchie und gleichen Sie sie mit dem bekannten Auftrag ab. Bei einer eigenen, abgeschlossenen Aufgabe kommt ein kontrolliertes Beenden infrage. Bei unbekannter Herkunft oder gemeinsam genutzter Arbeit klären Sie Zuständigkeit und Status, bevor Sie eingreifen. Die getrennte Sitzung allein sagt nichts über den Prozessstatus aus.

Wie unterscheiden Sie einen Build von einem unbekannten Hintergrundprozess?

Suchen Sie nach einer nachvollziehbaren Verbindung zwischen Prozess, Elternprozess, Projekt und laufendem Build- oder Testauftrag. Prüfen Sie, ob sich die CPU-Aktivität mit dem Fortschritt ändert und nach Abschluss zurückgeht. Fehlt diese Verbindung, bleibt der Prozess ungeklärt. Beenden oder löschen Sie ihn nicht allein wegen seines Namens; sichern Sie die Beobachtungen und folgen Sie dem für Ihren Mac geltenden Untersuchungsprozess.

Was prüfen Sie, wenn hohe CPU-Last nach einem Neustart wiederkehrt?

Untersuchen Sie Anmeldeobjekte, verwaltete Hintergrundaufgaben und geplante Automatisierungen, die beim Anmelden oder Starten erneut aktiv werden können. Apple beschreibt, wie Sie Objekte verwalten, die beim Anmelden geöffnet werden, sowie die Verwaltung von Hintergrundaufgaben. Vergleichen Sie die gefundenen Einträge mit der erwarteten Konfiguration. Bei ungeklärter Herkunft sichern Sie relevante Informationen und veranlassen eine Prüfung nach den Sicherheitsregeln Ihres Teams. Apple: Objekte beim Anmelden automatisch öffnen Apple: Verwaltung von Hintergrundaufgaben

Wiederkehrende Belastung nach einem Neustart untersuchen

Wenn dieselbe hohe Aktivität nach einem Neustart erneut auftritt, vergleichen Sie den Zustand nicht nur mit Ihrer letzten Sitzung. Prüfen Sie, ob ein legitimer Anmeldeeintrag, eine verwaltete Hintergrundaufgabe oder ein Automatisierungsablauf die Arbeit wieder aufnimmt. Die konkrete Konfiguration kann von den Richtlinien Ihrer Organisation abhängen.

Gehen Sie dabei in einer nachvollziehbaren Reihenfolge vor:

1. Ausgangslage festhalten: Notieren Sie, wann die CPU-Aktivität auffällt, ob eine Sitzung geöffnet ist und welche geplante oder manuell gestartete Arbeit erwartet wird.
2. Prozesse identifizieren: Erfassen Sie sichtbare Prozessnamen und ihre Beziehungen. Trennen Sie Beobachtung von Vermutung; halten Sie etwa „Prozess bleibt nach Build aktiv“ fest, statt ohne Beleg eine Ursache zu behaupten.
3. Startquellen prüfen: Kontrollieren Sie bekannte Anmeldeobjekte und verwaltete Hintergrundaufgaben. Vergleichen Sie sie mit der dokumentierten Teamkonfiguration.
4. Abweichungen sichern: Halten Sie relevante Prozess- und Warnmeldungen fest und informieren Sie die zuständige Person, wenn ein Eintrag nicht zugeordnet werden kann.
5. Sicherheitsprozess anwenden: Bei einem unbekannten oder verdächtigen Eintrag folgen Sie den Regeln Ihres Unternehmens für Isolation, Prüfung und Freigabe. Ändern Sie nicht eigenmächtig gemeinsam genutzte Systemkomponenten.
6. Mit echter Arbeit nachprüfen: Führen Sie einen repräsentativen Entwicklungsauftrag aus und beobachten Sie, ob die Aktivität zum Arbeitsverlauf passt und danach zurückgeht. Dokumentieren Sie das Ergebnis, bevor Sie die Untersuchung schließen.

Ein Bericht vom Oktober 2026 beschreibt einen einzelnen Entwickler, der nach eigener Aussage mit Claude Code einen Krypto-Mining-Prozess auf seinem Mac entdeckt habe. Der Bericht ist ein Medienbericht über einen Einzelfall und keine unabhängige technische Bestätigung dafür, wie der fragliche Prozess auf diesem System dorthin gelangte. Er belegt weder, dass Claude Code generell hohe CPU-Last verursacht, noch dass eine hohe CPU-Anzeige auf Ihrem Remote-Mac eine Infektion bedeutet. Bericht über die Schilderung eines einzelnen Entwicklers

Entscheidung nach Befund

Treffen Sie die nächste Maßnahme anhand der Zuordnung, nicht anhand eines einzelnen Lastwerts. Diese Verzweigungen helfen, normale Arbeitslast von einem ungeklärten Zustand zu trennen:

• Wenn ein Build, Test oder Analyseauftrag nachweislich läuft und die beteiligten Prozesse dazu passen, dann warten Sie auf den Abschluss oder pausieren Sie gezielt eine entbehrliche Aufgabe. Sonst prüfen Sie Prozesshierarchie und Startquelle.
• Wenn die Sitzung beendet ist, der Prozess aber zu einem bekannten Auftrag gehört, dann klären Sie dessen Status und beenden ihn nur kontrolliert, falls er nicht mehr benötigt wird. Sonst sichern Sie Beobachtungen und lassen die Herkunft prüfen.
• Wenn die Aktivität nach einem Neustart aus einem dokumentierten Startobjekt oder einer erwarteten Automatisierung stammt, dann prüfen Sie deren Aufgabe und Konfiguration. Sonst behandeln Sie den Eintrag als ungeklärt und wenden die Sicherheitsregeln Ihres Teams an.
• Wenn ein Prozess gemeinsam genutzt wird oder seine Zuständigkeit nicht feststeht, dann stoppen Sie ihn nicht eigenmächtig. Stimmen Sie die Untersuchung mit dem Verantwortlichen ab.

Die CLI-Optionen und Berechtigungsentscheidungen von Claude Code können erklären, welche Aktionen ein Arbeitsablauf ausführen darf; sie ersetzen nicht die Prüfung des tatsächlich aktiven Prozesses. Nutzen Sie die CLI-Dokumentation, um den Auftrag nachzuvollziehen, und die Aktivitätsanzeige, um den beobachteten Systemzustand zu prüfen. Diese beiden Informationsquellen beantworten unterschiedliche Fragen.

Untersuchungsnotiz und Nachkontrolle

Damit sich wiederkehrende Vorfälle vergleichen lassen, führen Sie pro Untersuchung eine kurze Notiz. Erfassen Sie mindestens:

• Situation: laufende Aufgabe, beendete Sitzung oder erneutes Auftreten nach dem Neustart.
• Auftrag: Projekt, erwarteter Build, Test oder sonstige Automatisierung.
• Prozessbefund: sichtbarer Prozess, bekannte Hierarchie und Zuordnung oder offene Frage.
• Maßnahme: abgewartet, gezielt pausiert, kontrolliert beendet oder zur Prüfung eskaliert.
• Nachkontrolle: Verhalten während eines passenden Auftrags und nach dessen Abschluss.
• Weiterer Schritt: Beobachtung fortsetzen, Konfiguration prüfen oder Sicherheitsprozess auslösen.

Verwenden Sie für die Nachkontrolle einen realistischen Arbeitsablauf aus Ihrem Projekt. Eine Leerlaufbeobachtung allein reicht nicht, wenn die fragliche Last nur beim Kompilieren oder Testen entsteht. Umgekehrt sollten Sie einen Prozess, der nach Ende des Auftrags weiterarbeitet, nicht als normal einstufen, nur weil er während eines Builds plausibel gewesen wäre.

Lösungswege und Zuständigkeiten im Vergleich

Bei einem Remote-Mac gehören Zugriff und Sicherheitsorganisation zur Betriebsentscheidung. Wenn Sie per Browser auf eine Umgebung zugreifen, finden Sie auf der Seite zum Webzugriff auf den Remote-Mac den passenden Zugangskontext. Für den Umgang mit Verbindungs- und Kontodaten beachten Sie außerdem die Datenschutzhinweise.

Nächster Schritt für dauerhaftes macOS-Entwickeln

Wenn Sie für Ihre Untersuchung eine dauerhaft erreichbare macOS-Umgebung brauchen, vergleichen Sie den Aufwand mit Ihrem vorhandenen Setup: Ein lokaler Mac erfordert verfügbare Hardware und eigene Wartung; ein Linux-Server kann macOS-spezifische Build- und Testwerkzeuge nicht ersetzen; ein Remote-Mac verlangt dagegen klare Zugriffsrechte, Prozessüberwachung und eine abgestimmte Bereinigung von Aufgaben. Ein gemieteter Mac ist dann eine passende Option, wenn Sie eine temporäre oder kontinuierlich erreichbare Entwicklungsumgebung benötigen, ohne dafür sofort eigene Hardware bereitzustellen.

Halten Sie zunächst Ihre Prozessbeobachtung und die Nachkontrolle fest. Wenn Sie anschließend eine Remote-Umgebung für wiederkehrende macOS-Arbeit benötigen, prüfen Sie die Mietpläne von macworker und entscheiden Sie anhand von Laufzeit, Zugriff und Sicherheitsanforderungen Ihres Projekts.

Häufig gestellte Fragen