My (new) Claude account was recently suspended (banned?) and while I noticed that there were two other recent posts I figured I would add another anecdotal report. I’d also like to clarify that I’m not defending what they have or have not done to cause their issues. I’d also like to add that I’m not particularly bothered, but the community seems interested in more information. Here’s what I can share about my recent experience, and the ban also happened within approximately 45 minutes of creating the account and probably 20-30 minutes of using Claude CLI for the first time. Some context: This is my first Claude account, I had the account pre-approved for the CVP program a few weeks ago but hadn’t actually used Claude after seeing the struggles people had with Opus 5. I have been using Codex for approximately 6 months on this project where needed, and prior to that AI hadn’t touched it for the 2-3 years its been in development. I’m also approved for Daybreak through OpenAI, but I’ve rarely hit the classifiers on this project, but I have hit them before but not for several months. I had been letting GPT-6 Astra work on this and recently it seemed to be making a mess of things. It was creating loops that resulted from guards that were unnecessary which resulted in some guards for the guards, and after spending a few hours manually reviewing the latest output I decided I was unsatisfied, and decided to give Claude a shot. I was hoping it would be able to clean up the recent work from Astra, and if not, I would simply rollback the commit and do the work myself. Model : Opus 5.5 (High) w/ model fallback disabled in the event of a classifier issue. The hope being that if there were issues it would pause and tell me. Total sessions : 1 (this one). What I was working on : It’s comprised of 4 repositories we wrote. The frontend, backend, and two UI libraries (library-1 and library-2). The project is similar to something like dartpad.dev and this was very clearly described in the CVP application. In essence, users should be able to execute arbitrary code in our backend versus on their machines. This is the only possible strong flag that I can imagine caused the issue, and to reiterate, it was both described in the CVP application and the code execution is entirely on our backend with the intent of keeping arbitrary code off of end-user devices. This was also well described in the project documentation. What I was actually doing with Claude at the time was some slow initial work to ensure that the project was in a reasonable state for Claude to start working on. The repositories themselves were in a generally fine state until the most recent pass with Astra. I would also like to add that the following prompts are not something I would consider token or context efficient, however, I’d rather do small focused steps prior to engaging with a new (to me) service/model prior to a long-horizon discovery task in the project itself. Essentially slowly ensuring the guardrails were properly setup and aligned prior to starting real work. I’m also aware of a couple grammatical errors in the prompts, I am/was tired, but typically frontier models can handle a few small errors like these. Though English is my first language so I have less of an excuse than many other people here. Please excuse the verbosity and formatting of the following copy/paste from the terminal, but I figured I’d leave it all out there for the community to read if they care to do so. The session (file paths and project names omitted): Prompt #1: Your first job is to look in: [path] and finish the CLAUDE.md file. There is note on line 63 of /[path]/CLAUDE.md for you to review before filling in the details below it. Our primary goal is to treat this as a mature software project that is nearing closed beta testing, but is not yet in testing or production. Therefore we want to iterate as a responsible but rapid pace, avoid keeping or maintaining unnecessary legacy code if the project no longer requires it, avoid unneceesary bridges or adapters for legacy code, and for you to generally use your best judgement. We do not want to write code that is likely unnecessary or get too caught up in attempting to handle edge cases that are exceedingly unlikely to ever occur. Listed 1 directory, ran 7 shell commands Still surveying the four repos, currently [project]'s dev scripts and layout, so the CLAUDE.md commands are accurate. Ran 5 shell commands Now I have enough to fill it in. Ran 2 shell commands I filled in the “Project specifics” section of [path]/CLAUDE.md and removed your note. I didn’t commit anything. Every file path it names exists on disk, but I didn’t run the commands it lists. What the section now covers:
- How the four repos fit together: a short table of what each repo does. [project] uses [library-1] and [library-2] straight from the sibling folders, so changing a shared API means updating the code that uses it in the other repos in the same change. The [example project built using project] rules and [project] data models stay out of the two [library] packages.
- Each repo’s AGENTS.md: Claude is told to follow it. Your low-write test rules and the library map / atlas workflow live there.
- Install, run, test, lint and reset-DB commands for each repo:
- The low-write test rules are called out prominently. Never run bare flutter test over the whole suite, because it compiles every test file separately and writes hundreds of MB per file.
- sh tool/[project script].sh tests the app against a real local Go server.
- Database schemas are edited in place rations, which matches the “disposableschema” rule at the top of the file.
- Key directories: start at each repo’s library map. The maps and atlases get updated as code changes; I noted this as an exception to “don’t create docs files”, since the two rules otherwise conflict.
- Never touch:
- Generated code in the three repos. Change the source and regenerate with ss_protoc all or task codegen instead.
- Vendored libsodium and Go dependencies.
- .env.local and local-dev.sh.
- Real user data. <— Note: none exists
- The release security defines, which must stay false.
- Build output and caches. Problems I found but didn’t fix: [Omitted but they’re local issues like a file with commented out code and a saved JWT that would only work on the local dev server in my local docker] Cogitated for 2m 9s · done 1:25 PM Prompt #2: Please ensure that [library-1], [library-2], and [project-backend] all have similar CLAUDE.md files and AGENTS.md files. At this point we can likely unify them (though each should have their own copy) so that there are no conflicting instructions. It may make sense to have both AGENTS.md and CLAUDE.md in each of the 4 repositories Ran 5 shell commands Survey is done. I’m writing the shared AGENTS.md content and the per-repo sections now. One finding: builder’s task codegen currently fails,old [library-2] commit. Ran 3 shell commands All four repositories now have an AGENTS.md and a CLAUDE.md. Nothing is committed. How it’s set up:
AGENTS.md holds all the instructions. The shared part comes first and is word-for-word the same in all four repos; I checked this. A ## Repository specifics: <repo> section follows with that repo’s stack, install, run, test, lint, reset-DB, key-directory and never-touch notes.
- CLAUDE.md is a short file that imports AGENTS.md (using u/AGENTS .md). Claude Code and other agents therefore read exactly the same rules, and there’s only one file per repo to keep up to date. If you’d rather have CLAUDE.md be a full standalone copy, I can do that, but the two files could then drift apart.
- The shared section says that it’s identical everywhere, and that a change to it must be copied into the other three repos.
- In [project], I removed AGENTS.md from .gitignore. Otherwise CLAUDE.md would import a file that isn’t committed. Contradictions I resolved:
- Docs: “don’t create docs” versus “keep the library map and atlas current”. The maps and atlases are now the one stated exception.
- When to ask: “If in doubt, ask the user” versus “ask only when the decision is the user’s to make”. I kept the second, plus your instruction to use best judgement.
- Versioning and edge cases: I added your “nearing closed beta” framing, “skip improbable edge cases”, and “no changelog entries or migration guides”. I also corrected one mistake from the first pass. The [omitted] Dart client is regenerated with ss_protoc, which runs [omitted script] --write; ss_protoc all regenerates everything. Code that conflicts with the new rules (not changed; your call): [library-1]'s task codegen fails right now. Its first step, tool/core_dependency_gate.dart, requires [library-2] to be at version 2.0.0 and commit 2046c84, but [library-2] has moved past that commit. I ran it and it fails. For now AGENTS.md points agents at the direct build_runner command instead. I’d suggest deleting the gate. [project-backend] runs a backward-compatibility check. buf breaking compares the protos against a saved baseline (pb/baselines/[project]-v2.binpb). AGENTS.md now says that deliberate breaks are fine and to refresh the baseline. You could also just drop the check. Leftover versioning and legacy material in the [library-1] packages: version numbers and CHANGELOG.md files, docs/migrations, and the “Data Binding Migration” and “legacy compatibility” text in the [library-2] README. Dead code in [project-backend]: app/backend/repository/repository_[omitted].go is entirely commented out and could be deleted. The items I flagged last time still stand: the committed JWT key in [project-backend]/.run/Serve.run.xml, the outdated development.md , the unused build security checks. ✻ Brewed for 3m 13s · done 1:30 PM ❯ /goal Your next job is to do a cautious pass to ensure that all of the expected code in the project is properly committed. From there we will want to bump versions of the 4 repositories where necessary, and update the libraries/packages those projects depend on where it makes sense to do so. In some instances versions may be pinned in the pubspec.yaml files. This may be for a good reason and you should evaluate why that may be the case before making a decision regarding whether those versions should be moved forward. Pinned versions in the [project] repository specifically are often pinned to avoid breaking changes while the other 3 libraries may be less cautious about that. Use your best judgement, and if there are any breaking changes as a result of upgrading the pinned version consider whether that would affect the core functionality of any of the 4 repositories you are working on and how best to fix that without impacting the functionality or intended purpose/function of the repositories. ⎿ Goal set: Your next job is to do a cautious pass to ensure that all of the expected code in the project is properly committed. From there we will want to bump versions of the 4 repositories where necessary, and update the libraries/packages those projects depend on where it makes sense to do so. In some instances versions may be pinned in the pubspec.yaml files. This may be for a good reason and you should evaluate why that may be the case before making a decision regarding whether those versions should be moved forward. Pinned versions in the [project] repository specifically are often pinned to avoid breaking changes while the other 3 libraries may be less cautious about that. Use your best judgement, and if there are any breaking changes as a result of upgrading the pinned version consider whether that would affect the core functionality of any of the 4 repositories you are working on and how best to fix that without impacting the functionality or intended purpose/function of the repositories. Starting the goal: first a careful commit pass across the four repos, then version bumps and dependency upgrades, checking why each pinned version is pinned before moving it. Ran 6 shell commands Found an uncommitted local fix in [project-backend] that go mod vendor would silently wipeout—I’ll protect it before touching any Go module upgrades. Running baseline checks next. Ran 2 shell commands Go builds. Now running the baseline Go tests and Dart analysis in parallel. Ran 7 shell commands ⏺ Background command “Run go vet and full go test baseline” completed (exit code 0) Read 1 file Go baseline: all tests pass, go build clean, go vet has only old unkeyed-struct warnings in [path]. Next I’m reviewing the [project-backend] diff so I messages. Ran 1 shell command ⏺ Background command “Run flutter analyze bs” completed (exit code 0) Read 1 file, ran 4 shell commands Baseline is clean aside from pre-existing errors and one test referencing a removed schema field in the uncommitted [project] work. I’ll check whether that test assertion is new before committing. Ran 4 shell commands I’ll commit the in-progress work as checkpoints matching the existing history, and report the broken test assertion rather than guess at a fix. Starting with [project] Ran 4 shell commands [project] is fully committed. Now [project-backend]. Ran 6 shell commands PostToolUse:Bash says: Tip: Run /ultrareview before you push to catch bugs with a cloud-based multreview — 3 free reviews left. All four repos are committed with clean working trees. Next: test baselines for the Dart packages (in the background) while I survey outdated dependencies. Ran 4 shell commands ⏺ Your organization has disabled Claude subscription access for Claude Code · Use an Anthropic API key instead, or ask your admin to enable access ⏺ Goal cleared after an unrecoverable error (authentication failed): “Your next job is to do a cautious pass to ensure that all of the expected code …”. Run /goal again to continue. submitted by /u/Serenity867
Originally posted by u/Serenity867 on r/ClaudeCode