Claude Code se niega a crear juegos: qué permite la regla

Si Claude Code se niega a crear un juego, comprueba si pides recrear un título concreto ya existente. Para proyectos originales, aclara los derechos del diseño y los recursos, repite una tarea pequeña y reporta rechazos incorrectos reproducibles. Anthropic afirma que Claude Code debe seguir ayudando con juegos originales y juegos dentro de un género.

Guarda el rechazo exacto antes de cambiar el prompt, el modelo o la configuración. Lo necesitarás para distinguir una confusión sobre derechos de un cambio de comportamiento más amplio.

¿Qué cambió y qué es tengu_heron_brook?

A fecha de 2026-11-05, la confirmación de Anthropic abarca dos frases del prompt de Claude Code para Opus 5.5. No demuestra que todos los modelos Claude o todas las solicitudes directas a la API reciban esa misma instrucción.

La regla publicada en el artículo de Game Developer del 30 de octubre dice, traducida al español:

Crea juegos originales, juegos de un género y juegos a partir de los diseños y recursos propios del usuario. No recrees un juego concreto que ya exista, aunque se le cambie el nombre o se lo presente como original.

En su declaración del 30 de octubre, Addy Osmani, de Anthropic, confirmó el cambio del prompt. Explicó que su objetivo era evitar infracciones de los derechos de propiedad intelectual. Añadió que los juegos originales, los juegos de un género y los proyectos con diseños y recursos propios debían seguir funcionando. Game Developer informó de que un portavoz de Anthropic remitió a la publicación a esa declaración.

El informe original de Chasm atribuyó el cambio a un campo enviado desde el servidor llamado tengu_heron_brook, que habría llegado alrededor del 27 de octubre. Chasm también afirmó que no había un ajuste para desactivarlo.

Estos detalles de implementación siguen siendo afirmaciones atribuidas a sus autores. Incluye tengu_heron_brook como contexto en un informe de error; no lo trates como una clave de configuración admitida. La declaración de Osmani confirma el propósito y el contexto del modelo, pero no ofrece una opción para desactivar la regla ni un proceso detallado de excepciones.

¿Qué proyectos de juegos encajan en el límite anunciado?

Identifica el trabajo concreto y los derechos que lo respaldan antes de cambiar el prompt. La declaración describe el comportamiento previsto; no garantiza que todas las solicitudes que encajen vayan a funcionar.

Proyecto	Qué respalda la declaración	Siguiente paso útil
Un juego original con diseño y recursos propios	Se pretende que siga funcionando	Proporciona una descripción concreta y una tarea de programación acotada.
Un prototipo de un género, como plataformas o construcción de mazos	Se pretende que siga funcionando	Especifica tus propias mecánicas, niveles, textos y recursos visuales.
Desarrollo de un juego existente de tu estudio	Es relevante la aclaración sobre diseños y recursos propios	Explica tu función e identifica el material que controla tu estudio.
Una adaptación, un port o un mod para un cliente	La declaración no describe una excepción general	Explica la autorización, su alcance y el material de terceros utilizado.
Recrear un juego concreto ya existente, incluso con otro nombre	La regla publicada rechaza expresamente esta categoría	Aclara el alcance y los derechos del proyecto; cambiar su etiqueta no resuelve el problema.

La descripción del género debe servir para elaborar tu propia especificación. Pedir los niveles y la presentación de otro juego con un nombre nuevo sigue describiendo una recreación.

Para un proyecto original acotado, la guía para crear un nivel jugable en Unreal ofrece un punto de partida útil. Documenta el diseño, la procedencia de los recursos y las pruebas de aceptación.

¿Qué hacer si Claude Code rechaza tu propio juego?

Explica la procedencia concreta del material y solicita una tarea pequeña de programación. Una descripción clara ayuda a distinguir tu proyecto de una petición para reproducir el juego de otra persona.

Para quien haya creado el diseño del siguiente ejemplo, esta descripción sería apropiada:

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.

Usa datos veraces sobre tu proyecto. No apliques esa declaración a materiales que no hayas creado ni tengas derecho a utilizar.

