Claude Code Refuses to Make Games: What the Rule Allows

If Claude Code refuses to make a game, first check whether the request recreates a specific existing title. For original work, clarify the design and asset rights, retry a small task, and report a reproducible mistaken refusal. Anthropic says original games and genre games are still intended to work.

Preserve the exact refusal before changing the prompt, model, or configuration. You need that evidence to distinguish a rights misunderstanding from a broader behavior change.

What changed, and what is tengu_heron_brook?

As of 2026-11-05, Anthropic’s confirmation concerns two sentences in Claude Code’s prompt on Opus 5.5. It does not establish that every Claude model or direct API request receives the same instruction.

The reported prompt rule, reproduced in Game Developer’s October 30 report, reads:

Do build original games, games in a genre, and games from the user’s own designs and assets. Do not build a recreation of a specific existing game, even if it is renamed or called original.

In his October 30 statement, Anthropic’s Addy Osmani confirmed the prompt change and linked its purpose to preventing intellectual-property infringement. He said original games, genre games, and games using the user’s own designs and assets were meant to keep working. Game Developer reported that an Anthropic spokesperson directed it to that statement.

Chasm’s original report attributed the change to a server-delivered field named tengu_heron_brook, arriving around October 27. Chasm also reported that there was no setting to disable it.

Those implementation details remain attributed reports. Treat tengu_heron_brook as context for a bug report, rather than a supported configuration key. Osmani’s statement confirms the purpose and model context, but does not provide a user-facing switch or a detailed exemption process.

Which game projects are still within the stated boundary?

Classify the actual work and the rights behind it before changing your prompt. The statement describes intended behavior; it does not guarantee that each qualifying request will succeed.

Project	What the statement supports	Useful next step
An original game with your own design and assets	Intended to keep working	Supply a concrete design brief and a bounded engineering task.
A genre prototype, such as a platformer or deck builder	Intended to keep working	Specify your own mechanics, levels, writing, and visual material.
Development of your studio’s existing game	Relevant to the statement about your own designs and assets	Explain your role and identify the material your studio controls.
A client adaptation, port, or mod	No blanket exemption is described in the statement	Explain the authorization, its scope, and any third-party material.
A recreation of a specific existing game, including a renamed version	The reported rule explicitly rejects this category	Resolve the project’s scope and rights; changing its label does not resolve the issue.

A genre description should lead to your own specification. Asking for another game’s levels and presentation under a new name still describes a recreation.

For a bounded original project, the playable Unreal level workflow provides a useful starting point. Keep the design, asset provenance, and acceptance checks explicit.

What should you do when your own game is refused?

Provide concrete provenance and ask for one small engineering task. A clear brief helps distinguish your project from a request to reproduce someone else’s game.

For a developer who created the following design, a suitable brief would be:

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.

Use truthful project details. Do not apply the ownership statement to material you did not create or acquire rights to use.

For client work, identify the rights holder and the permission covering the requested task. Explain which assets it covers, whether adaptation is authorized, and the intended distribution. A purchase receipt and publisher permission establish different facts. For example, U.S. copyright law distinguishes ownership of a physical copy from ownership of copyright.

The frequently cited GitHub issue #106167 needs this distinction. Its author, lerugray of Conflict Simulations LLC, corrected the original description on October 30. The commissions were initially not publisher-licensed; clients owned the games and supplied materials.

On November 4, the author reported obtaining written publisher permission for both commissions. In that update, they said Claude Code lifted the hold on the second commission. They also described both commissions as resolved.

That is one developer’s reported recovery after supplying additional authorization. It does not establish an official exemption program or guarantee the same result elsewhere.

If your rights are clear, retry the bounded task in a fresh session with the same accurate project description. Preserve relevant ownership and licensing facts. If it still refuses, save that result and report it. If it succeeds, continue with a representative project task and verify the output before expanding the scope.

How do you report an incorrect refusal?

Use /bug in the affected session after preparing a minimal, non-sensitive reproduction. The current command reference documents a choice of how much session history to include. It also requires confirmation on a consent screen before sending.

On a first-party connection authenticated to Anthropic, the report goes to Anthropic. With a third-party provider, or without Anthropic credentials, Claude Code creates a local archive under ~/.claude/feedback-bundles/. You must forward that archive yourself.

Include enough detail to reproduce the failure:

