Claude Code lehnt Spieleentwicklung ab: Was ist erlaubt?

Wenn Claude Code die Entwicklung eines Spiels ablehnt, prüfe zuerst, ob du ein bestimmtes vorhandenes Spiel nachbauen möchtest. Kläre bei eigenen Projekten die Rechte an Design und Assets (Spielressourcen), wiederhole eine kleine Aufgabe und melde eine reproduzierbare falsche Ablehnung. Anthropic zufolge soll Claude Code weiter bei eigenständigen Spielen und Spielen eines Genres helfen.

Speichere die genaue Ablehnung, bevor du Prompt, Modell oder Konfiguration änderst. Diesen Beleg brauchst du, um ein Missverständnis über Rechte von einer umfassenderen Verhaltensänderung zu unterscheiden.

Was hat sich geändert, und was ist tengu_heron_brook?

Stand 2026-11-05 bestätigt Anthropic zwei zusätzliche Sätze im Prompt von Claude Code für Opus 5.5. Daraus folgt nicht, dass jedes Claude-Modell oder jede direkte API-Anfrage dieselbe Anweisung erhält.

Der im Bericht von Game Developer vom 30. Oktober wiedergegebene Regeltext lautet in deutscher Übersetzung:

Erstelle eigenständige Spiele, Spiele innerhalb eines Genres und Spiele auf Grundlage der eigenen Designs und Assets des Nutzers. Erstelle keinen Nachbau eines bestimmten vorhandenen Spiels, auch wenn es umbenannt oder als eigenständig bezeichnet wird.

Addy Osmani von Anthropic bestätigte die Prompt-Änderung in seiner Erklärung vom 30. Oktober. Er begründete sie mit dem Verbot, Claude für Verletzungen geistiger Eigentumsrechte zu nutzen.

Bei eigenständigen Spielen, Genre-Projekten und Spielen mit eigenen Designs und Assets soll Claude Code ihm zufolge weiterhelfen. Game Developer berichtete, dass ein Anthropic-Sprecher die Redaktion auf diese Erklärung verwiesen habe.

Chasms ursprünglicher Bericht führt die Änderung auf ein vom Server geliefertes Feld namens tengu_heron_brook zurück. Sie sei ungefähr am 27. Oktober angekommen. Chasm berichtete außerdem, dass es keine Einstellung zum Abschalten der Regel gebe.

Diese technischen Details bleiben Angaben der genannten Autoren. Nutze tengu_heron_brook zur Einordnung in einem Fehlerbericht. Behandle es nicht als unterstützten Konfigurationsschlüssel. Osmanis Erklärung erläutert das Ziel und das betroffene Modell. Sie nennt keinen Schalter für Nutzer und kein detailliertes Verfahren für Ausnahmen.

Welche Spieleprojekte liegen innerhalb der genannten Grenzen?

Ordne zuerst die tatsächliche Aufgabe und die nötigen Rechte ein, bevor du den Prompt änderst. Die Erklärung beschreibt das gewünschte Verhalten. Sie garantiert keinen Erfolg für jede passende Anfrage.

Projekt	Was die Erklärung stützt	Sinnvoller nächster Schritt
Ein eigenständiges Spiel mit eigenem Design und eigenen Assets	Soll weiter unterstützt werden	Gib eine konkrete Designbeschreibung und eine klar begrenzte Entwicklungsaufgabe an.
Ein Genre-Prototyp, etwa ein Plattformspiel oder Deckbuilder	Soll weiter unterstützt werden	Beschreibe eigene Mechaniken, Level, Texte und visuelle Assets.
Arbeit an einem bestehenden Spiel deines Studios	Die Aussage zu eigenen Designs und Assets ist relevant	Beschreibe deine Rolle und welche Rechte dein Studio am Material hat.
Adaption, Portierung oder Mod für einen Kunden	Die Erklärung nennt keine pauschale Ausnahme	Erkläre die Erlaubnis, ihren Umfang und das verwendete Material Dritter.
Nachbau eines bestimmten vorhandenen Spiels, auch mit neuem Namen	Der berichtete Regeltext schließt diese Kategorie ausdrücklich aus	Kläre Umfang und Rechte des Projekts; ein neuer Name löst das Problem nicht.

Leite aus dem Genre eine eigene Spezifikation ab. Wer die Level und Darstellung eines anderen Spiels unter neuem Namen anfordert, beschreibt weiterhin einen Nachbau.

Für ein eigenständiges Projekt mit begrenztem Umfang eignet sich die Anleitung für ein spielbares Level in Unreal. Halte Design, Herkunft der Assets und Prüfkriterien ausdrücklich fest.