Para encargos de clientes, identifica al titular de los derechos y el permiso que cubre la tarea solicitada. Explica qué recursos abarca, si autoriza la adaptación y cómo se distribuirá el resultado. Un recibo de compra y una autorización de la editora acreditan hechos distintos. Por ejemplo, la legislación de Estados Unidos distingue entre poseer una copia física y ser titular de los derechos de autor.

El conocido issue #106167 de GitHub exige mantener esa distinción. Su autor, lerugray, de Conflict Simulations LLC, corrigió la descripción original el 30 de octubre. Los encargos inicialmente no tenían licencia de las editoras: los clientes poseían copias de los juegos y aportaban los materiales.

El 4 de noviembre, el autor afirmó haber obtenido autorización escrita de las editoras para ambos encargos. Según esa actualización, Claude Code levantó el bloqueo del segundo encargo. También indicó que el problema de los dos encargos había quedado resuelto.

Ese resultado procede del relato de un desarrollador que aportó permisos adicionales. No demuestra que exista un programa oficial de excepciones ni garantiza el mismo resultado para otros proyectos.

Si tus derechos están claros, repite la tarea acotada en una sesión nueva con la misma descripción precisa del proyecto. Conserva los datos relevantes sobre la titularidad y las licencias. Si vuelve a rechazarla, guarda la respuesta y reporta el caso. Si funciona, continúa con una tarea representativa del proyecto y verifica el resultado antes de ampliar el alcance.

¿Cómo reportar un rechazo incorrecto?

Usa /bug en la sesión afectada con un ejemplo mínimo que no contenga información sensible. La referencia actual de comandos documenta cómo elegir cuánto historial de la sesión incluir. También exige una confirmación en la pantalla de consentimiento antes del envío.

Con una conexión directa autenticada en Anthropic, el informe se envía a Anthropic. Con un proveedor externo, o sin credenciales de Anthropic, Claude Code crea un archivo local en ~/.claude/feedback-bundles/. Debes enviar ese archivo por tu cuenta.

Incluye los datos necesarios para reproducir el fallo:

• Fecha y hora en UTC, salida de claude --version, modelo solicitado, cuenta y ruta de acceso al proveedor.
• El prompt y el rechazo exactos, junto con el ejemplo mínimo relevante del proyecto.
• Un resumen de derechos que distinga material original, recursos con licencia y autorización del cliente.
• El resultado esperado y si la misma solicitud falla en una sesión nueva.

No publiques contratos, credenciales ni material que permita identificar a un cliente en los issues públicos. Usa un canal privado de soporte adecuado para las pruebas que no puedas compartir públicamente.

Si tu ejemplo coincide con el issue #106167, añade allí los datos relevantes. En caso contrario, crea un informe específico con la plantilla del repositorio.

Osmani también invitó a enviarle casos en los que Claude rechace trabajo que pertenece al usuario. Su declaración del 30 de octubre contiene esa invitación. No promete un plazo de revisión ni una aprobación automática.

¿Cómo detectar cambios sin actualizar la CLI?

Ejecuta una prueba pequeña y repetible, y compara los resultados a lo largo del tiempo. Que la versión de la CLI no cambie no demuestra que el comportamiento siga igual.

Mantén constantes la cuenta, la ruta del proveedor y la revisión del proyecto. Conserva también las instrucciones, los permisos y los ajustes relevantes. Registra el modelo solicitado y los metadatos del modelo recibidos en la respuesta. Usa un ID completo, como claude-opus-5-5, para evitar que un alias cambie la versión solicitada. La guía para seleccionar Opus 5.5 detalla esa configuración.

El siguiente script de comprobación en Bash compara una pequeña solicitud para un juego original con otra similar sin contexto de juego. Registra el prompt, la respuesta, los errores, el código de salida, la versión de la CLI y la hora de inicio.

Necesitas una instalación de Claude Code ya autenticada y jq instalado. Ejecuta el script desde un directorio de pruebas controlado cuya configuración hayas revisado. La opción de bloqueo impide las llamadas del modelo a herramientas. Los hooks de inicio, acciones configuradas para el arranque, pueden seguir ejecutándose.

Guarda este ejemplo como game-probe.sh y ejecuta bash game-probe.sh:

#!/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"

La referencia de la CLI documenta los controles del modelo y de las herramientas. La guía de uso programático explica el modo no interactivo, la salida JSON y la lectura del resultado.

