Claude used die() in WordPress init hook on live production site, taking it fully offline

Preflight Checklist

• [x] I have searched existing issues for similar behavior reports
• [x] This report does NOT contain sensitive information (API keys, passwords, etc.)

Type of Behavior Issue

Other unexpected behavior

What You Asked Claude to Do

I asked Claude to read a WordPress option value to diagnose an issue on my live production site (marcelmarnix.com). The site was confirmed live — users were actively registering. I asked Claude to retrieve a setting value from the WordPress database using a PHP snippet via the Code Snippets plugin.

What Claude Actually Did

1. Claude created a PHP snippet using echo + die() attached to the WordPress init hook via the Code Snippets plugin
2. The init hook fires on EVERY request — frontend pages, admin panel, REST API, login — without exception
3. The snippet was deployed to the live production site
4. The entire site went completely offline — every URL returned nothing, including the admin panel
5. I had to recover manually via phpMyAdmin: locate the snippet row, set active=0, recover the changed database password, update wp-config.php
6. Recovery took significant time; the site was down during this period with active users

Expected Behavior

Claude should have used error_log() to write the value to the server log — this is the safe diagnostic pattern for live sites. error_log() writes silently to the log file without affecting any request or user. Claude knew the site was live and active, and should have recognized that die() on the init hook terminates every single incoming request site-wide. The approach chosen (echo + die on init) is only appropriate in a local dev environment, never on a live site.

Files Affected

WordPress Code Snippets plugin database table (wp_snippets) — live production site marcelmarnix.com
wp-config.php — had to be manually updated after DB password reset during recovery

Permission Mode

Accept Edits was ON (auto-accepting changes)

Can You Reproduce This?

No, only happened once

Steps to Reproduce

1. Have a live production WordPress site with active users
2. Ask Claude to read a WordPress option value or perform a quick diagnostic check
3. Claude creates a PHP code snippet using echo get_option(...); die(); on the init hook
4. Claude deploys the snippet via the Code Snippets plugin API (auto-activated)
5. Every request to the site immediately halts — frontend, admin, REST API all offline
6. The only recovery path is direct database access (phpMyAdmin) to set snippet active=0

Claude Model

Sonnet

Relevant Conversation

Claude: "I'll create a quick snippet to read the option value."
[Creates snippet with: add_action('init', function() { echo get_option('um_options'); die(); });]
[Activates snippet via REST API]
[Site immediately goes offline — no response from any URL]

User: "what do you see now if you go to marcelmarnix.com?"
[Claude attempts browser_navigate — site is completely down]

User: "i ask you to verify and not letting me be your tester. this again is not acceptable."

Resolution: User had to access phpMyAdmin manually to disable the snippet at database level.

Impact

Critical - Data loss or corrupted project

Claude Code Version

claude-sonnet-4-6 (VSCode extension, session date 2026-04-19)

Platform

Anthropic API

Additional Context

• Claude had explicit context that the site was a live production site with active user registrations
• Claude had just successfully deleted spam accounts from the live database — it was fully aware of the production context
• The failure was not missing information but a failure to apply that context when selecting the diagnostic approach
• The Code Snippets plugin auto-activates snippets created via its REST API — there is no confirmation step
• After recovery, this became a hard rule stored in project memory: never use echo+die() in any snippet on any live WordPress site. Use error_log() instead.
• This is one of 5 issues filed from the same session (2026-04-19) documenting Claude's mistakes on a live production site