The UTC timestamp, output of claude --version, requested model, and account/provider route.
The exact prompt and refusal, plus the smallest relevant project example.
A concise rights summary that distinguishes original material, licensed assets, and client authorization.
The expected deliverable and whether the same request fails in a fresh session.

Keep contracts, credentials, and identifying client material out of public issues. Use a suitable private support channel for evidence that cannot be shared publicly.

If your reproduction matches issue #106167, add the relevant evidence there. Otherwise, create a focused report using the repository’s issue template.

Osmani also invited reports when Claude rejects work that belongs to the user. His linked October 30 statement provides that contact lead. It does not promise a review deadline or automatic approval.

How can you detect changes without a CLI update?

Run a small, repeatable evaluation and compare its results over time. An unchanged CLI version alone cannot establish unchanged behavior.

Keep the account, provider route, project revision, instructions, permissions, and relevant configuration fixed. Record the requested model and returned model metadata. Use a full model ID, such as claude-opus-5-5, to avoid an alias changing the requested version. The Opus 5.5 selection guide covers that configuration separately.

The following Bash probe compares a small original-game request with a similar non-game request. It records the prompt, response, errors, exit status, CLI version, and start time.

Use an authenticated Claude Code installation and install jq before running it. Run it from a controlled fixture directory with reviewed configuration. The tool-denial flag blocks model tool calls, but configured startup hooks can still run.

Save this example as game-probe.sh, then run 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"

The CLI reference documents the model and tool controls. The programmatic usage guide documents print mode, JSON output, and result retrieval.

The command supplies neither --continue nor --resume. It requests medium effort through CLAUDE_CODE_EFFORT_LEVEL. Keep organization policies unchanged too.

The script creates a temporary evidence directory. Keep TMPDIR outside the fixture so captured responses do not change its repository contents.

Mark a response accepted only if it supplies the requested function and tests. The expected arithmetic is 0 to 1, 1 to 2, and -1 to 0. Review generated code before executing it.

Interpret the evidence in this order:

Check execution failures. If JSON is missing or invalid, inspect the saved stderr and exit status. Authentication failures and unsupported flags need separate investigation.
Read the response. A zero exit status does not establish that the task was accepted. Inspect stop_reason when present, and read result for an ordinary-language refusal or an unanswered request.
Check model metadata. The model configuration reference directs JSON users to modelUsage when model-remapping warnings are suppressed. Additional model entries warrant investigation; they can include internal calls and do not alone identify the final answer’s author.
Compare with the baseline. Keep accepted, refused, clarification-needed, and execution-error outcomes separate. Repeat a new refusal before escalating it.

For a small team, a daily run and a run after deliberate configuration changes are reasonable starting points. Review a change when an allowed fixture repeatedly moves from accepted to refused while its control still works. Preserve the earlier evidence instead of replacing the baseline immediately.

This probe detects a narrow behavior change. It cannot prove that tengu_heron_brook changed, and passing it does not validate a whole game-development workflow. Add a representative task using your own designs or appropriately licensed assets, followed by engine or build checks. Each run consumes account usage, so keep the suite small and bound its runtime.

How should you validate a second model?

Compare a second model on the same authorized task, with the same acceptance checks. A different model’s willingness to answer does not establish permission to reproduce someone else’s game.

If your account, provider, and organization permit Sonnet 5.5, rerun the saved probe in Bash:

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

Anthropic’s model configuration help page documents both model IDs. For interactive work, use /model to select an available model and /status to inspect the current choice. Preserve the original session and evidence before comparing results.

For a different provider, OpenCode’s model-selection documentation describes the interactive path: run /connect, complete the provider’s authentication, then use /models to choose an available model. Submit the same rights-cleared brief and apply the same tests. Record this as a separate client/provider trial because more than the model changed.

For teams already using BetterToken, its OpenCode configuration guide documents an OpenAI-compatible provider at https://www.bettertoken.ai/v1. That API route is separate from a Claude subscription.

Changing ANTHROPIC_BASE_URL alone changes routing, not which model answers. Select the model explicitly and verify the returned metadata.

Compare usable code, mistaken refusals, tool behavior, latency, and actual billed usage. Adopt the alternative only after code review and representative engine or build checks pass. Keep unresolved rights questions in the review process instead of routing them automatically until some model accepts them.