El comando no incluye --continue ni --resume. Solicita un nivel de esfuerzo medium mediante CLAUDE_CODE_EFFORT_LEVEL. Mantén también sin cambios las políticas de la organización.

El script crea un directorio temporal con los datos de la comprobación. Si defines TMPDIR, debe apuntar fuera del proyecto de pruebas. Así las respuestas guardadas no alteran el contenido del repositorio.

Considera aceptada la respuesta solo si proporciona la función solicitada y las pruebas. Para 0 debe devolver 1; para 1, 2; y para -1, 0. Revisa el código generado antes de ejecutarlo.

Interpreta los datos en este orden:

1. Comprueba los fallos de ejecución. Si falta el JSON o no es válido, revisa el stderr guardado y el código de salida. Los fallos de autenticación y las opciones no admitidas requieren un análisis separado.
2. Lee la respuesta. Un código de salida cero no demuestra que se haya aceptado la tarea. Revisa stop_reason cuando esté presente y lee result para detectar un rechazo en lenguaje natural o una solicitud sin resolver.
3. Comprueba los metadatos del modelo. La referencia de configuración de modelos indica que debes consultar modelUsage cuando la salida JSON oculta las advertencias de reasignación de modelos. Las entradas de modelos adicionales requieren análisis. Pueden incluir llamadas internas y no identifican por sí solas al autor de la respuesta final.
4. Compara con el resultado de referencia. Separa los resultados aceptados, los rechazos, las solicitudes de aclaración y los errores de ejecución. Si aparece un rechazo nuevo, repite la prueba antes de comunicar el problema.

Un equipo pequeño puede empezar con una ejecución diaria. Añade otra después de cambiar la configuración de forma deliberada. Investiga si una solicitud permitida pasa repetidamente de aceptada a rechazada mientras su control sigue funcionando. Conserva los datos anteriores en lugar de sustituir de inmediato el resultado de referencia.

Esta comprobación detecta un cambio de comportamiento en un caso limitado. No demuestra que haya cambiado tengu_heron_brook, y superarla no valida todo un proceso de desarrollo de juegos. Añade una tarea representativa con tus propios diseños o recursos con la licencia adecuada, seguida de pruebas en el motor o de compilación. Cada ejecución incrementa el uso de la cuenta, así que mantén pequeña la batería de pruebas y limita su duración.

¿Cómo validar un segundo modelo?

Compara un segundo modelo en la misma tarea autorizada y con las mismas pruebas de aceptación. Que otro modelo responda no demuestra que tengas permiso para reproducir un juego ajeno.

Si tu cuenta, proveedor y organización permiten Sonnet 5.5, vuelve a ejecutar la prueba guardada en Bash:

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

La ayuda de Anthropic sobre configuración de modelos documenta ambos IDs. Para trabajar de forma interactiva, usa /model para elegir un modelo disponible y /status para comprobar la selección actual. Conserva la sesión original y los datos de la prueba antes de comparar resultados.

Para otro proveedor, la documentación de selección de modelos de OpenCode describe el procedimiento interactivo. Ejecuta /connect y completa la autenticación del proveedor. Después usa /models para elegir un modelo disponible.

Envía la misma descripción con los permisos aclarados y aplica las mismas pruebas. Regístrala como una prueba independiente de cliente y proveedor, porque cambiaste más elementos que el modelo.

Si tu equipo ya usa BetterToken, consulta su guía de configuración de OpenCode. Describe un proveedor compatible con OpenAI en https://www.bettertoken.ai/v1. Ese acceso a la API es independiente de una suscripción a Claude.

Cambiar solo ANTHROPIC_BASE_URL modifica el destino de las solicitudes, no el modelo que responde. Selecciona el modelo de forma explícita y verifica los metadatos recibidos.

Compara la utilidad del código, los rechazos incorrectos, el comportamiento de las herramientas, la latencia y el consumo facturado real. Adopta la alternativa solo tras revisar el código y superar pruebas representativas del motor o de compilación. Si quedan dudas sobre los derechos, revísalas antes de continuar. No redirijas automáticamente la solicitud entre modelos hasta encontrar uno que la acepte.