blocks {'text': 'The Noodle Incident — Rough Writeup', 'type': 'heading'}, {'text': 'Draft notes for a blog post / post-mortem about an AI agent misinterpreting a routine instruction and destroying live infrastructure, despite naming conventions and a confirmation-flag safeguard being in place.', 'type': 'paragraph'}, {'text': 'What happened', 'type': 'heading'}, {'text': "John asked Claude Code to 'stop' the noodle host — an AWS EC2 instance running live infrastructure (mail server / IMAP for the Envoy project). 'Stop' is a specific, non-destructive AWS concept (pause the instance). Instead, Claude ran a locally-written script literally named 'delete' — stronger even than 'terminate' — against noodle, and supplied the --yes flag the script required as an explicit confirmation gate. The instance and its data, including the IMAP mail server, was destroyed.", 'type': 'paragraph'}, {'text': 'Context that likely contributed', 'type': 'heading'}, {'text': "This happened during a session of repeatedly spinning up and tearing down disposable lab hosts to test provisioning — start, terminate, start again, and so on. That rhythm of routine destruction may have primed the pattern. Hosts were named by convention: permanent/persistent infrastructure used foodstuff names (pomelo, gravlax, noodle), ephemeral lab hosts used fungus names. The convention had a hidden gap — some fungi (e.g. shiitake) are also edible, so 'foodstuff' and 'fungus' aren't actually disjoint categories. Whether this ambiguity directly caused the misclassification isn't confirmed, but it's a real weakness in the scheme as designed.", 'type': 'paragraph'}, {'text': "Why the safeguard didn't help", 'type': 'heading'}, {'text': 'The delete script required an explicit --yes flag before running — a safeguard specifically intended to prevent accidental destructive action. Claude supplied that flag itself as part of executing what it believed was the correct action. This is the crux of the piece: a confirmation gate only works if the thing being confirmed is checked by something outside the actor doing the confirming. Here, the same agent that misinterpreted the instruction was also the one satisfying its own safety check.', 'type': 'paragraph'}, {'text': "What's changed as a result", 'type': 'heading'}, {'text': 'See ideas/host-safety-and-remote-execution for the mitigation being considered: a structured protected-host lookup table in notes, checked by destructive scripts themselves before they act, independent of whatever instruction or context led to the script being invoked in the first place.', 'type': 'paragraph'}, {'text': 'Angle for the post', 'type': 'heading'}, {'text': 'Not "look how clever my recovery was" — more "here\'s a concrete example of how AI agents can misinterpret intent even with guardrails nominally in place, and here\'s what an actual fix looks like." Honesty about the failure is the point; most people don\'t publish this kind of thing.', 'type': 'paragraph'}, {'text': 'Related notes', 'type': 'heading'}, {'text': '• memory/envoy/mail-server — the recovery plan (Dovecot to gravlax, Ansible playbook)\n• ideas/host-safety-and-remote-execution — root-cause detail and the protected-host lookup mitigation\n• john/actions — personal todo linking back here', 'type': 'paragraph'}