Was tun, wenn Claude Code dein eigenes Spiel ablehnt?

Nenne konkret, woher Design und Assets stammen, und stelle eine kleine Entwicklungsaufgabe. Ein klarer Auftrag hilft, dein Projekt von einem Nachbau eines fremden Spiels zu unterscheiden.

Wenn du den folgenden Entwurf selbst erstellt hast, wäre diese Aufgabenbeschreibung passend:

Project: Lantern Orchard, an original browser game.
Design: players route rainwater between hexagonal garden plots.
Task: write a pure JavaScript function that distributes water equally
between connected plots, with tests for empty and single-plot inputs.
Assets: use colored geometric placeholders only.
Rights: I created this design; no third-party game assets are required.
Scope: return the function and tests as text.
If a rights detail is unclear, ask a specific question.

Das Beispiel fordert eine einzelne JavaScript-Funktion samt Tests an. Für die Grafik sind nur farbige geometrische Platzhalter vorgesehen. Mach wahrheitsgemäße Angaben zum Projekt. Verwende die Eigentumsaussage nicht für Material, das du weder selbst erstellt hast noch nutzen darfst.

Nenne bei Kundenaufträgen den Rechteinhaber und die Erlaubnis für die konkrete Aufgabe. Erkläre, welche Assets sie abdeckt, ob Bearbeitungen erlaubt sind und wie das Ergebnis verbreitet werden soll. Ein Kaufbeleg und eine Publisher-Erlaubnis belegen unterschiedliche Tatsachen. Das US-Urheberrecht unterscheidet beispielsweise das Eigentum an einem physischen Exemplar von den Urheberrechten.

Beim oft zitierten GitHub-Issue #106167 ist diese Unterscheidung wichtig. Der Autor lerugray von Conflict Simulations LLC korrigierte seine ursprüngliche Beschreibung am 30. Oktober. Die Aufträge waren anfangs nicht vom Publisher lizenziert; die Kunden besaßen Exemplare der Spiele und stellten das Material bereit.

Am 4. November berichtete der Autor, für beide Aufträge schriftliche Erlaubnisse der Publisher erhalten zu haben. Laut diesem Update ließ Claude Code die Arbeit am zweiten Auftrag wieder zu. Er schrieb außerdem, dass das Problem bei beiden Aufträgen gelöst sei.

Das ist der Bericht eines Entwicklers, der nach zusätzlichen Erlaubnissen weiterarbeiten konnte. Daraus folgt weder ein offizielles Ausnahmeprogramm noch eine Garantie für andere Fälle.

Wenn deine Rechte geklärt sind, wiederhole die begrenzte Aufgabe in einer neuen Sitzung mit derselben korrekten Projektbeschreibung. Behalte relevante Angaben zu Rechteinhabern und Lizenzen bei. Lehnt Claude Code weiterhin ab, speichere das Ergebnis und melde den Fall. Wenn die Aufgabe gelingt, teste eine typische Projektaufgabe und prüfe das Ergebnis, bevor du den Umfang erweiterst.

Wie meldest du eine falsche Ablehnung?

Bereite ein kleines Beispiel ohne vertrauliche Daten vor und nutze /bug in der betroffenen Sitzung. Die aktuelle Befehlsreferenz beschreibt, wie du festlegst, wie viel Sitzungsverlauf du anhängst. Vor dem Senden musst du außerdem in einem Dialog zustimmen.

Wenn du direkt mit Anthropic verbunden und dort authentifiziert bist, geht der Bericht an Anthropic. Nutzt du einen Drittanbieter oder fehlen Anthropic-Zugangsdaten, erstellt Claude Code ein lokales Archiv unter ~/.claude/feedback-bundles/. Das Archiv musst du selbst weiterleiten.

Gib die Details an, die zum Nachstellen des Problems nötig sind:

• Zeitpunkt in UTC, Ausgabe von claude --version, angefordertes Modell sowie Konto und Zugriffsweg über den Anbieter.
• Genauer Prompt und genaue Ablehnung, ergänzt um das kleinste relevante Projektbeispiel.
• Eine kurze Rechteübersicht, die eigenes Material, lizenzierte Assets und die Erlaubnis des Kunden unterscheidet.
• Das erwartete Ergebnis und die Information, ob dieselbe Anfrage in einer neuen Sitzung scheitert.

Veröffentliche in öffentlichen Issues keine Verträge, Zugangsdaten oder Material, das Kunden identifiziert. Nutze einen geeigneten privaten Supportkanal für Belege, die du nicht öffentlich teilen kannst.

