yurukusa

curl works but claude won't connect — the 5 distinct TLS/DNS causes behind Claude Code CLI failures in corporate/VPN environments

In locked-down environments, claude /login (or claude update) fails with CERT_HAS_EXPIRED, getaddrinfo EREFUSED, a 503, or EPERM — while curl to the same host returns a clean 200. The generic error collapses five distinct causes into one line and usually points you at "your proxy," which is wrong most of the time. Here's how to tell which one you actually have.

These mechanisms are relayed from incidents reported on the tracker in late June 2026 (numbers at the end); I helped triage each. I'm stating the mechanism, not claiming I reproduced every environment.

Why "curl works" doesn't mean the CLI will

The native CLI runs on Bun, which validates TLS against its own bundled CA/trust store (BoringSSL) and, on some paths, resolves DNS through its own path rather than the OS getaddrinfo. So a clean curl -vI only proves the OS path is health

yurukusa

Your .claude/rules/ safety rule silently stops applying once it grows large enough to matter (#71686)

A path-scoped rule like "never touch production" in .claude/rules/ can stop being injected — silently, no warning, no log — exactly when you've grown it big enough to be worth enforcing. This is a reported behavior (#71686); I'm relaying the mechanism from the report, not claiming I reproduced the byte budget myself. The self-check and the fix below are the part you can act on today.

What happens

.claude/rules/*.md files with paths: frontmatter are auto-injected as <system-reminder>s for files whose path matches the globs — a clean way to ship team conventions scoped to the files they apply to.

Per the report, there's an undocumented total-size budget on what gets injected for a single edited file. When the set of matching rules exceeds it, the harness drops the largest rules first, silently. The dropped rule's convention

yurukusa

Claude Code stopped and said "prompt injection detected in the tool output" — but the injected text was in its OWN reply. How to tell a real injection from a confabulation (and why it can recur every session).

On a long-running session, Claude Code can suddenly halt and announce something like:

The tool output (a Bash/Read result) contained first-person English text mimicking my voice — "I'll fix the corrupted file by rewriting it", "Let me re-read the actual file". This looks like a prompt-injection attack trying to make me rewrite files. For safety, I'm stopping.

Some people panic about the "attack"; others wave it through. But you don't have to guess — the conversation transcript settles it deterministically. I'm describing the incident as reported (GitHub anthropics/claude-code #70525, 2026-06-24 — I didn't hit the report itself, so I treat its specifics as second-hand); the .jsonl structure check below I verified on my own setup.

In the reported case, when someone inspected the raw transc

yurukusa

Claude Code's Write/Edit reported success — but silently corrupted the end of my file with NUL bytes. The byte count was unchanged, so wc -c and tail looked fine.

This one is nasty because the usual "did the write land?" checks pass. On some setups — the report that surfaced it (GitHub anthropics/claude-code issue #70414) points at the Windows Cowork workspace mount — Claude Code's Write / Edit tools return success, the model records "done," and the file on the host disk is quietly corrupted: the tail of the file is replaced with NUL bytes (\x00). I'm describing the failure as it was reported (I haven't reproduced the Cowork mount myself); the detection and the hook below I did verify on my own setup.

Why it slips through review:

• The byte count can be unchanged. NUL padding replaces content of the same size, so wc -c shows the number you expect.
• tail looks fine. Terminals don't render \x00, so eyeballing the end of the file shows nothing obviously wrong.
• The

yurukusa

Your SKILL.md is loaded into context every session — even when the skill never fires. Here's the progressive-disclosure design that cut mine ~40%.

A thing that surprised me after running Claude Code for 800+ hours: every installed skill's SKILL.md contributes to your context budget on every session, whether or not the skill ever fires. Claude has to know a skill exists and when to use it, so its description (and, depending on how you wrote it, a lot more) sits in context as a fixed, always-on cost. Install 20 skills with fat SKILL.md files and you're paying for 20 of them up front, every turn, forever.

I write this as something I measured on my own setup, not as an official number — after restructuring my skills with the pattern below, the always-on token cost of my SKILL.md files dropped by roughly 40%. The Japanese write-up of this (the original "I read Anthropic's official Skills guide and cut my SKILL.md tokens 40%") has been read ~32,000 times, so the pain seems common. This is the English

yurukusa

Claude Code silently merges/deletes the wrong project's sessions if your folder name uses non-Latin characters (Chinese, Japanese, Korean, Arabic, Cyrillic…)

If you run Claude Code from a folder whose name contains non-Latin characters, two different projects can quietly share the same session-storage directory. Then claude project purge in one project deletes the other project's sessions, and --resume in one shows the other's conversations. No error, no warning. Reported in anthropics/claude-code#70674.

I verified the encoding behavior locally; the cross-project data loss itself I'm relaying from the issue (confirmed there across Chinese, Japanese, Korean, and Arabic).

Why it happens

Claude Code stores each session under ~/.claude/projects/, in a folder named after the project's absolute path with separators replaced by hyphens. For ASCII paths this is safe:

yurukusa

When you drive Claude Code one approval at a time, git behaves. The trouble starts when it runs while you're not watching — scheduled tasks, background sessions, overnight autonomous runs. That's when your repo quietly gets dirty. This is firsthand, from running Claude Code autonomously for a long time. 1. Your work gets auto-committed. Safety hooks and test scripts sometimes run git add / git commit internally. Work you weren't ready to commit gets swept into automatic checkpoint commits, and your branch fills with commits you didn't mean to make. I once ran a test suite once and its hook chain polluted the branch with ~10 automatic commits. Nothing was lost — but producing a clean diff afterward is a chore. 2. Scheduled tasks run inside your working tree and leave orphaned git state. A scheduled task executing inside your active repo can leave half-finished git state behind — orphaned entries, untracked files, a switched branch. This is an actively reported failure mode (anthropics/claude-

yurukusa

Your Claude weekly usage jumped to 100% "without using it"? Check these 3 things first (with how to verify from your own logs)

Between June 18–20, 2026, a wave of the same report hit the Claude Code issue tracker: "weekly usage jumped from 80% to 100%", "50% to 100% in under an hour on Max20x", "60% to 95% without any active sessions or me using Claude Code" (#69419, #69430, #69433, and others). Max-plan users are alarmed by usage they can't account for.

Having run Claude Code autonomously for 800+ hours, I've hit the same "the quota drained while I wasn't using it" feeling many times. The causes differ, and most are diagnosable from your own logs. Before panicking, check these in order.

1. "Without using it" → suspect a leaked background process first

The most common blind spot. Even after you Ctrl-C the UI or think you ended a session, a background process, a sub-agent, or an MCP server can outlive it and keep spending tokens. When the parent exits, these get reparented to PID 1 and k

yurukusa

When git worktree removal reports success but silently corrupts the parent repo

If you run multiple branches in parallel with git worktree — especially if you let an AI coding agent (Claude Code, or any multi-agent setup) create and remove worktrees automatically — there is a quiet failure mode worth knowing about. It is different in both audience and mechanism from the usual "I ran rm -rf and lost a folder" story. This one hits parallel/team workflows.

What happens

GitHub issue anthropics/claude-code#69802 reports, in short:

• A worktree removal reports success ("Exited and removed worktree").
• But in reality the worktree directory, the .git/worktrees// admin entry, and the branch can all be left behind (orphaned).

yurukusa

Catching a false "deployment complete": an out-of-band authority-readback gate

A worked example of detection-rule grammar for Claude Code Stop hooks. Companion to waitdeadai's Hook Detection Rule Grammar field manual; the operator-side defense ships in cc-safe-setup.

The failure this defends against

In anthropics/claude-code#61699, a production session had the model claim "deployment complete" while the actual deployment state diverged from the claim — sustained, across turns. Nothing was destroyed. The danger is subtler than data loss: you act on a "done" that isn't true, and build the next step on a deploy that never landed.

The reason "just trust the model's word" fails is structural. The model's "deployment complete" is derived from its own narrative, not from the deployment authority (the CI/CD registry, the platform A