Background-Agents und parallele Tasks in Claude Code

1. Was Background-Agents und parallele Tasks bedeuten

Ein Background-Agent in Claude Code beschreibt einen lang laufenden Prozess, der asynchron gestartet wird und dessen Ergebnis erst spaeter, ueber eine Benachrichtigung oder eine gezielte Statusabfrage, in die eigentliche Konversation zurueckfliesst. Das unterscheidet sich fundamental vom Standardfall, bei dem jeder Befehl synchron ausgefuehrt wird und die gesamte Session wartet, bis er beendet ist. Ein vollstaendiger Produktions-Build, eine umfangreiche Test-Suite oder ein Datenbank-Migrations-Skript kann mehrere Minuten dauern, waehrend dieser Zeit muss die Arbeit an anderen Teilaufgaben aber nicht stillstehen.

Parallele Tasks gehen noch einen Schritt weiter: Statt nur einen einzigen Hintergrundprozess laufen zu lassen, waehrend man an einer anderen Sache weiterarbeitet, koennen mehrere unabhaengige Aufgaben gleichzeitig bearbeitet werden, etwa das Recherchieren einer Bibliothek waehrend ein Build laeuft, oder das Vorbereiten einer zweiten Aenderung, waehrend die erste noch getestet wird. Der Nutzen entsteht durch die Uebertragung von Wartezeit in Nutzzeit, ein Prinzip, das aus klassischer Softwareentwicklung mit asynchroner Programmierung bekannt ist und sich direkt auf den Claude-Code-Workflow uebertragen laesst.

2. Lang laufende Befehle im Hintergrund starten

Der praktische Einstiegspunkt fuer Background-Agents ist die Moeglichkeit, einen Bash-Befehl explizit im Hintergrund auszufuehren, statt auf dessen Abschluss zu warten. Statt npm run build synchron zu starten und die Konversation fuer mehrere Minuten anzuhalten, wird der Befehl im Hintergrund gestartet, die Kontrolle kehrt sofort zurueck, und die Arbeit an einer anderen Aufgabe kann sofort beginnen. Der Prozess laeuft weiter, unabhaengig davon, ob gerade eine andere Datei bearbeitet oder eine andere Frage beantwortet wird.

Wichtig fuer sinnvollen Einsatz von Background-Agents: Nicht jeder Befehl eignet sich dafuer. Kurze Befehle, deren Ergebnis fuer den naechsten Schritt sofort benoetigt wird, etwa das Lesen einer Konfigurationsdatei, sollten synchron bleiben. Lang laufende, aber vom naechsten Schritt entkoppelte Prozesse wie Builds, vollstaendige Test-Suiten, Datenbank-Dumps oder das Herunterladen grosser Abhaengigkeiten sind die idealen Kandidaten fuer den Hintergrundmodus.

# Start a long-running build in the background instead of blocking the session
npm run build > /tmp/build.log 2>&1 &
BUILD_PID=$!
echo "Build started in background with PID $BUILD_PID"

# Continue working on other tasks immediately while the build runs
# ... edit other files, answer other questions ...

# Check later whether the background build has finished
if kill -0 "$BUILD_PID" 2>/dev/null; then
  echo "Build still running"
else
  echo "Build finished, exit code: $(wait $BUILD_PID; echo $?)"
  tail -n 20 /tmp/build.log
fi

3. Fortschritt ueberwachen und Benachrichtigungen erhalten

Ein Background-Agent ist nur dann nuetzlich, wenn sein Fortschritt und Ergebnis nachvollziehbar bleiben. Dafuer eignen sich zwei komplementaere Ansaetze: aktives Polling, bei dem man in regelmaessigen Abstaenden den Status des Hintergrundprozesses abfragt, und passives Warten auf eine Benachrichtigung, sobald der Prozess abgeschlossen ist. Aktives Polling eignet sich fuer kurze bis mittlere Wartezeiten, bei denen ein kurzer Blick auf den Fortschritt ausreicht, waehrend passives Warten bei sehr lang laufenden Prozessen wie einem vollstaendigen Regressionstest sinnvoller ist.

