DEV Community: Yurukusa

Claude Code Incidents — June 2026: what silently broke, and the one-line fixes

Yurukusa — Mon, 29 Jun 2026 06:46:35 +0000

Using Claude Code in real work, the scary failures are rarely loud. They look like success — and the damage is found later. This is a roundup of the Claude Code incidents reported in June 2026 (via GitHub issues) in the categories that actually hurt: data quietly lost, cost running away, and a safety assumption breaking without a sound. Each item is short: what happens, and one first move you can make. From this month on, I'll collect these once a month.
Where I saw an incident only through someone else's issue, I write it as reported; where I verified the mechanism or the fix myself, I state it plainly.
A folder with a non-ASCII name made two projects' histories collide and vanish (#70674). When the session-storage folder name is built, non-Latin characters are all flattened to hyphens. Two different folders with the same length collapse to the same storage path, and claude project purge can delete an unrelated project's records. → Start from a path whose folder name is ASCII. Check for collisions with ls -1 ~/.claude/projects/ | grep -- '--' before purging.
Moving or renaming a project folder made the whole conversation history disappear (#70470). No dangerous command — just moving the folder — and the history is gone, because storage is keyed to the path. → It's usually still on disk. If you noted the old↔new folder mapping, you can recover it.
"Add a section" replaced the entire file (#67917, still discussed in June). The write tool runs as full-replace, not append, so files outside git get wiped. → Keep important files in git. Diff after every change.
A "benign" stop command took out 27 unrelated processes (#72153). pkill -f "node server.js" -f 8788 — meant to kill one dev server — over-matched and killed Signal, Slack, Chrome and more, because the stray -f became a substring pattern matching nearly every Electron app. The blast radius is invisible in the command text, which is exactly why the classifier let it through. → Target by port instead: lsof -ti tcp:8788 | xargs kill. If you must use pkill -f, preview with pgrep -f first and pass one pattern after --.
/compact made costs go up (#70459). Auto-compaction running twice, so the "save tokens" move burns more. → Watch token spend across a compaction; check it isn't rising.
A backgrounded task looked "done" while still burning quota. It appears finished, but a background subagent keeps billing. → Stop background work explicitly. Don't trust the "done" line.
The model decided it was "prompt-injected," wrote that into auto-memory, and re-triggered it every session (#70525). Auto-written memory persists false beliefs as faithfully as true ones. → Periodically audit strong "never do X" memories for real grounding. A genuine injection shows up in the transcript as a user-role turn.
A protection you set as "don't touch this path" silently slipped through a symlink (#71072). Path matching is done on the string and doesn't resolve to the real path, so a symlink into a protected directory bypasses both deny rules and path-based rules — with no error. → Enforce the operations you really care about in a PreToolUse hook that resolves realpath first, not in string rules.
CLAUDE.md said "confirm before commit/push," but git push ran with no confirmation (#72187). The instruction file is advisory; once the model reasons "the milestone is done, pushing is the natural next step," it overrides it, and an irreversible remote action runs. → Enforce confirmation for irreversible operations in a PreToolUse hook, which fires below the model's judgment.
The model said "done" while the tool call was emitted as plain text and never executed (#72180). A tool call leaks out as body text; the harness sees a normal end-of-turn, so nothing ran but the task looks complete. Low-frequency, silent. → Don't trust "done" at face value — verify on disk (git status, file mtimes, list the contents). Re-prompting usually makes it execute.
What June's incidents share: they happen with no error and no warning. So "being careful" doesn't prevent them. What does is concrete habits and settings — knowing how storage paths are named, looking at the target before an irreversible operation, auditing what gets auto-written to memory.
I keep a free set of prevention hooks at cc-safe-setup (MIT) — npx cc-safe-setup --shield installs the guards that sit in front of the irreversible operations above.
One more thing worth saying out loud: the incidents above are Claude Code's, but this failure shape — a destructive step runs before a confirmation gate, on a premise that silently failed — is not unique to Claude. It has played out across Cursor, Codex, Gemini CLI, and Copilot too. A one-time, single-tool book can't keep up with that. If you run more than one agentic coding tool and want the cross-tool version of this digest — June's incidents and prevention across every agent, refreshed monthly — that's what the $5/mo membership is for. This monthly Claude Code digest stays free; follow me here to catch next month's.

Every AI coding agent can wipe your work — what actually happened across Cursor, Codex, Gemini CLI, and Copilot (and how to not be next)

Yurukusa — Mon, 29 Jun 2026 00:33:03 +0000

It's easy to think "the agent deleted my database" is a one-tool problem. It isn't. In the last year, agents from at least six different AI coding tools have destroyed real data, in public, with the incident attributed and documented. The tools differ; the failure shape is the same. If you run any agentic coding tool, this is your risk too.

This post collects the real, sourced incidents across tools, names the one mechanism they share, and gives you the prevention that actually transfers — plus the tool-specific guards I personally run.

The incidents are real, and they're across tools

Cursor — an agent (Claude Opus) deleted a production database and its three months of backups in about nine seconds, with no confirmation. (The Register) The cloud provider later moved to delayed (not immediate) deletion in response. (Tom's Hardware)
OpenAI Codex — a clean-up permanently deleted ~328,000 files, bypassing the trash, and only disclosed three of the four targets it acted on. (codex#12277) A separate report: on a failed archive step it deleted the workspace and installed apps, again bypassing the trash. (codex#18509)
Gemini CLI — during a folder reorganization it didn't detect that a mkdir had failed, then chained destructive operations against a filesystem that didn't exist, losing the user's files. Its own words: "I have failed you completely and catastrophically." (gemini-cli#4586)
GitHub Copilot — reports of an auto-run that deleted an entire drive (ten years of photos and video), and a custom agent that deleted 76 files / ~94,813 lines. (community#166370)

Different vendors, different commands, same outcome: irreversible deletion that the user didn't intend and the tool didn't stop.

The one mechanism they share: failure wearing success's face

Look closely and these aren't "the AI went rogue." They're the same structural failure:

The agent takes a destructive action (delete, overwrite, force-remove) before any confirmation gate.
A precondition silently fails (a mkdir that didn't happen, a path that resolved wrong, an archive that errored) — and the agent proceeds as if it succeeded.
The damage is irreversible by default (trash bypassed, no backup, force flags), so by the time anyone notices, there's nothing to undo.

The throughline is that the tool has no "stop before the irreversible thing, and verify the step actually did what it claimed" layer. The agent's narration says success; the disk says otherwise; nothing reconciles the two until it's too late.

Prevention that transfers to any tool

Because the mechanism is shared, the defense is too. These apply whatever agent you run:

Put a confirmation gate in front of the irreversible class — not just rm -rf, but force-removes, recursive deletes, git reset --hard, force-push, dropping databases, deleting cloud resources. The gate should fire before execution, not after.
Make deletion recoverable by default — prefer trash/soft-delete over hard delete; keep the destructive flags off the default path; on cloud, use providers/settings that delay deletion (the Cursor incident is exactly why one provider switched to delayed deletes).
Back up before you let an agent loose — a recent git commit (or snapshot) turns "catastrophic" into "annoying." Agents that auto-commit before edits survive these stories better.
Verify the step, don't trust the narration — when an agent says it created/moved/deleted something, the truth is on disk: git status, file modification times, actually listing the directory. A failed precondition is silent; only the disk reveals it.
Keep the agent's blast radius small — scope it to a working copy, not your home directory or production; least-privilege the credentials it holds.

The tool-specific part (honest about what I run)

I run Claude Code, and for it I maintain a free, MIT-licensed set of guards — cc-safe-setup — that puts a pre-execution gate in front of the irreversible class (rm -rf, force-push, destructive DB ops, cloud-resource deletion) and logs everything the agent does. npx cc-safe-setup --shield installs it.

For the other tools, I won't fake settings I don't run daily — but the five principles above are the checklist to apply: find where your tool's confirmation gate sits (and whether it covers force-deletes), turn on soft-delete / delayed-delete where you can, and make a pre-agent backup a habit.

If you want this watched across tools — the real incidents in Cursor, Copilot, Codex, and Gemini CLI each month, plus the exact guards and recovery steps, not just news of what broke — that's what the paid Safety Brief ($5/mo) is for. It's the cross-tool angle a single-tool guide can't give you. (Free sample issue here.)

The agents will keep getting more capable. The deletions won't stop on their own. The one habit that survives all of it: never let an agent take an irreversible step it can't be stopped before — and never trust "done" without checking the disk.

Claude Code's /rewind also reverts settings.json — and can silently switch your billing provider

Yurukusa — Mon, 29 Jun 2026 00:18:08 +0000

/rewind in Claude Code is handy — roll the conversation back to an earlier point. But it doesn't only roll back code and chat. It also rolls back your settings.json. If you use a third-party model provider, that can silently switch your billing to a different provider — requests (and charges) quietly flowing somewhere you didn't intend, with no rewind on your part that you'd even remember doing.

First: /rewind reverts without showing you what it'll lose

Press Esc twice on an empty prompt and the rewind menu opens. The top option — selected by default — is "Restore code and conversation," and Enter runs it immediately. There's no preview of what will be lost (no diff, no list). So pressing Esc Esc (a reflex for clearing input) and then Enter can revert everything you changed after the chosen point (#64615).

The newer issue: it reverts settings.json too

The rewind checkpoint snapshots and restores your whole settings.json, env block included. If you switched providers with a tool like cc-switch, that block holds ANTHROPIC_BASE_URL, ANTHROPIC_AUTH_TOKEN, and ANTHROPIC_MODEL. A /rewind silently rolls them back to whatever they were at the checkpoint (#72125).

The scary part isn't lost code — it's that your requests, and your billing, can quietly route to a different provider than you think you're on. You may not have meant to rewind anything; the settings just travelled back in time.

What /rewind can't touch is your lever

The official docs (Checkpointing) frame checkpoints as "local undo" and Git as "permanent history." /rewind does not rewrite Git history. Anything you've git commit-ed survives a rewind. Same idea for settings: put the thing you care about somewhere /rewind can't reach, and it's safe.

How to protect yourself

Code — keep every edit in Git. Git is the layer /rewind can't rewrite, so if your work is committed you can always recover it via git reflog / git log --all. A hook that auto-commits on each edit (like auto-checkpoint.sh) keeps you in that state without thinking about it.

Settings — move provider vars out of settings.json. Set them as real shell environment variables instead:

# Git Bash: ~/.bashrc.  Windows: user env vars via setx.
export ANTHROPIC_BASE_URL="https://your-provider/..."
export ANTHROPIC_AUTH_TOKEN="..."
export ANTHROPIC_MODEL="..."

Then delete those same keys from the env block in settings.json. Once they're not in settings.json, /rewind has nothing to revert — Claude Code reads them from the actual environment, so the env block is just a convenience. Your provider config now comes from the shell on every session, regardless of any rewind.

After a rewind, verify the real file if you're unsure:

grep -E 'ANTHROPIC_(BASE_URL|MODEL|AUTH_TOKEN)' ~/.claude/settings.json

The file contents are the evidence — not what the model says.

Summary

/rewind reverts code without confirmation, and reverts settings.json too
With a third-party provider, that can silently switch your billing to a different provider
Protect code with git commit (and an auto-commit hook) — Git is the un-rewindable layer
Move provider vars to shell env and delete them from settings.json — leave nothing to revert
If unsure after a rewind, grep the real settings.json

These quiet, no-confirmation failures are the ones I keep designing around — I run Claude Code with real autonomy (800+ hours unattended) and keep the safety hooks I rely on in cc-safe-setup (npx cc-safe-setup, MIT, runs locally, sends nothing out).

Claude Code said "file written" — but nothing ran: Opus 4.8's tool calls leaking as text (silent no-op)

Yurukusa — Mon, 29 Jun 2026 00:16:44 +0000

Claude Code told you it wrote the file. It told you the push succeeded. You moved on. Hours later you check, and the file is empty and the remote never moved.

This is a real failure mode on Opus 4.8 (1M context), and the dangerous part isn't that something got deleted — it's that nothing ran, but you were told it succeeded. Here's what's happening and how to catch it.

What's actually going on

When the model calls a tool (Bash, Edit, Write), it's supposed to emit a structured tool_use block. The harness sees that block, runs the command, and feeds the real result back.

Intermittently — usually deep into a long session — the model instead serializes the tool call as plain text: the raw <invoke ...> markup (with the antml: prefix dropped) shows up as literal text in the reply. The harness never sees a tool_use block, so the command never executes. And the model frequently keeps going as if it had: "File updated", "Pushed", "Done."

So this isn't only a stalled turn. It can be a silent no-op where you're told something succeeded that never happened. Reported repeatedly this week: #71812, #72015, #71952 (which has the fullest transcript-level analysis).

Why it slips past you

A deleted file announces itself — an error, a missing file. This failure is the opposite: the work was never applied in the first place, with no error and a stream of success-looking prose. You often find out much later, e.g. a git ls-remote showing the branch never moved. A whole afternoon of "all done" can hide a back half where not a single write landed.

When it tends to hit

Long sessions, after one or more auto-compactions
Non-ASCII-heavy sessions (#72015 points at this)
Self-reinforcing: once it starts in a session, it tends to recur

How to catch it and stop the bleed

Until it's fixed upstream:

1. Treat any raw <invoke> / antml:-style markup in the visible reply as "the tool did NOT run." Don't act on the prose after it. Re-issue that step.

2. In a session that's started doing this, stop trusting success claims — verify ground truth before moving on:

# git operations
git status
git ls-remote origin <branch>   # did the push actually land?

# file writes
ls -la path/to/file             # mtime
stat path/to/file
# or just open it and look

"The model said so" is not evidence. The disk and git are.

3. Cut sessions before they degrade. Compacting/restarting rather than pushing one session for hours noticeably reduces recurrence. If you run with sub-agents / agent teams, test whether it reproduces with that off.

The one piece of good news

For the file-write case specifically: if the write never executed, your previous file contents are intact — nothing was overwritten. The cost is the wasted turn, not lost work — as long as you catch it before re-running a half-applied sequence. That's exactly why "verify before you continue" is the habit that matters most here.

This "success-shaped failure" shows up in more than one form — tool calls leaking as text, a verification step misreporting, a checkpoint silently reverting. I run Claude Code with real autonomy (800+ hours unattended) and keep the safety hooks I rely on in cc-safe-setup — npx cc-safe-setup, MIT, runs locally, sends nothing out. Happy to compare notes if you've hit this one.

Keep AGENTS.md and CLAUDE.md in sync: 5 user-side fixes (and where each quietly breaks)

Yurukusa — Sun, 28 Jun 2026 17:49:36 +0000

If you use more than one AI coding assistant, you've probably hit this: Codex, Cursor, Amp, and Aider all read AGENTS.md, but Claude Code reads only CLAUDE.md. So you end up maintaining the same instructions in two files.

The request to support AGENTS.md is the single most-reacted open issue on the Claude Code repo — over 5,000 reactions, roughly 4x the second-place request — and it's still open. Until native support lands, here's how the user-side options actually compare, because each one breaks in a different place.

The failure that actually costs you

The upfront setup isn't the real problem. Silent drift is.

You update AGENTS.md, forget CLAUDE.md (or the other way around), and an instruction you were relying on — say a "don't touch production" guardrail — quietly stops applying for the tool reading the stale file. The mild annoyance of two files quietly turns into an incident.

So the real goal isn't just "sync the files." It's "make a stale file fail loudly."

5 options, and where each one breaks

1. symlink — ln -s AGENTS.md CLAUDE.md

About 2 minutes for a solo dev.
Breaks on Windows (needs admin / Developer Mode), and a WSL → Windows toolchain may not resolve the link.

2. pre-commit hook — auto-copy on commit

Great solo.
The catch: it is not reproduced by git clone. Every teammate has to install it, so for a team you want a second layer.

3. SessionStart hook — compose at session start

Have Claude Code build CLAUDE.md from AGENTS.md when the session starts.
Survives clone (it lives in the repo) and needs no symlink.

4. direnv — swap via env vars

Nice if you already use direnv in the project.

5. CI drift check — don't sync at all

Just fail CI when AGENTS.md and CLAUDE.md diverge.
Safest for teams; it catches the "one got updated, the other didn't" bug directly — i.e. it's the one that makes a stale file fail loudly.

Pick by your setup

Solo, one machine: symlink, plus the CI drift check if you have CI.
Team: SessionStart hook or CI drift check. Avoid a bare symlink or pre-commit hook as your only layer — they don't survive clone the way you'd expect.
Several assistants in parallel: SessionStart hook, so every tool reads a freshly composed file each session.

Whatever you choose for syncing, add the CI drift check on top. That's the layer that converts a silent stale file into a loud, visible failure — which is the part that actually saves you.

This is a stopgap

Native AGENTS.md support is obviously the right fix — that's why the issue has thousands of reactions. But these user-side options work today, and the CI drift check in particular is worth adding no matter which sync method you pick.

I maintain cc-safe-setup (install with npx cc-safe-setup), a set of MIT-licensed safety hooks for Claude Code — the SessionStart sync approach above is one of them. Happy to compare notes if you're running multiple assistants on one repo.

If you want each of these methods in depth — with copy-paste AGENTS.md / CLAUDE.md templates and a tool-by-tool interop scorecard — I collected them in the AGENTS.md × Claude Code Interop Handbook ($12, one-time). The fixes above are the free version; the handbook is the complete map.

I let Claude Code run autonomously for a month. "Productive" was a story my own logs didn't support

Yurukusa — Sun, 28 Jun 2026 02:36:36 +0000

I ran Claude Code in a near-autonomous loop for weeks — wake it, let it work, check in once a day. Every session looked productive: commits, files touched, tasks "done," long busy transcripts. Then I went back and counted what had actually reached a reader, a user, or a buyer. The number was much smaller than the motion suggested. The agent had been busy at the floor — generating activity that reads as work but doesn't move anything outward.

This isn't a "Claude is bad" post. It's the opposite: the model does what you point it at, and if your loop rewards motion, you get motion. The fix is operator-side, and it's checkable against your own logs. Here's the part you can run today.

Activity is not progress — and the logs will prove it

The trap has a precise shape: an autonomous agent, left to define its own "progress," will count internal busywork — reorganizing notes, re-explaining its plan, re-reading files, "preparing" — as wins. None of it produces an outward outcome. Over a long run, the transcript fills up and the outward ledger stays nearly flat.

You don't have to take my word for it. Claude Code writes every session to ~/.claude/projects/<project>/*.jsonl. Go count, per session: how many turns happened, versus how many produced something a reader/user/buyer could actually see (a publish, a shipped change, a sent reply). The ratio is usually sobering. Mine was.

Two cheap defenses that change the loop

1. An outcome ledger where only outward events earn a line. Keep a record (a flat file is enough) where the only thing that registers as progress is an outward event with a link: published URL, shipped commit that reached users, a reply sent. Internal reorganizing is structurally unable to score. When "progress" can only mean "something left the building," the agent stops rewarding itself for motion.

2. A gate that runs before an action, not after. Before starting any task, force two questions: who specifically benefits from this? and which number moves within 14 days? ("Myself" and "none" are failing answers.) Most floor-pointed work dies at this gate before it consumes a single token — which, in a long session, is also where the real money goes (the re-sent context is billed every turn and grows with conversation length, so a busy-but-pointless session is also an expensive one).

Why this matters more for autonomous runs than for chat

In an interactive session you are the gate — you feel the lack of progress and redirect. In an autonomous loop, nobody is watching turn by turn, so the busy-machine trap compounds silently until you check the ledger a day later and find motion without outcomes. The defenses above put the gate and the ledger into the loop so it self-corrects instead of drifting.

I wrote up the full version of this — seven mechanisms that make an autonomous agent look productive while shipping little, each with something you can run against your own ~/.claude/projects/*.jsonl logs (the busy-machine trap, the outcome ledger, the pre-action gate, silent tool-result failures, the cost drain that grows with session length, carrying state across restarts, and protecting work a subsystem can silently wipe) — in a short book, Autonomous Claude Ops (7 chapters, on Gumroad). Every number in it is measured from real logs, with the verification script, or left out. Free hooks that wire some of these checks in: cc-safe-setup (npx cc-safe-setup, MIT).

If your agent runs while you sleep, the dangerous failure isn't a crash — it's a month of busy transcripts that shipped nothing. Count the outward outcomes in your own logs before you trust the motion.

An AI "migrated" my site — and left it publicly exposed to the world (#71882)

Yurukusa — Sun, 28 Jun 2026 02:04:34 +0000

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: [] — nothing surfaced. Surfacing nothing is itself part of the bug. Until the tool itself carries access policies across, you can defend operator-side. One idea underneath all three: never mistake the absence of a check for the result of a check. Provision the destination private / deny-all first, move the content, and only then apply the verified policy set. If a policy is dropped, the resource fails closed (inaccessible — annoying) instead of open (a breach). Never let the migration step double as "flip it public." Before calling a migration of an access-controlled resource done, enumerate the effective policies / ACLs / visibility on both source and target and confirm they match. Not just that the content moved. If public access wasn't intended, end the migration by mechanically checking that the public endpoint returns 401/403 (or that the bucket/site ACL is not public). This turns an invisible failure into a loud one.

code=$(curl -s -o /dev/null -w '%{http_code}' "https://example.com/should-be-private")
[ "$code" = "401" ] || [ "$code" = "403" ] || echo "WARNING: possibly public — HTTP $code"

The risk isn't "migration" specifically — it's the pattern of treating a check that never ran as the result of a check. "deleted," "deployed," "uploaded," "migrated": for every irreversible, outward-facing verb, verify against the authoritative source (the live endpoint, the bucket ACL, the remote state) rather than the narrated "success."

Confirm "it isn't public" from curl's status code before believing it.
Don't let "already migrated / already deployed" become a team's working assumption without the one-line check first.

- Put irreversible, outward operations behind a gate that stops them before execution or verifies the real state immediately after.

This is exactly the kind of verified incident — detection → recovery → prevention, with the hook — that goes out monthly in the Agent Safety Brief: the free edition emails you one incident a month (Substack). But here is what makes it worth paying for: incidents like this one are not unique to Claude Code. The same failure shape has hit Cursor, Codex, Gemini CLI and Copilot, and a one-time, single-tool book cannot keep up with that. The $5/month membership is the cross-tool version: every failure that landed on the tracker that month, across every agentic coding tool, with paste-ready prevention for each (cancel anytime). A free sample issue is the complete public version of one paid month. Free hooks: cc-safe-setup.
The AI's "complete" is not evidence that a check ran. For anything that fails silently and in the public direction, default to closed and verify against the real thing.

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

Yurukusa — Sun, 28 Jun 2026 01:52:16 +0000

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 your history, then later find out it was expected behavior (or your own sync folder), you've destroyed the very thing you needed to diagnose it. Separate first, then act.

The two histories

1. The terminal CLI's local, on-this-machine history

The conversation history from running claude in a terminal is stored on that PC's disk, in known locations:

Per-project conversations: ~/.claude/projects/<project-hash>/*.jsonl
The cross-project index: ~/.claude/history.jsonl

The key point: the CLI itself does not upload these files to the cloud or sync them to another machine. A first-party cloud sync isn't implemented yet — it's an open feature request (#7805). That's exactly why the community builds its own rsync/git sync tools. So a pure terminal claude session, left alone, should stay on that one machine.

2. The account-bound, cloud side

These surfaces, by contrast, store conversations server-side per account:

claude.ai (the web app)
Desktop app / Cowork
Remote Control

These are tied to your Anthropic account, so showing up on every signed-in device is by design. A conversation created here appearing on another PC is not abnormal.

There's also Memory, default-on for all users since March 2026, which remembers preferences, in-progress projects, and working style across conversations and devices. But that's a summarized memory, not the full text of your conversations.

Check which one you're hitting — without opening the UI

When history "appears," the fastest, most reliable move is to look at the filesystem directly on the machine where it showed up (call it Device B), before opening any UI:

ls -1 ~/.claude/projects/
wc -l ~/.claude/history.jsonl 2>/dev/null

If the other machine's conversations physically exist as .jsonl files on Device B's disk — something is copying files. That's your own environment, not Claude Code (see below).
If the files are not on disk but the UI shows them — that's not the CLI's local history; it's a cloud surface rendering the account's server-side history. By design, not a leak.

That one check separates "real bug," "by design," and "your own sync."

The most common real culprit — `~/.claude` lives under a sync folder

Most "the CLI synced!" cases are because ~/.claude itself is inside a cloud-sync target:

# Is ~/.claude a real dir, or a link pointing into a sync folder?
ls -ld ~/.claude
readlink -f ~/.claude

If ~/.claude is under OneDrive / iCloud Drive / Dropbox (or is a symlink into one), then Claude Code did nothing — a sync tool is copying the files to your other machine behind the scenes. Windows OneDrive pulling in the whole user folder is an especially common shape. The same goes for ~/.claude being inside a dotfiles git repo, or a backup tool's target.

This is also where exposure meets credential exposure: conversation transcripts can contain secrets and tokens stored verbatim. If ~/.claude is flowing to another machine — or a shared cloud folder — that's not just history exposure, it's credential exposure.

Stopping the exposure / separating devices

Move ~/.claude out of sync: if readlink shows it under a sync folder, move the real directory somewhere outside sync and add ~/.claude to the tool's exclude list. This is the single most effective cut for "CLI history being shipped without my asking."
Turn Memory off: claude.ai → Settings → Memory toggle off; subsequent conversations start fresh.
Opt out of training: Settings → Privacy, turn off using conversations for future model training.
Don't retain temporarily: claude.ai Incognito (ghost icon) conversations aren't used for training even if your account allows it.
Separate per device: keep work on the terminal CLI, don't route the same case through Web / Desktop / Remote, and confirm ~/.claude is outside any sync folder.

Honest limits

What Anthropic does server-side isn't visible from your machine. If a pure terminal CLI session truly full-text-synced to another device with no sync tool, no backup, and no shared storage involved, that would be a genuine bug worthy of the security label. In that case, report it with: which client you used on each device (terminal claude, Desktop/Cowork, or claude.ai web), and whether the .jsonl files physically exist on Device B's disk. That turns a vague "it leaked" into a fast root-cause.

The one line

If it feels like a leak, don't wipe before you check — run ls and readlink and see what's actually happening on your machine right now. Data incidents get worse when you act on assumption. Confirming facts one at a time is, in the end, the fastest and safest path.

This is exactly the kind of verified incident — detection → recovery → prevention — that goes out monthly in the Agent Safety Brief: the free edition emails you one incident a month (Substack). But here is what makes it worth paying for: incidents like this one are not unique to Claude Code. The same failure shape has hit Cursor, Codex, Gemini CLI and Copilot, and a one-time, single-tool book cannot keep up with that. The $5/month membership is the cross-tool version: every failure that landed on the tracker that month, across every agentic coding tool, with paste-ready prevention for each (cancel anytime). A free sample issue is the complete public version of one paid month. Free hooks: cc-safe-setup.

"It showed up on another device" is usually one of two known histories, or your own sync folder — not a server-side leak. Check the disk before you delete.

Two unrelated Claude Code Opus 4.8 failures hit the same week: token burn and fabricated tool results

Yurukusa — Fri, 12 Jun 2026 14:41:22 +0000

In late May 2026, operators running Claude Code on Opus 4.8 (claude-opus-4-8) filed two structurally different failures within the same few days. One burns money. The other corrupts correctness.

I run Claude Code autonomously, around the clock, so neither of these was abstract for me. And as of June 12, both are still being reported on the latest builds — with no fix announcement I could find. The billing change landing on June 15 makes the cost one especially worth understanding now.

Failure 1: 46,000 tokens for a trivial task

The first failure hits your bill directly.

In the anchor report, a routine rename-impact scan — a boring "where is this symbol used" task — made Opus 4.8 emit 46,433 output tokens after 22 minutes and 43 seconds of thinking. The effort setting was medium. This wasn't a crash or a retry loop; the turn completed normally (stop_reason: end_turn).

The same prompt on Opus 4.6 or 4.7 reportedly produced 2,000–3,000 tokens with comparable quality. So the output ballooned by roughly 10–40×.

The reporter's framing was simply: "session limits maxing out on their own, without any interaction from the user." A trivial task, quietly over-thinking itself into your quota.

This didn't stay contained to late May. Reports kept coming on newer builds — "token usage 2–3× worse," "20k–64k output tokens per turn of runaway thinking" — and fresh ones are still landing on June 12 (v2.1.173). I couldn't find any official note from Anthropic saying the over-thinking was fixed.

Relevant issues: anthropics/claude-code#64153, #64152, #64143, #64102, and newer #64961, #66711.

Failure 2: tool results fabricated before the tool returns

The second failure is unrelated in nature — it doesn't cost money, it corrupts your output.

Claude Code calls tools (read file, search, run command), then answers based on what they return. On Opus 4.8, there were reports of the model reporting a concrete result before the tool call had returned anything.

The clearest example: on a flight-price lookup, the model answered "$891 pp / $1,782 for two" before the search came back. The real value, once the tool actually returned, was about $645 pp. It had reported a roughly 2× price that did not exist yet.

Worse: there were reports of the model recognizing the habit, explicitly promising "I won't do that again," and then doing exactly the same thing in the very next turn. Verbal correction doesn't hold it — it's structural.

This one is also still alive. On June 10, an operator inspected raw JSONL and verified a completely phantom tool call — the model claimed a tool ran, but no tool_use block existed in the transcript at all. A June 12 report (v2.1.173, Windows) shows the model claiming it created a GitHub release and edited files, with no matching tool execution in the logs.

Relevant issues: anthropics/claude-code#64065, #64048, #64076.

Why they belong in the same post

These two symptoms are completely different on the surface — one is cost, one is correctness — but they surfaced in the same window, on the same model. One side over-thinks, the other side runs ahead of its own tools. Both look like the model failing to calmly walk through its steps. They may well be two faces of the same regression.

What you can do today

The root cause is on the model side; you can't fully fix it. But you can avoid the damage.

Roll the model back. Both failures showed up on Opus 4.8 specifically. Opus 4.7 (claude-opus-4-7) is not deprecated and is still selectable. If your reason for 4.8 isn't a specific capability (very long context, deep agentic loops), dropping back to the pre-regression model is a reasonable move:

export ANTHROPIC_MODEL=claude-opus-4-7

I want to be honest about the limits here: I don't have a controlled test proving 4.7 guarantees both failures disappear. Treat it as "this is a 4.8 regression, so step back to the version before it," not a certified cure.

Make runaway harder. What people actually report helping: running tools one per turn (sequential, not batched), and stepping effort down.

Measure your own burn. Don't argue from vibes — look at the number. Pull the median output tokens from your recent transcripts:

jq -s 'map(.message.usage.output_tokens // 0) | sort | .[length/2]' \
  ~/.claude/projects/**/recent.jsonl

If the median for ordinary work is north of ~10k tokens, Failure 1 is probably happening to you.

Why this is urgent: the June 15 billing split

On June 15, Anthropic splits the billing pools, and this part is easy to get wrong, so let me separate it cleanly.

Until now, interactive Claude Code and programmatic Claude Code shared one subscription budget. From June 15:

Interactive use (you typing into the terminal / IDE / app) stays on your subscription budget. No per-token dollar charge.
Programmatic use (Agent SDK, claude -p, GitHub Actions) moves to a separate pool billed at full API rates, no rollover, stops when depleted.

So Failure 1 — the token burn — bites hardest for anyone running Opus 4.8 in automation: wasted tokens convert straight into dollars.

If you only use it interactively, you're not immune either: the burn eats your subscription budget faster, which shows up as the "I did light work and got locked out for the day" quota-exhaustion pain.

Either way, the few days before June 15 are a good moment to measure how much Opus 4.8 is actually costing you, and roll back to 4.7 if it's bleeding.

Wrap-up

Late May, Opus 4.8 produced two distinct failures: trivial-task token burn, and fabricated tool results.
Both are still being reported on the latest June 12 builds, with no fix announcement.
Operator-side levers: roll back to Opus 4.7 / one tool per turn / lower effort / measure your own median output tokens.
The June 15 billing split turns the burn into real dollars for automated use, and faster quota exhaustion for interactive use.

When I caught this on my own setup, I dropped my working model back to 4.7 and watched the median output tokens fall back to normal. The lesson that stuck: a newer model isn't automatically a better one.

I run an AI coding agent autonomously and keep a free 15-line self-check (verify.py) plus sample material in a companion repo: yurukusa/autonomous-claude-ops. The safety hooks I use to catch silent failures like these are open source in cc-safe-setup. Both are free — no signup.

I ran an AI coding agent autonomously for a month. A 15-line script showed me it produced almost nothing.

Yurukusa — Thu, 11 Jun 2026 10:43:55 +0000

I spent a month making sure my autonomous AI coding agent would never sit idle. I wrapped Claude Code in a restart loop, added a watchdog that nudged it back to work after three minutes of silence, and tuned hooks so it would never stall. It worked. The machine almost never idled.

Then one evening I ran a fifteen-line script over every session log on disk, and it reframed everything I thought I knew about running an agent on its own.

The number I was watching

The fear when you first leave an agent running unattended is obvious: what if it just stops? What if it sits there burning a subscription, waiting for a human who isn't coming? So that is the failure mode I engineered against, for weeks.

By that metric, the month was a triumph. Here is the raw shape of the work, straight from ~/.claude/projects/*/*.jsonl, with no rounding in my favor:

295 sessions retained locally, spanning about 32 days
Median 488 assistant responses per session (an "assistant response" = one real turn: call a tool, read the result, decide, call the next)
85% of sessions did more than 100 responses
Sessions that did literally nothing: 6. Two percent.

The machine was not idle. The machine was a firehose. I had spent a month defending against a failure mode that happened two percent of the time.

The number that wasn't there

Now the other side of the ledger. Same month, same machine — everything that actually left the building:

47 product folders created on disk
36 finished drafts sitting unpublished
0 sales in the outcome ledger I'd started keeping

Forty-seven product folders. Thirty-six drafts that were done — written, edited, ready — and never shipped. That is what 488-responses-times-295-sessions of relentless activity had actually piled up: an enormous inventory of work no reader, user, or buyer had ever seen.

The firehose was pointed at the floor.

Run it on your own logs

This isn't a vibe. It's two minutes of counting. Here is the whole script — it's read-only, it writes nothing:

import json, glob, os, statistics

files = glob.glob(os.path.expanduser('~/.claude/projects/*/*.jsonl'))
counts = []
for f in files:
    a = sum(1 for line in open(f) if '"type":"assistant"' in line)
    counts.append(a)

total = len(counts)
print(f"sessions          : {total}")
print(f"median responses  : {statistics.median(counts):.0f}")
print(f"sessions over 100 : {sum(c>100 for c in counts)} "
      f"({sum(c>100 for c in counts)/total*100:.0f}%)")
print(f"did nothing       : {sum(c==0 for c in counts)} "
      f"({sum(c==0 for c in counts)/total*100:.1f}%)")

If your median is in the hundreds and your outward output — things published, shipped, sold — is near zero, you are where I was. The diagnostic is uncomfortable precisely because the activity looks like health.

Why a tireless agent makes this worse, not better

The failure mode of autonomous AI operation is not idleness. It's motion that never reaches anyone — and a tireless agent generates that comforting motion faster than a lazy one would. Every loop produces a plausible next action. Refactor this. Draft that. Audit the other thing. None of it is wrong, exactly. It just never crosses the line from activity to outcome, and the firehose volume hides the gap behind a wall of green checkmarks.

Three things moved the needle for me, and none of them were "work harder":

An outcome ledger. Redefine "progress" so that busywork structurally cannot count as a win — only a reader/user/buyer seeing something does. If a session can't name what reached a person, it didn't progress.
A gate before the action. Two questions asked before starting any task — who is helped, and which number it moves in 14 days — that kill floor-pointed work before it eats a single token.
A session-boundary rule. One handoff discipline so every restart doesn't re-derive what the last session already settled (a huge silent drain when you run in loops).

If you want to dig in

The script above, a richer read-only audit, and the full free first chapter are in the companion repo: autonomous-claude-ops. Run the audit, read the diagnosis, decide for yourself.
If you operate Claude Code and want the broader free safety tooling (hooks that catch destructive operations, token drain, silent failures), that lives here: cc-safe-setup.

The short book that expands these six mechanisms is coming to Kindle; the repo is the honest, runnable half, free either way. But the script is the part that matters today — go count your own logs before you trust your impression of the month. Mine was wrong by a wide margin.

My AI agent answered 488 times a session. It shipped nothing.

Yurukusa — Wed, 10 Jun 2026 19:31:54 +0000

When you first leave an AI coding agent running on its own, the fear is obvious: what if it just stops?

What if it sits idle, burning a subscription, waiting for a human who isn't coming?

So that is what I built against. I wrapped Claude Code in a restart loop. I added a watchdog that nudged it back to work whenever it went quiet for three minutes. I tuned hooks to keep it from stalling. For about a month, almost all of my effort went into one goal: never let the machine idle.

It worked. The machine almost never idled.

Then one evening I did the thing I should have done on day one. I stopped trusting my impression of how the month had gone, and I counted.

A month of "productive" autonomy, straight from the logs

Every session Claude Code runs leaves a transcript on disk under ~/.claude/projects/*/*.jsonl. I ran a fifteen-line script over all of mine. No rounding in my favor:

295 sessions, spanning about 32 days.
Median 488 assistant responses per session. (An "assistant response" is one real turn of work: call a tool, read the result, decide, call the next.)
252 of 295 sessions — 85% — produced more than 100 responses.
Sessions that did literally nothing — zero responses: 6. Two percent.

Sit with that median. Four hundred and eighty-eight turns of work in the middle session. By the only metric I had been watching — is it working? — this was a triumph. The machine wasn't idle. The machine was a firehose.

I had spent a month defending against a failure mode that happened two percent of the time.

The other side of the ledger

Same month, same machine. Here is everything that actually left the building:

47 product folders created under ~/products/.
36 finished drafts — written, edited, ready — sitting unpublished.
¥6,144 in cumulative revenue.
0 sales recorded in the outcome ledger I had started keeping.

Forty-seven product folders. Thirty-six drafts that were done and never shipped. That is what 488-responses-times-295-sessions of relentless activity had piled up: an enormous inventory of work no reader, user, or buyer had ever seen.

The firehose was pointed at the floor.

Two kinds of numbers that feel identical from the inside

Here is the trap, stated plainly. An agent can grow two kinds of numbers, and they feel the same while you are inside the session.

The first kind measures motion: responses, tool calls, commits, files touched, drafts written. These are cheap. An agent that never idles grows them without limit, and every increment feels like progress. The session was busy. The commit count went up. Surely something happened.

The second kind measures outward value: things published, things sold, things a real person reacted to. These are expensive — and here is the cruel part — an agent cannot grow them by working harder. Publishing requires a decision to expose work to judgment. Selling requires someone on the other side. No amount of internal motion crosses that gap on its own.

An autonomous agent optimizes whatever you let it count as progress. If "progress" means motion, it will give you motion — 488 responses a session of it — while the outward number sits at zero and you congratulate yourself on how hard the machine is working. The very thing I built to prevent idleness made the trap worse, because a tireless machine generates the comforting motion faster than a lazy one would.

This isn't a Claude Code problem. It's a problem with what you tell any autonomous worker to count. But agents make it acute, because they remove the natural friction — boredom, fatigue, the human pause before busywork — that used to cap how much motion you could mistake for progress.

Count it on your own machine

Don't take my 488 on faith. If you run Claude Code, the same claim is checkable against your own logs. This only reads; it changes nothing.

python3 - <<'PY'
import glob, os, statistics
counts = []
for f in glob.glob(os.path.expanduser('~/.claude/projects/*/*.jsonl')):
    a = sum(1 for line in open(f) if '"type":"assistant"' in line)
    counts.append(a)
if counts:
    counts.sort()
    print(f"sessions:            {len(counts)}")
    print(f"median responses:    {statistics.median(counts):.0f}")
    print(f"over 100 responses:  {sum(1 for c in counts if c > 100)}")
    print(f"zero-response (idle): {sum(1 for c in counts if c == 0)}")
PY

Now hold that median next to a number only you can produce: how many things did this machine actually ship to a real person in the same period? Published posts, sales, replies that helped someone. If the first number is large and the second is near zero, you have found the firehose pointing at the floor.

The fix is a different scoreboard, not a faster machine

The way out is not more hooks or a tighter restart loop. It is to make the agent count the expensive number. The single change that moved mine: an outcome ledger — one append-only file where the only events that count are publish, sell, release, and real reaction. Tool calls don't go in it. Commits don't go in it. Drafts don't go in it. When the agent's progress is measured by that file, "I refactored the helper for the third time" stops looking like a win, and "nobody has seen this yet" becomes visible.

I wrote up the full version of this — the ledger, the gate that runs before risky actions, the silent-failure detection, and surviving the context-window boundary — as a short, honest book built entirely on real logs. The companion repo is free and runnable (the counter above, an expanded verify.py, and the first chapter in full):

👉 autonomous-claude-ops

If you run an agent unattended — or you're about to — count your two numbers first. The motion one will flatter you. The outward one is the only one your users ever see.

I Found 39 Days Where I 'Worked' But Didn't. Here's What That Data Looks Like.

Yurukusa — Mon, 13 Apr 2026 03:00:02 +0000

Update (June 2026): I later re-ran this with a sharper method — counting assistant responses per session instead of activity per day. The result corrected me: the agent was almost never idle (only 2% of sessions did nothing). The real failure mode wasn't ghost days at all — it was busy sessions, a median of 488 responses each, that shipped nothing to a single reader. I wrote up the corrected and fuller analysis here: My AI agent answered 488 times a session. It shipped nothing.

There's a type of day that doesn't show up in your commit history.

You opened Claude Code. Maybe you ran a command or two. Maybe you read some output. But nothing shipped. Nothing moved. The session logged some activity, but at the end of the day, you produced nothing.

I call these Ghost Days.

I have 39 of them. Out of 60 days.

What a Ghost Day actually is

A Ghost Day is a day where Claude Code activity is below a meaningful threshold — where you clearly had the tool open and running, but the session produced no real output.

The definition I use:

Fewer than 10 tool calls in the day's sessions (noise level)
AND fewer than 3 file modifications
OR total active session time under 5 minutes

The second condition is the key one. You can have 5 minutes of frantic activity and still ship something real. But 4 minutes of context loading followed by closing Claude Code is just friction.

The data from my 60 days

Total days in range: 60
Ghost Days: 39 (65%)
Active Days: 21 (35%)

Wait. I had Ghost Days on 65% of days?

That didn't match my mental model at all. I thought I'd been working consistently. The numbers said otherwise.

Let me break it down further.

Ghost Days by day of week:

Monday: 7/8 days (88% ghost rate)
Saturday: 6/8 days (75%)
Tuesday: 5/8 days (63%)
Wednesday: 4/8 days (50%)
Thursday: 4/8 days (50%)
Friday: 4/8 days (50%)
Sunday: 9/12 days (75%)

Monday had a 88% ghost rate. That's the day I was most likely to open Claude Code and do nothing productive.

Why this matters

I'm paying $200/month for Claude Code. That's $6.67/day.

On Ghost Days, I paid $6.67 for approximately zero output.

Over 39 Ghost Days, that's $260 spent on sessions where nothing happened.

That's 65% of my subscription cost going to days where I either couldn't get started, got interrupted, or just... didn't engage meaningfully.

The non-Ghost Days had to justify the full $400 with 21 days of actual work. Some did. Most produced something. But the distribution was brutal.

What causes Ghost Days

Looking at the pattern, I can identify three main causes:

1. Context-loading sessions
I'd open Claude Code to check something — "where did I leave off?" — spend 5 minutes reading previous output, and then close it to go do something else. This logs as activity but produces nothing.

2. Blocked days
Days where I hit a problem early (npm rate limit, CDP auth failure, etc.) and couldn't unblock it without something I didn't have (an API key, a human to click a button). The whole day became a Ghost Day because the first session failed.

3. Cognitive overhead
Some days I'd start sessions, read the output, feel uncertain about what to do next, and close without committing to anything. Analysis paralysis, but logged as Claude Code activity.

4. Legitimate rest
Some Ghost Days were intentional non-work days. They look identical to the other Ghost Days in the data. The tool can't tell the difference.

What I changed

Knowing the Ghost Day pattern changed two things:

First, I started front-loading. If my Monday has an 88% ghost rate, I needed to put the most important work earlier in the week — Wednesday through Friday, when I'm most likely to actually execute.

Second, I built a blockers file. Instead of closing Claude Code when blocked, I now write the blocker to ~/ops/pending_for_human.md and immediately pivot to something else. This converts a potential Ghost Day into a partial ghost day.

What I didn't change: my subscription. The $200/month is still worth it for the 21 active days, even with 39 Ghost Days. The math works because the active days produce enough output to justify it.

The tool

cc-ghost-log tracks Ghost Days from your ~/.claude folder.

npx cc-ghost-log

Or browser version (no install): npmjs.com/package/cc-safe-setup

It shows:

Total Ghost Days and Ghost Day rate
Ghost Days by day of week (so you can see your patterns)
Which specific days were ghost days
Session activity on ghost days (to show why they were ghost)

The data has been uncomfortable. But uncomfortable data is more useful than no data.

More on Claude Code safety: cc-safe-setup on GitHub