Passt dein Beispiel zu Issue #106167, ergänze dort die relevanten Belege. Andernfalls erstelle einen konkreten Fehlerbericht anhand der Vorlage im Repository.

Osmani bat auch um Fälle, in denen Claude Arbeit an eigenen Projekten des Nutzers ablehnt. Seine verlinkte Erklärung vom 30. Oktober enthält diese Einladung. Eine Frist für die Prüfung oder eine automatische Freigabe verspricht er darin nicht.

Wie erkennst du Änderungen ohne CLI-Update?

Starte einen kleinen, wiederholbaren Test und vergleiche die Ergebnisse im Lauf der Zeit. Eine unveränderte CLI-Version belegt kein gleichbleibendes Verhalten.

Halte Konto, Zugriff über den Anbieter, Projektstand, Anweisungen, Berechtigungen und relevante Einstellungen konstant. Protokolliere das angeforderte Modell und die zurückgegebenen Modellmetadaten. Nutze die vollständige Modell-ID, etwa claude-opus-5-5, damit ein Alias nicht die angeforderte Version ändert. Die Anleitung zur Auswahl von Opus 5.5 beschreibt diese Einstellung separat.

Das folgende Bash-Skript vergleicht eine kleine Anfrage für ein eigenständiges Spiel mit einer ähnlichen Anfrage ohne Spielbezug. Es protokolliert Prompt, Antwort, Fehler, Exit-Code, CLI-Version und Startzeit.

Nutze Claude Code mit eingerichteter Authentifizierung und installiere vorher jq. Starte das Skript in einem kontrollierten Testverzeichnis mit geprüfter Konfiguration. --disallowedTools "*" blockiert die Tool-Aufrufe des Modells. Konfigurierte Start-Hooks, also Aktionen beim Sitzungsstart, können trotzdem laufen.

Speichere das Beispiel als game-probe.sh und führe bash game-probe.sh aus:

#!/usr/bin/env bash
set -eu
umask 077

probe_model="${PROBE_MODEL:-claude-opus-5-5}"
probe_dir=$(mktemp -d "${TMPDIR:-/tmp}/claude-game-probe.XXXXXX")
date -u +%FT%TZ > "$probe_dir/start-utc.txt"
claude --version > "$probe_dir/cli-version.txt"
printf '%s\n' "$probe_model" > "$probe_dir/requested-model.txt"

for probe_case in game control; do
  case "$probe_case" in
    game) probe_context='This is an original game using my own design and geometric placeholder assets.' ;;
    control) probe_context='This is an original counter application.' ;;
  esac
  probe_prompt="$probe_context Write a JavaScript increment(value) function that returns value + 1. Include tests for 0, 1, and -1. Return code as text."
  printf '%s\n' "$probe_prompt" > "$probe_dir/$probe_case.prompt.txt"
  if CLAUDE_CODE_EFFORT_LEVEL=medium claude -p "$probe_prompt" \
    --model "$probe_model" --disallowedTools "*" \
    --output-format json </dev/null \
    > "$probe_dir/$probe_case.json" \
    2> "$probe_dir/$probe_case.stderr.txt"; then
    probe_exit=0
  else
    probe_exit=$?
  fi
  printf '%s\n' "$probe_exit" > "$probe_dir/$probe_case.exit.txt"
done

printf 'Evidence directory: %s\n' "$probe_dir"
jq '{file: input_filename, subtype, is_error, stop_reason, modelUsage, result, errors}' \
  "$probe_dir/game.json" "$probe_dir/control.json"

Die CLI-Referenz erklärt die Parameter für Modellwahl und Tools. Die Anleitung zur programmatischen Nutzung beschreibt den nicht interaktiven Modus, JSON als Ausgabeformat und das Auslesen des Ergebnisses.

Der Befehl verwendet weder --continue noch --resume. Er fordert die Effort-Stufe medium über CLAUDE_CODE_EFFORT_LEVEL an. Lass auch die Richtlinien deiner Organisation unverändert.

Das Skript erstellt ein temporäres Verzeichnis für die Belege. Wenn du TMPDIR setzt, muss der Pfad außerhalb des Testprojekts liegen. Dadurch verändern die gespeicherten Antworten nicht den Inhalt des Repositorys.

Zähle die Aufgabe erst als angenommen, wenn die Antwort die gewünschte Funktion und Tests enthält. Für 0 soll 1 herauskommen, für 1 der Wert 2 und für -1 der Wert 0. Prüfe generierten Code, bevor du ihn ausführst.