In der Praxis kombiniert man beides: Ein Hintergrundprozess schreibt sein Log kontinuierlich in eine Datei, ein einfacher Monitor-Loop prueft in Intervallen, ob der Prozess noch laeuft, und meldet den Abschluss inklusive der letzten relevanten Zeilen aus dem Log. So bleibt jederzeit nachvollziehbar, ob ein Background-Agent noch arbeitet, erfolgreich fertig wurde oder mit einem Fehler abgebrochen ist, ohne dass man die Ausgabe live mitverfolgen muss.

#!/usr/bin/env bash
# monitor-background-task.sh -- polls a background PID until it finishes
set -euo pipefail

PID="$1"
LOG_FILE="$2"
INTERVAL=5

while kill -0 "$PID" 2>/dev/null; do
  echo "[$(date +%H:%M:%S)] Task $PID still running..."
  sleep "$INTERVAL"
done

wait "$PID"
exit_code=$?

echo "[$(date +%H:%M:%S)] Task $PID finished with exit code $exit_code"
echo "--- last 20 log lines ---"
tail -n 20 "$LOG_FILE"

exit "$exit_code"

4. Mehrere unabhaengige Aufgaben parallel bearbeiten

Der eigentliche Produktivitaetsgewinn von parallelen Tasks zeigt sich, wenn mehrere echte Arbeitsstroeme gleichzeitig existieren. Ein typisches Szenario: Waehrend ein Background-Agent die vollstaendige Test-Suite fuer eine bereits fertiggestellte Aenderung durchlaeuft, beginnt die Arbeit bereits an der naechsten, unabhaengigen Aufgabe, etwa dem Schreiben einer neuen Komponente oder der Recherche zu einer API-Integration. Beide Arbeitsstroeme sind voneinander unabhaengig, ihr Ergebnis beeinflusst sich nicht gegenseitig, was die Grundvoraussetzung fuer sichere Parallelisierung ist.

Ein zweites haeufiges Muster sind mehrere unabhaengige Recherche-Aufgaben, etwa das gleichzeitige Untersuchen mehrerer Kandidaten-Bibliotheken fuer dieselbe Anforderung. Da reine Lesevorgaenge sich nicht gegenseitig stoeren, lassen sich solche Recherchen parallel als mehrere Background-Agents anstossen und deren Ergebnisse spaeter gebuendelt vergleichen. Entscheidend ist dabei immer die Unabhaengigkeit der Aufgaben, sobald ein Task auf das Ergebnis eines anderen angewiesen ist, verliert Parallelisierung ihren Vorteil und fuehrt stattdessen zu Koordinationsaufwand.

5. Ressourcen- und Kontextmanagement bei Parallelitaet

Parallele Ausfuehrung ist nicht kostenlos. Jeder zusaetzliche Background-Agent beansprucht CPU, Arbeitsspeicher und im Fall von Datenbankverbindungen oder Netzwerk-I/O auch begrenzte externe Ressourcen. Auf einer Entwicklungsmaschine mit begrenzten Kernen fuehrt das gleichzeitige Starten von drei vollstaendigen Build-Prozessen oft dazu, dass alle drei langsamer laufen als ein einzelner sequenzieller Durchlauf, weil sie um dieselben CPU-Zyklen konkurrieren. Die Faustregel lautet: Die Anzahl gleichzeitig laufender, ressourcenintensiver Hintergrundprozesse sollte sich an der Anzahl verfuegbarer CPU-Kerne orientieren, nicht an der Anzahl gewuenschter Aufgaben.

Ein zweiter, oft uebersehener Aspekt betrifft den Kontext der eigentlichen Konversation. Jede parallele Aufgabe, deren Ergebnis spaeter zusammengefuehrt werden muss, fuegt zusaetzliche Information in den Gesamtkontext ein. Bei vielen gleichzeitigen Background-Agents kann das dazu fuehren, dass der Kontext schneller waechst als bei rein sequenzieller Arbeit, weil Zwischenergebnisse aller parallelen Stroeme irgendwann zusammengefuehrt werden muessen. Wer parallel arbeitet, sollte deshalb bewusst nur wirklich unabhaengige und klar abgegrenzte Aufgaben parallelisieren, statt jede Kleinigkeit in einen eigenen Hintergrundprozess auszulagern.

