Ask HN: Banned From Claude Code

Ask HN: Anthropic banned me from using Claude Code and I don’t know what to do is a June 2026 Hacker News post from a developer who says Anthropic blocked their personal account for Claude Code, Anthropic’s coding agent, after VPN and payment-card signals. The problem is not just one lost account; it is what happens when a coding workflow depends on a service whose risk systems can say no without a detailed appeal path. The takeaway is simple: keep Claude Code useful, but keep your project habits portable, especially around review, MCP access, and tool boundaries.

Claude Code MCP is the way Claude Code connects to external tools through Model Context Protocol servers. A safe answer to adding a Claude Code MCP server is to start with one narrow, local, read-only server, prove it helps on a throwaway task, then widen access only when the boundary is clear.

Read the ban story as a support-system failure

The post was short and familiar in the way developer horror stories often are. The author said they had used Claude Code at work for months, then tried a personal subscription for side projects. They suspected a VPN triggered the first ban after about an hour, received a refund, waited a month, signed up again without the VPN, and was banned again, possibly because the same card was reused.

What made the thread flare was the support response. The author said the reply cited a usage-policy violation but did not say what behavior caused it. Their examples sounded ordinary: summarizing markdown, asking about refactors, and doing normal code assistance.

That gap is where the debate lived. One side read the post as a false positive from fraud or abuse detection. The other side pointed out that platforms have to defend themselves against account farming, sanctions risk, payment fraud, and automated abuse, and that they often cannot reveal detection details without making the system easier to bypass.

Both sides can be true. A vendor can have a rational risk system and still leave a legitimate developer stranded.

The trap is treating this as only a customer-support anecdote. For Claude Code users, the larger engineering question is whether your repo can keep moving when an identity, billing, or network signal breaks access to one agent.

Take the fallback argument seriously

Several commenters suggested switching to another coding assistant, using a model router, or paying for tokens through another provider. That was not just brand rivalry. It was a practical answer to a brittle dependency.

The strongest version of that argument is this: coding agents are now part of the development environment, not a novelty tab. If your editor, shell, test runner, or package registry disappeared for a week, you would want a backup path. The same logic applies to Claude Code.

The strongest version of the counterargument is also fair. Switching tools can lose workflow details. Claude Code conventions, slash commands, hooks, MCP servers, and project memory are not automatically portable. A developer who has tuned prompts, review habits, and repo-specific instructions may not get the same result elsewhere on day one.

So the useful move is not panic-switching. It is separating durable project practice from product-specific convenience.

Keep your important conventions in repo artifacts where a human can read them. A short CLAUDE.md can describe architecture boundaries and test commands, but avoid turning it into a diary of every preference. A review checklist in the repository is even better because any assistant, or any teammate, can follow it.

For readers comparing Claude Code conventions across real teams, the broader team conventions topic is a good place to connect this debate to day-to-day repo practice.

Add MCP only when it reduces blast radius

MCP came up in the wider Claude Code world because it is how developers connect agents to GitHub, docs, databases, issue trackers, and internal systems. That power cuts both ways. A Claude Code MCP server can make a workflow smoother, but it also creates a sharper permission question: what can the agent see, and what can it change?

The practical version of how to add mcp server to claude code is boring on purpose: add one server, use the smallest scope, log what it can touch, and test it against a task that has no production consequence.

Here is a concrete example. Suppose your repo has architecture decision records in docs/adr/, and you want Claude Code to answer questions from those files while refactoring a payment module. Do not start by connecting the agent to every document store and ticket system. Start with a local docs server that can read only the ADR folder.

The permission note can live next to the server script:

MCP server: repo-adr
Purpose: let Claude Code read architecture decisions during refactors
Transport: local stdio
Allowed paths: docs/adr only
Write access: none
Network access: none
Owner: devtools
Remove if: unused for two weeks

Then run a small command workflow:

# Example shape. Use the exact Claude Code MCP command form from your installed version.
claude mcp add repo-adr -- node tools/mcp/repo-adr-server.js --root docs/adr --read-only
claude mcp list
claude 'Use repo-adr to summarize the decision behind ADR-014. Do not inspect application source.'

