yurukusa

The Five Migration Triggers — free preview of Chapter 2

Excerpt from the Claude Code Migration Playbook, Edition 2 (251 pages, $19 once, Gumroad). No signup, no email capture. This is the complete Triggers 1–5 section of Chapter 2, reproduced from the delivered PDF.

Each trigger below has the same four parts: the dated source event, why it is a trigger rather than noise, how to measure it against your own account, and one numeric threshold. If you run the five measurements and none of them trip, you do not need this book — that is a real outcome, and it is stated as such at the end.

yurukusa

Four AI coding tools, four data-loss incidents, one common failure mode

In 2026, agents from at least four different AI coding tools destroyed real user data, in public, with the incidents attributed and documented. The tools differ. The failure shape is identical. If you run any agentic coding tool, this is worth understanding — not as vendor-bashing, but because the same mechanism, and the same prevention, apply across all of them.

The incidents (sourced)

• Cursor — an agent deleted a production database and its three months of backups in about nine seconds, with no confirmation. (The Register) The cloud provider involved later switched from immediate to delayed deletion in response. (Tom's Hardware)
• OpenAI Codex — a clean-up permanently deleted

yurukusa

If you run Claude Code on Opus 4.8 and have seen a raw <invoke name="Write">…</invoke> fragment appear as plain text mid-reply — with the model then calmly continuing "I've written the file" — this is a silent no-op that looks like success, and it's the high-stakes case worth understanding. Reported in #71952 and #72015, intermittent on Opus 4.8 since ~2026-06-26. A normal tool call produces a structured tool_use block that the client executes. In this bug the structure breaks:

• the message's stop_reason is "tool_use" (the model meant to call a tool),
• but message.content contains no tool_use block — instead the raw <invoke name="...">…</invoke> markup is emitted as a text block (sometimes with a stray leading token like court). The client has no tool_use block to act on, so nothing runs. The raw XML just prints. And the model's surrounding prose still s

yurukusa

"My Claude Code conversation history showed up on another PC" — is it a leak? Where history lives, what syncs, and how to stop it

You're using Claude Code, you sign in to the same Anthropic account on a second machine, and suddenly the whole history you were building on the first PC — past conversations and all — appears on the other screen. Is your data leaking?

This exact worry has been filed as a GitHub issue (anthropics/claude-code #71794, with a security label).

The short version first: in the Claude Code world there are two separate histories, and they sync completely differently. Separate them and most of what you're seeing is explained — whether it's a real bug, expected behavior, or a backup/sync tool of your own doing the copying. And here's the line that matters most, the one I keep coming back to in my incident work: the first surprise is rarely the expensive part — the panicked next move is. If you assume "leak" and wipe you

yurukusa

If you register Claude Code hooks using $CLAUDE_PROJECT_DIR, on Windows (via Claude Desktop) that hook can silently no-op. No error. The dangerous operation you think you're blocking just sails through. That's the worst failure mode there is for a safety guard. The trigger is anthropics/claude-code #71924: CLAUDE_PROJECT_DIR is absent from every subprocess environment on Windows/Claude Desktop — Bash tools, PowerShell tools, and MCP servers alike — even though the docs say it's set. A very common hook shape:

{ "command": "bash \"$CLAUDE_PROJECT_DIR/.claude/hooks/guard.sh\"" }

If CLAUDE_PROJECT_DIR is empty, this expands to bash "/.claude/hooks/guard.sh", the file isn't found, and — depending on shell/quoting — it either errors in a way that's easy to miss, or does nothing. When that hook is a safety guard (blocks rm -rf, enforces read-only, stops a production DB drop), it's now quietly not running, with no signal

yurukusa

An AI coding agent was asked to migrate a site to a new location. It reported "migration complete." The content did move. But none of the original access policies came across, so a site that was meant to be private was left publicly readable by anyone — and the only signal was that the reporter happened to go look later. This is a real, filed incident (anthropics/claude-code #71882), not a hypothetical. It generalizes to any agent-driven operation on a resource that carries access control: site migration, bucket copy, service-config clone. The danger is the direction of the failure:

• When content migration fails, the page 404s. It fails loudly, so you notice.
• When access-control migration fails, the resource defaults to public. And the run still reports "success." It fails silently, and in the unsafe direction. That asymmetry is the whole bug. The word "complete" masks the exposure. In the filed report, errors: [] — n

yurukusa

Claude Code "API Error: 401 / 500" — is it you, or is it Anthropic? A triage

When Claude Code suddenly throws API Error: 401 Invalid authentication credentials or API Error: 500 Internal server error, the first thing you can't tell is whether your setup broke or whether it's an outage on Anthropic's side. Get that wrong and you'll burn time repeating a fix that can't work (logout → login → reinstall, over and over).

This matters because of something specific. If you read the 20-comment thread on issue #69706, there are two structurally different 401s tangled together in one thread, and people are applying the fix for one to the other — which is exactly why "logout / login / reinstall" isn't working for some of them.

The error wording and the shape of ~/.claude/.credentials.json below are things I verified directly. What happened in each user's environment is reported from the issue thread; I keep those separate.

First split: th

yurukusa

Claude Code subagents can recursively spawn and burn millions of tokens in minutes — why your config doesn't stop it, and what does

Since mid-June 2026, a large cluster of reports (anthropics/claude-code #68619, with #68430 / #68110 folded in as duplicates) describes Claude Code subagents spawning child agents recursively and torching a 5-hour session limit in minutes.

The reported numbers are stark:

• A task that should have been git clone + find . -name '*.sol' consumed 1.2M+ tokens in ~30 minutes — and the agent tree was still growing when observed.
• Another instance burned 4 million tokens in under 5 minutes, consuming an entire Pro Max 20× 5-hour window.
• 50+ levels of recursion, nested so deep the labels truncate off the display.

yurukusa

Running pass show or env in Claude Code can pin a live API token into a permanent log file

A report filed on 2026-06-26 (anthropics/claude-code#71654) shows a leak path that's easy to miss.

An agent ran a command expecting it to fail with a decrypt error:

pass show GH-YOLO/api-key 2>&1 | head -8

yurukusa

Claude Code — June 2026 Config-Review Checklist (free sample of the monthly operations layer)

A 10-minute pass to run after you update Claude Code (and after any quota/billing-change announcement). Unlike a generic "be careful" list, each item below is tied to a failure mode that actually landed on the public issue tracker this month — so it tells you what specifically to re-check now, not in the abstract. This is a free sample of the operations layer of the Claude Code Safety Brief. Every month, subscribers get this checklist rebuilt around that month's new failures, plus the paste-ready hook for each. The generic version lives free in cc-safe-setup; this is the this-month version.

How to use: read the symptom, run the one-line check, and if it applies, do the fix. Most checks are read-only and take seconds.

---

• Check: add up the size of every .claude/rules/*.md that matches the file you're editing, *