6. Race Conditions und Konflikte vermeiden

Sobald mehrere parallele Tasks auf dieselben Ressourcen zugreifen, etwa dasselbe Arbeitsverzeichnis, dieselbe Datenbank oder dieselbe Datei, entstehen klassische Race Conditions. Zwei gleichzeitig laufende Prozesse, die beide dieselbe Datei schreiben, koennen sich gegenseitig ueberschreiben, ein Build-Prozess und ein gleichzeitig laufender Test-Lauf im selben Arbeitsverzeichnis koennen sich gegenseitig Kompilate ueberschreiben und inkonsistente Zwischenzustaende erzeugen. Diese Probleme sind nicht spezifisch fuer Claude Code, sie sind dieselben Nebenlaeufigkeitsprobleme, die aus klassischer Systemprogrammierung bekannt sind.

Die zuverlaessigste Absicherung ist strikte Ressourcentrennung: Jeder Background-Agent, der Dateien schreibt, sollte in einem eigenen, isolierten Arbeitsverzeichnis laufen, etwa ueber separate Git-Worktrees oder temporaere Verzeichnisse. Wo geteilte Ressourcen unvermeidlich sind, etwa eine gemeinsame Datenbank, hilft ein einfaches Lock-Mechanismus wie flock, der verhindert, dass zwei Prozesse gleichzeitig eine kritische Sektion betreten. Ohne diese Absicherung fuehrt Parallelisierung schnell zu schwer reproduzierbaren Fehlern, die einzeln getestet nie auftreten, aber im parallelen Zusammenspiel regelmaessig zuschlagen.

#!/usr/bin/env bash
# run-parallel-tasks.sh -- runs independent tasks in isolated directories
set -euo pipefail

MAX_JOBS=4
declare -a pids=()

run_isolated_task() {
  local task_id="$1"
  local work_dir
  work_dir=$(mktemp -d)
  (
    cd "$work_dir"
    # Each task operates in its own directory -- no shared state, no races
    git worktree add "$work_dir/repo" "task-$task_id" > /dev/null 2>&1
    cd "$work_dir/repo"
    npm test > "/tmp/task-$task_id.log" 2>&1
  ) &
  pids+=($!)
}