The important part is not the exact server name. It is the boundary. The server has one job, one data root, and no write path.

The trap is using MCP as a workaround for account or access anxiety. If you are worried about losing access to a coding agent, adding more privileged integrations is the wrong instinct. First make the existing workflow easier to audit and easier to replace.

For a related MCP infrastructure story, see Manufact (YC S25) Ships MCP Cloud.

Copy this small experiment

Use this when the argument in your team turns into vibes: one person says Claude Code is too risky to rely on, another says the productivity is worth it, and nobody has evidence from your repo.

Run the experiment on one low-risk issue. Pick a docs update, a failing unit test, or a small refactor with good test coverage. Do not use a production incident, auth code, billing code, or private customer data.

End with a handoff receipt, not a meeting. Keep it small enough that someone will actually write it:

Task: fix flaky parser test in packages/importer
Agent used: Claude Code
External access: repo-adr MCP, read-only docs/adr
Commands run: pnpm test importer -- --runInBand
Human checks: reviewed diff, reran failing test 10 times
Fallback notes: test command and parser invariant are in repo docs
Decision: keep Claude Code for this class of task; no broader MCP access needed

This settles the useful part of the debate locally. It does not prove which vendor has the best model. It tells you whether your own workflow has enough evidence, enough review, and enough portability.

The limitation is obvious: one experiment will not predict every outage, ban, or policy edge case. But it will reveal whether your process lives in the repo or only in a chat transcript.

Common questions

• Is how to add mcp server to claude code the right question after an account ban?

  Yes, but only if the server reduces risk instead of expanding it. Start with a local, read-only Claude Code MCP server for one folder or one knowledge source. Record the owner, allowed paths, and removal condition before connecting anything that can write, call production systems, or read private customer data.

• Should I stop using Claude Code because one developer was banned?

  No, one Hacker News post is not enough evidence to abandon a useful tool. It is enough evidence to test your fallback path. Pick one low-risk task and prove that your review checklist, test commands, and repo notes still work if Claude Code is unavailable for a day.

• Can a VPN really trigger a Claude account problem?

  It can be one signal, but outsiders cannot know what triggered this specific case. Fraud and abuse systems often combine network, billing, device, and behavior signals. The practical move is to avoid unusual sign-up patterns when possible and keep receipts: account email, payment status, support ticket, and timestamps.

• What should go in CLAUDE.md after this debate?

  Put durable repo rules in CLAUDE.md, not account drama or tool-specific panic. Good entries include test commands, architectural boundaries, generated-file warnings, and review expectations. Keep it short enough that Claude Code and humans can follow it, and keep fallback instructions in normal repo docs when they matter outside Claude.

• Are Claude Code MCP servers portable to other tools?

  Sometimes, because MCP is an open protocol, but the surrounding workflow may not be portable. Server capabilities, approval prompts, config locations, and tool UX can differ. Treat the MCP server contract as portable infrastructure, and treat Claude Code commands, hooks, and prompts as product-specific glue.

Best ways to use this research

• Best for: Claude Code users who want the speed of an agent without making one account the only path through a repo.
• Best first artifact: A one-page handoff receipt that lists the task, external access, commands run, human checks, and fallback notes.
• Best comparison angle: Compare workflows by portability, not just model output. Ask what survives when Claude Code is unavailable halfway through a task.
• Best MCP boundary: One read-only server, one purpose, one data root, one owner, and one removal condition.

Further reading

• Anthropic — Claude Code product page
• Claude Code — getting started
• Model Context Protocol — specification

Next step

Pick one low-risk issue and run the experiment above before adding more integrations. If the workflow cannot survive a missing agent, fix the repo artifacts first.

One methodology lens

One useful way to read this through our methodology is the Plan step: delegate first-pass decomposition and dependency mapping, review the sequencing and assumptions, and keep ownership of scope and priorities. If that split is still fuzzy, the workflow usually is too.