# Destroy Any Website: How Claude Opus 5.5 Built a Web-Wrecking Game in One Session

How Claude Opus 5.5 built destroyanywebsite.org in one Claude Code session: architecture, testing, the bugs it fixed, and a link to wreck aiidelist.com.

Canonical URL: https://aiidelist.com/blog/claude-opus-5-5-destroy-any-website

Language: en

Published: 2026-10-01

Updated: 2026-10-01

## Key Takeaways

- **[destroy any site](https://destroyanywebsite.org/?url=aiidelist.com)** is a free browser game that turns any web page into a destructible pixel level. Its first version was built by **Claude Opus 5.5** in a single Claude Code session.
- The human input was a one-line request in Chinese: rebuild the idea behind destroyanywebsite.com and Sprite Fusion's Destroy Any Website, and make it different. Follow-ups were equally short: commit, add more gameplay, deploy to the new domain, add SEO.
- From an empty folder, Opus 5.5 had a working single-player and multiplayer game committed in **about 80 minutes**, and the site was live on its custom domain **about three and a half hours** after the session started, including time spent waiting for DNS.
- That first version is **8 commits, 8,638 lines of TypeScript in 22 files and 1,551 lines of CSS**, spanning a Cloudflare Worker, a DOM-to-pixel level builder, a game engine, Durable Object multiplayer, and deployment.
- The most useful capability on display was not raw code output. It was **checking its own work in a real browser**, reading the screenshots, and fixing root causes, from a load-event race to a font whose "5" looked like an "S".
- You can try the result on this site right now: **[destroy aiidelist.com](https://destroyanywebsite.org/?url=aiidelist.com)**.

![The stick-figure demolition worker laser-cutting the aiidelist.com homepage, with a red 拆 stamp burned into the search bar](https://cdn.aiidelist.com/api/image/JDUVPT6M2gpmwgzuRSl36.webp)

## Wreck aiidelist.com in One Click

This link loads our homepage into the game and drops you straight into it:

**[destroy any site](https://destroyanywebsite.org/?url=aiidelist.com)**

Nothing on aiidelist.com is touched. The game fetches a copy of the page, lays it out in a sandbox, and turns the result into a level that only exists in your browser tab. The heading, the tool cards, the search box and every border become solid pixels you can stand on, shoot, burn and blow apart.

Two variations worth trying:

- [A 60-second contract on aiidelist.com](https://destroyanywebsite.org/?url=aiidelist.com&mode=contract): chain combos for a payout and a grade from S to D.
- [A hit list on aiidelist.com](https://destroyanywebsite.org/?url=aiidelist.com&mode=hitlist): eight real elements of the page are marked as targets, and you race the clock to take them out.

Controls are simple: **A/D** to run, **Space** to jump (press again mid-air to flip, hold to jetpack), the mouse to aim and shoot, right click for a grenade, **1–7** to switch weapons and **Q** for the stamp. On a phone, a joystick appears and you hold the screen to fire.

![The Destroy Any Website title card with aiidelist.com typed into the address field](https://cdn.aiidelist.com/api/image/KsoE2Bf-ij6Dm-3fXhWCo.webp)

## The Brief

The starting point was two existing versions of the same idea. We covered the original in [Destroy Any Website: Inside Sprite Fusion's Viral Stickman Browser Game](https://aiidelist.com/blog/destroy-any-website): type a URL, and the page becomes a level for a small armed stickman.

The request to Claude Opus 5.5 was short: recreate destroyanywebsite.com, combine it with the Sprite Fusion version, and add some differentiation.

The first thing Opus did was look at how the references actually worked. It fetched both sites and noticed that, at the time, they served the same JavaScript bundle. It probed the page endpoint to understand the general approach (a server fetches the page and strips scripts; the browser lays it out and reads the result). Then it made a decision it stated up front: it would rebuild the concept with its own code, art, sound and copy instead of reusing anyone's bundle, fonts or icons.

That set the tone for the rest of the session. The game design was the reference; the implementation and identity were new.

## What It Built

The result plays like the original idea but has its own personality: a Chinese demolition-crew theme (网页拆迁队, roughly "web demolition crew") with hazard-stripe UI, a stick figure in a hard hat, and a red 拆 ("demolish") stamp as the logo.

On top of the core loop, the first session added:

- **Seven tools plus grenades**: nail gun, SMG, shotgun, rocket launcher, laser cutter, a flamethrower whose fire actually spreads along text and images, and a wrecking ball that swings on a chain with real pendulum physics.
- **A 拆 stamp ultimate** that charges as you destroy, then slams a giant stamp into the page and leaves a red mark on the background.
- **Three single-player modes**: free wreck, a 60-second contract with combo multipliers and grades, and the hit list.
- **Multiplayer rooms** for up to six players, with co-op and a 90-second race instead of a deathmatch.
- **Five world skins** (original, handheld green, neon, newsprint, thermal) that recolor the whole page, and **seven unlockable hats** earned through achievements.
- **Optional site events**: parachuting supply crates with power-ups, and repair drones that fly to your damage and rebuild the page until you shoot them down.
- **A shareable demolition certificate** with before-and-after thumbnails, plus Chinese and English UI, touch controls, an embeddable badge and a bookmarklet.

![A demolition certificate for aiidelist.com showing the page before and after, 24.8% wrecked, an S grade and several red 拆 stamps](https://cdn.aiidelist.com/api/image/xNSTpXjS8Hgc6K3z-4GZ6.webp)

## How It Works

The architecture Opus chose has four parts.

**1. An edge proxy.** A Cloudflare Worker fetches the requested page and rewrites it with HTMLRewriter. It removes every script and inline event handler, fixes common lazy-loading patterns so images actually load, and routes CSS, images and fonts through a same-origin resource proxy. That last step matters: the browser can only read pixels from images that come from the game's own origin.

**2. A level builder.** The cleaned HTML is laid out in a sandboxed iframe with scripts disabled, at the width of your screen. The builder walks the DOM and turns backgrounds, borders, images, inline SVG and text into a display list, measuring wrapped text word by word. Everything is painted at half resolution into three layers: solid page pixels, background scenery, and a material map that knows which pixels were text, images or boxes.

**3. A game engine.** The page becomes a grid of 2×2-pixel cells. Weapons carve circles out of it, debris flies off as particles in the page's own colors and settles as rubble, and fire spreads cell to cell. Particles are written straight into a pixel buffer, so effects match the terrain's pixel look. All sound effects are synthesized live with the Web Audio API; there are no audio files.

**4. Multiplayer on Durable Objects.** Each room is one Durable Object. The host builds the level, compresses it and uploads it in chunks; other players download it. Destruction is sent as batched events, and the host runs the fire simulation for everyone so terrain stays consistent. Players who join mid-match receive a snapshot of the current, already-damaged page.

## What Opus 5.5 Did Well

### It tested in a real browser and read its own screenshots

Opus wrote Playwright scripts that loaded real sites, played the game with keyboard and mouse input, and captured screenshots at each step. Then it looked at them.

Several of the best fixes came from that loop rather than from type errors:

- On the first Wikipedia run, the page appeared completely unstyled. Opus traced it to HTMLRewriter returning attribute values exactly as written in the source, so `&` inside stylesheet URLs was never decoded. It confirmed the behavior with a throwaway Worker route before changing the code.
- Words ran together at link boundaries ("known asrazingandwrecking"). The cause was subtle: single-line text was measured with its trailing space, then drawn without it, so the text stretched across the gap. The fix measures only the visible characters.
- The countdown read "82.9" when it should have read "52.9". Opus rendered a test card of digits and confirmed that the pixel font drew "5" like "S" and "2" like "Z", then compared four replacements before switching.

### It went after root causes

A few bugs only showed up intermittently, and Opus kept digging until it found the mechanism:

- Some pages randomly loaded as "nearly empty". Chrome fires a synchronous `load` event for an iframe's initial `about:blank` document, so the builder sometimes read the page before it existed. The fix sets the source before insertion and ignores loads that are not the real document.
- In multiplayer, guests got stuck downloading levels. Replaying the protocol with raw WebSockets showed the room storing zero bytes: in the development runtime, binary frames did not arrive as the `ArrayBuffer` the code expected. Messages are now normalized and processed through an ordered queue so an asynchronous read can never let "upload finished" overtake the data.
- Supply crates flickered between "landed" and "falling" every frame because the support check looked at a slightly different band of pixels than the landing check.

### It treated deployment and security as part of the job

Some of the most valuable decisions were about things that never show up in a demo:

- The page proxy blocks private and local addresses, re-validates every redirect, and serves everything with a locked-down Content Security Policy, so proxied HTML can never run script on the game's own domain. The page itself is laid out in an iframe with scripts disabled.
- The resource proxy signs every URL it generates with an HMAC, so it cannot be hotlinked as a free general-purpose proxy. Secrets were passed to Wrangler through temporary files and never printed.
- A `wrangler deploy --dry-run` revealed that the production bundle would have shipped a development-only proxy setting, simply because the developer's shell had a proxy configured. Deployed, every page fetch would have failed. Opus caught it before the first real deploy.
- When the brand-new domain refused TLS connections, Opus queried the `.org` registry directly and found the delegation had not been published yet, then waited for the certificate instead of changing working configuration.

### It was explicit about what it did not verify

At each stopping point, the summary separated what had been tested from what had not: race-mode timeouts that were never waited out, Safari, real phones, and game-balance numbers that were first guesses. That is less exciting than a demo video, but it is what makes an agent's work safe to build on.

![The same aiidelist.com page in four world skins: neon, newsprint, thermal and handheld green](https://cdn.aiidelist.com/api/image/S43xz__m79zct--d7AmYv.webp)

## Hit List, Skins and Multiplayer

The second round of work came from another one-line prompt asking for more gameplay or skins on a separate branch. Opus planned five features, built them one at a time, tested each in the browser and shipped them in four commits.

The hit list is a good example of grounding a feature in the actual page. While building a level, the game records visible images, headings, buttons and short links. Hit list mode picks eight that are spread down the page and do not overlap, labels each with its real text, and tracks how much of it is left. Testing on Wikipedia exposed a flaw: links inside collapsed menus have a layout box but are never painted, so targets appeared around the wrong content. Candidates now have to be mostly visible inside their clipping region.

![Hit list mode on aiidelist.com, with the Models and Guides links marked as targets and a running clock](https://cdn.aiidelist.com/api/image/0iAemUrW-EePwVmb0Gllp.webp)

Multiplayer uses the same terrain as single player. Each player's hat and color are visible to everyone else, explosions from other players knock you around, and a live scoreboard tracks how many cells each person has destroyed.

![Two players, Opus and Guest, wrecking the demo site together with a live scoreboard](https://cdn.aiidelist.com/api/image/CkAkNBV_Z0hkV2gxt1Y6R.webp)

## Where It Falls Short

The project is fun, but it has real limits, and Opus reported most of them itself:

- **JavaScript-only sites barely work.** Pages are laid out with scripts disabled, so many single-page apps load as an almost empty level.
- **Some sites refuse the fetch.** In production, Hacker News (sometimes), Bilibili and The New York Times rejected requests from Cloudflare Workers. The game now shows a clear "bot protection" message instead of a bare status code.
- **Long pages are cut off** at roughly four to five screens to keep the level fast.
- **One multiplayer bug is open at the time of writing.** On a large page like aiidelist.com, a guest can fail to load the shared level while the host plays normally. Single player is unaffected, and multiplayer on smaller pages works.
- **Not everything was verified.** Safari and real phones were not fully tested in that session, and balance values such as drone repair speed and power-up timing were first guesses.

It is also worth being clear about authorship. The game in this article was built by Claude Opus 5.5 with short instructions from a human, who bought the domain, made the calls on what to ship, and has since migrated the site to Astro and added guides and sharing features. The live site includes those later changes.

## What This Says About Claude Opus 5.5

Most of the individual pieces here are not new. Proxies, canvas rendering, particle effects and WebSocket rooms are all well understood.

What stands out is the combination. One session covered research, architecture, an edge proxy, a rasterizer, a game engine, real-time multiplayer, testing, security hardening, deployment, DNS and SEO. Opus moved between those layers without losing track of earlier decisions, and it kept verifying behavior in a real browser instead of trusting that code which type-checks also works.

For developers, the practical lesson is how little the prompts needed to say. None of them specified an architecture, a test strategy or a security posture. Those came from the model. The human role shifted toward taste and decisions: which features matter, which domain to buy, when to ship.

The fastest way to judge the result is to play it. Load **[aiidelist.com into the game](https://destroyanywebsite.org/?url=aiidelist.com)**, or try any other site at **[destroyanywebsite.org](https://destroyanywebsite.org/)**.