Anthropic's Claude game cloning rule allows originals

The Claude game cloning rule consists of two new sentences in Claude Code's prompt on Opus 5.5 that steer it away from recreating specific existing games—even under a different name—while leaving original games an intended use. Here is how to scope an original project, investigate unexpected refusals, and distinguish the confirmed restriction from unresolved questions about modding and preservation.

For developers prototyping games, that distinction decides whether a request gets assistance or a refusal. The confirmed prompt change follows concern that AI-assisted copies could reach players before the games they imitate. Digital Sun Games cancelled an upcoming public playtest of ReVamp over that risk.

The Claude game cloning rule targets recreation, not game development

The restriction targets recreation of a particular existing game, not game development as a category. Anthropic member of technical staff Addy Osmani explained the company changed Claude Code's prompt on Opus 5.5 because using Claude to infringe intellectual property violates its usage policy.

Chasm spotted the rule under the internal identifier tengu_heron_brook, with the change reportedly pushed on October 27, 2026. Anthropic's confirmation was added to the reporting on October 30. Earlier descriptions of the restriction as entirely unconfirmed are outdated.

The wording explicitly permits original games, games within a genre, and games built from a user's own designs and assets. It also explicitly rejects treating a different name or an assertion of originality as sufficient to make a recreation acceptable.

“Original games, genre games, and games built from your own designs and assets are meant to keep working. We'll continue to iterate to ensure we're striking the right balance.”

— Addy Osmani, Anthropic member of technical staff

That distinction matters when describing a project. A broad genre supplies context; a particular existing game supplies a recreation target. The announced intention is to preserve the former while steering the assistant away from the latter.

Map requests to the stated categories

The following interpretation of the published rule maps common requests to its stated categories, rather than documenting tested model responses.

Say you are designing a platformer with your own levels and art. Describe those actual designs and the behavior you want implemented. There is no need to turn the brief into a request to reproduce a famous title merely to communicate the genre.

Server-side delivery changes the debugging question

The Claude game cloning rule arrives from Anthropic rather than through a user-controlled local setting, according to reports of server-side delivery. Chasm also reported no way to disable it. Those delivery details remain reported observations; Anthropic's quoted confirmation specifically establishes the prompt change on Opus 5.5.

If the server-side description is correct, pinning or downgrading an installed client would not pin this instruction. A refusal could appear without a corresponding local upgrade. That shifts the debugging question from which local package changed to whether the hosted assistant's instructions changed.

The internal identifier is not a documented configuration switch. Its appearance in reporting does not establish a command, environment variable, or editable setting that controls the behavior.

Focus investigation on whether the request genuinely describes original work and, if so, whether the refusal should be reported as an incorrect application of the rule.

Scope the project and document refusals

A practical response is to make the project's actual design and ownership clear, then preserve enough context to investigate a refusal. These are workflow recommendations, not a guaranteed way to obtain a particular answer.

1. Write the brief around your own game. Begin with the intended genre, the designs being implemented, and the assets available for the project. If the task is genuinely to recreate someone else's specific game, changing its title does not address the restriction. If it is original work, describe that work directly rather than presenting it as a clone with substitutions.

2. Distinguish your designs and assets from reference material. For an original project, identify which level layouts, artwork, and other supplied material are yours. This follows the permitted category Anthropic named; it should not be treated as proof that every request will pass. Be accurate about ownership rather than adding a blanket originality claim to a reproduction.

3. Keep the request, refusal, and date together. Recording the prompt and when the behavior occurred can help reveal a pattern if the assistant's responses shift. Where relevant, note that the request used Opus 5.5, the model named in Anthropic's confirmation. Preserve the actual exchange rather than reconstructing a shorter version from memory.

4. Report refusals involving your own work. Osmani explicitly invited developers to send him cases where Claude turns down something they own. Include the project context and the relevant exchange so the distinction between original development and recreation is visible. That invitation provides a feedback route, not a promise that a particular request will be accepted.

Ownership, modding, and preservation stay unresolved

The confirmed rule does not explain how ownership is established. It remains unclear how the assistant distinguishes a user's own game idea or assets from someone else's material. The published wording gives developers an intended boundary, but not a reliable test for every borderline request.

Ports, decompilation, rewrites, and modding also remain unresolved in the reporting. Some coverage describes the restriction more broadly, but the rule itself addresses recreations of specific existing games. That is not enough to conclude that every modding task is blocked, or that every preservation project is permitted.

I'd treat a refusal as a product-policy decision, not as a ruling on copyright. Likewise, receiving generated code should not be treated as an ownership determination. Anthropic's statement explains the usage-policy motivation; it does not settle the rights associated with an individual project.

The restriction also cannot be assumed to end AI-assisted copying. Reporting raises the possibility that determined users could sidestep model guardrails or move to open-weight models without the same restrictions. That limits what this change can establish for studios deciding whether to expose an unfinished game through a public playtest.

What this means for your workflow

For an original game, keep using Claude Code where it helps, while describing the actual design instead of using an existing title as the implementation specification. That choice follows Anthropic's stated intention to keep original and genre-based development working.

For a workflow centred on recreating a particular existing game, the Claude game cloning restriction is directly relevant. Renaming the project is not an answer. For modding or preservation work, the unresolved scope deserves checking against the actual task rather than assuming either blanket permission or a blanket ban. The useful response is a clearer brief and documented feedback—not an invented local configuration fix.