for task_id in 1 2 3; do
  run_isolated_task "$task_id"
  (( ${#pids[@]} >= MAX_JOBS )) && wait "${pids[0]}" && pids=("${pids[@]:1}")
done

for pid in "${pids[@]}"; do
  wait "$pid" || echo "Task with PID $pid failed"
done

7. Background-Tasks in CI/CD und Automatisierung

Das Prinzip von Background-Agents uebertraegt sich direkt auf CI/CD-Pipelines, in denen ohnehin parallele Jobs die Norm sind. Ein Claude-Code-gestuetzter Workflow kann etwa einen Deploy-Vorgang anstossen, der intern mehrere parallele Schritte enthaelt, Datenbank-Migration, Cache-Invalidierung und Asset-Build, waehrend die Session selbst auf das Gesamtergebnis wartet und currency-relevante Zwischenschritte protokolliert. Wichtig ist hier eine klare Fehlerbehandlung: Schlaegt einer der parallelen Schritte fehl, muss das Gesamtergebnis das reflektieren, statt einen Teilfehler stillschweigend zu ignorieren.

Ein weiterer sinnvoller Anwendungsfall ist das parallele Ausfuehren von Linting, Typpruefung und Unit-Tests als drei unabhaengige Background-Agents, deren Ergebnisse am Ende gebuendelt als ein einziger Statusbericht zusammengefasst werden. Da diese drei Pruefungen sich nicht gegenseitig beeinflussen, ist die Parallelisierung hier risikofrei und spart in der Praxis oft mehr als die Haelfte der Gesamtlaufzeit gegenueber einer sequenziellen Ausfuehrung derselben drei Schritte.

#!/usr/bin/env bash
# ci-parallel-checks.sh -- runs three independent checks as background agents
set -euo pipefail

npm run lint      > /tmp/lint.log 2>&1 &   LINT_PID=$!
npm run typecheck > /tmp/types.log 2>&1 &  TYPES_PID=$!
npm test          > /tmp/tests.log 2>&1 &  TEST_PID=$!

status=0
for pair in "lint:$LINT_PID" "typecheck:$TYPES_PID" "test:$TEST_PID"; do
  name="${pair%%:*}"; pid="${pair##*:}"
  if wait "$pid"; then
    echo "[PASS] $name"
  else
    echo "[FAIL] $name (see /tmp/$name.log)"
    status=1
  fi
done

exit "$status"

8. Wann sequenzielles Arbeiten die bessere Wahl ist

Nicht jede Situation profitiert von parallelen Tasks. Wenn ein Schritt zwingend das Ergebnis eines vorherigen Schritts benoetigt, etwa ein Deployment, das erst nach erfolgreichem Test-Lauf beginnen darf, ist sequenzielle Ausfuehrung nicht nur einfacher, sondern auch korrekter. Der Versuch, eine solche Abhaengigkeit trotzdem zu parallelisieren, fuehrt entweder zu unnoetigem Koordinationsaufwand oder zu tatsaechlich falschen Ergebnissen, wenn der abhaengige Schritt vor Abschluss des vorherigen beginnt.

Auch bei kleinen, schnellen Aufgaben lohnt sich Parallelisierung selten: Der Overhead, einen Background-Agent zu starten, zu ueberwachen und sein Ergebnis spaeter wieder einzusammeln, uebersteigt bei einer Aufgabe, die ohnehin nur wenige Sekunden dauert, schnell den eigentlichen Zeitgewinn. Die Faustregel bleibt: Parallelisierung lohnt sich, wenn die Aufgabe lang genug laeuft, um Wartezeit relevant zu machen, und unabhaengig genug ist, um ohne Koordinationsaufwand nebenherzulaufen. Fehlt eine dieser beiden Bedingungen, bleibt sequenzielles Arbeiten die robustere und oft auch schnellere Wahl.

# A dependent sequence must stay synchronous -- parallelizing it would be wrong
run_tests() {
  npm test
}

deploy() {
  # This step must never start before tests have actually finished successfully
  npm run deploy
}

if run_tests; then
  deploy
else
  echo "Tests failed, deployment skipped" >&2
  exit 1
fi

9. Synchron versus asynchron im direkten Vergleich

Die Entscheidung zwischen synchroner und asynchroner Ausfuehrung haengt von wenigen klaren Kriterien ab, die sich direkt gegenueberstellen lassen.

Die Tabelle macht deutlich, warum es keine pauschale Antwort gibt: Kurze, voneinander abhaengige Schritte gehoeren synchron ausgefuehrt, lang laufende, unabhaengige Aufgaben profitieren von der asynchronen Ausfuehrung als Background-Agent. Die Kunst liegt darin, diese Einordnung fuer jede konkrete Aufgabe bewusst zu treffen, statt reflexhaft alles zu parallelisieren oder reflexhaft alles sequenziell abzuarbeiten.

10. Zusammenfassung

Background-Agents und parallele Tasks uebertragen ein bewaehrtes Prinzip aus der asynchronen Programmierung auf den Claude-Code-Workflow: Lang laufende, unabhaengige Aufgaben blockieren nicht mehr die gesamte Session, sondern laufen im Hintergrund weiter, waehrend an anderer Stelle produktiv weitergearbeitet wird. Monitoring durch Polling oder Benachrichtigung haelt den Fortschritt nachvollziehbar, Isolation durch separate Arbeitsverzeichnisse oder Locks verhindert Race Conditions bei geteilten Ressourcen.

Der Nutzen entsteht nur, wenn Aufgaben tatsaechlich unabhaengig voneinander sind und lang genug laufen, um den Koordinationsaufwand zu rechtfertigen. Kurze Aufgaben und solche mit direkter Abhaengigkeit vom Ergebnis eines anderen Schritts gehoeren weiterhin synchron ausgefuehrt. Wer diese Unterscheidung bewusst trifft, gewinnt spuerbar Zeit, ohne neue, schwer reproduzierbare Fehlerquellen durch unkontrollierte Parallelisierung zu schaffen.

11. FAQ: Background-Agents und parallele Tasks in Claude Code