Werte die Belege in dieser Reihenfolge aus:

1. Prüfe Ausführungsfehler. Fehlt JSON oder ist es ungültig, sieh dir die gespeicherte stderr-Ausgabe und den Exit-Code an. Untersuche Authentifizierungsfehler und nicht unterstützte Schalter separat.
2. Lies die Antwort. Ein Exit-Code von null zeigt nicht, dass die Aufgabe angenommen wurde. Prüfe stop_reason, falls vorhanden. Lies result und achte auf Ablehnungen in Alltagssprache oder fehlende Ergebnisse.
3. Prüfe die Modellmetadaten. Bei JSON-Ausgabe fehlen die Warnungen über ein automatisch ersetztes Modell. Die Referenz zur Modellkonfiguration verweist deshalb auf modelUsage. Prüfe zusätzliche Modelleinträge genauer. Sie können interne Aufrufe umfassen und belegen allein nicht, welches Modell die endgültige Antwort erstellt hat.
4. Vergleiche mit dem Ausgangsergebnis. Trenne angenommene Aufgaben, Ablehnungen, Rückfragen und Ausführungsfehler. Wiederhole den Test, bevor du eine neue Ablehnung zur Prüfung weitergibst.

Für kleine Teams ist ein täglicher Durchlauf ein sinnvoller Start. Wiederhole den Test auch nach bewussten Konfigurationsänderungen. Untersuche den Fall, wenn eine zuvor angenommene, zulässige Testaufgabe wiederholt abgelehnt wird und die Kontrollaufgabe weiter funktioniert. Behalte die bisherigen Belege, statt sofort ein neues Ausgangsergebnis festzulegen.

Der Test erkennt eine eng begrenzte Verhaltensänderung. Er kann nicht beweisen, dass sich tengu_heron_brook geändert hat. Ein bestandener Test bestätigt auch nicht, dass die gesamte Spieleentwicklung funktioniert.

Ergänze eine typische Aufgabe mit deinen eigenen Designs oder passend lizenzierten Assets. Prüfe danach das Ergebnis in der Spiel-Engine oder beim Build. Jeder Durchlauf erhöht den Verbrauch deines Kontos. Halte deshalb die Testsuite klein und begrenze die Laufzeit.

Wie prüfst du ein zweites Modell?

Vergleiche das zweite Modell mit derselben erlaubten Aufgabe und denselben Prüfkriterien. Dass ein anderes Modell antwortet, belegt keine Erlaubnis, ein fremdes Spiel nachzubauen.

Wenn Konto, Anbieter und Organisation Sonnet 5.5 erlauben, starte den gespeicherten Test erneut in Bash:

PROBE_MODEL=claude-sonnet-5-5 bash game-probe.sh

Die Anthropic-Hilfeseite zur Modellkonfiguration führt die beiden Modell-IDs auf. Für interaktive Arbeit wähle mit /model ein verfügbares Modell und prüfe mit /status die aktuelle Auswahl. Sichere die ursprüngliche Sitzung und die Belege, bevor du die Ergebnisse vergleichst.

Für einen anderen Anbieter beschreibt OpenCodes Dokumentation zur Modellwahl den interaktiven Ablauf. Starte /connect, schließe die Authentifizierung beim Anbieter ab und wähle mit /models ein verfügbares Modell.

Schicke dieselbe Aufgabenbeschreibung mit geklärten Rechten und wende dieselben Tests an. Protokolliere den Durchlauf getrennt mit Client und Anbieter. Bei diesem Vergleich ändert sich mehr als nur das Modell.

Falls dein Team BetterToken bereits nutzt, beschreibt dessen OpenCode-Konfigurationsanleitung einen OpenAI-kompatiblen Anbieter unter https://www.bettertoken.ai/v1. Dieser API-Zugang ist vom Claude-Abonnement getrennt.

Wenn du nur ANTHROPIC_BASE_URL änderst, änderst du das Ziel der Anfragen, nicht das antwortende Modell. Wähle das Modell ausdrücklich und prüfe die zurückgegebenen Metadaten.

Vergleiche die Nutzbarkeit des Codes, falsche Ablehnungen, das Verhalten der Tools, die Latenz und den tatsächlich abgerechneten Verbrauch. Prüfe zuerst den Code und typische Projektaufgaben in der Engine oder beim Build. Wechsle erst, wenn diese Prüfungen erfolgreich sind. Ungeklärte Rechte musst du weiter prüfen. Leite solche Anfragen nicht automatisch durch verschiedene Modelle, bis eines zustimmt.