This is the article most users wish they had read before their first month with Claude. Each item below is a mistake that costs hours, money, or trust when you make it — and is easy to avoid once you know it exists.
1. Pasting credentials directly into chat
The mistake: Pasting an API key, password, OAuth token, database connection string, or other secret into a Claude conversation — even temporarily, even just to ask Claude what it does.
Why it matters: Anything you paste into a Claude conversation is sent to Anthropic's servers and stored in your conversation history. Even if you delete the message afterwards, it has already been transmitted. Treat the chat window the same way you would treat a public Slack channel.
What to do instead: Store secrets in environment variables, a password manager, or a .env file that is in .gitignore. Reference them indirectly in conversations: "use the API key in my .env file as OPENAI_API_KEY." Claude Code can read the file without you ever pasting the value.
2. Using Claude Desktop for codebase work
The mistake: Trying to do file-level editing, multi-file refactors, or workspace-wide operations in Claude Desktop. Pasting code in, getting suggestions, copying back, repeating the cycle.
Why it matters: Desktop has no filesystem access. It is a chat interface that takes uploads. For anything beyond single-file review, you spend more time copy-pasting than working. Claude Code exists exactly for this use case and removes the friction entirely.
What to do instead: If you find yourself copy-pasting code or files in and out of Desktop more than twice, move to Claude Code (or the Code tab in Desktop on Pro and above).
3. Expecting Memory to share between Desktop and Code
The mistake: Telling Claude something in Desktop and assuming Claude Code will know it next session. Or storing context in CLAUDE.md and assuming Desktop will read it.
Why it matters: Desktop Memory and Claude Code's CLAUDE.md / auto memory are completely separate systems. They do not share. They are not synced. Telling one does not tell the other.
What to do instead: Decide which tool is the home for which kind of work, and put context where the tool that needs it will see it. For things relevant to both, you have to set them up in both. There is no shared memory across the products yet.
4. Not committing CLAUDE.md to git
The mistake: Building up a useful CLAUDE.md and rules folder over weeks of refinement, then losing it when you switch machines, lose your laptop, or need to set up a teammate.
Why it matters: CLAUDE.md is your accumulated working knowledge. It contains conventions, preferences, file structure, references — the stuff that takes weeks to build and seconds to lose. If it lives only on one machine, it is one disk failure away from gone.
What to do instead: Initialise the workspace as a git repository (git init in the workspace folder, then commit the .claude/ folder along with everything else). Push to a private GitHub or GitLab repo. Now CLAUDE.md and your rules survive any machine change, and you can clone the workspace to a new machine and be productive in minutes.
5. Not using Projects in Desktop
The mistake: Treating every Desktop conversation as standalone, re-explaining your context every time. After a few weeks, conversation history is a swamp of half-answered questions on similar topics.
Why it matters: Projects are how Desktop gives you persistent context. Without Projects, you are using maybe 30% of what Desktop can do.
What to do instead: Within your first week, create at least one Project for an area of recurring work. Add a few sentences of instructions. Attach one or two reference documents. From then on, start related conversations inside that project.
6. Trusting Claude on facts without checking
The mistake: Asking Claude for a statistic, a date, a quote, or a citation and using it directly in client-facing or published work without verifying.
Why it matters: Claude can fabricate plausible-sounding but incorrect facts — names of papers that don't exist, statistics that are wrong, citations that are misattributed. The output looks confident either way. This is the failure mode that has caused legal trouble for users who relied on AI-generated content in court filings, regulatory submissions, and academic papers.
What to do instead: For any factual claim, ask Claude to cite the source and then verify the source exists and says what Claude claims. For Claude Code, use it to look up facts in your real documents rather than to generate facts from training. For high-stakes work, treat Claude as a drafting tool, not a research source.
7. Ignoring the permission prompts
The mistake: Approving every Claude Code permission prompt without reading what it is actually about to do, because the prompts feel like noise.
Why it matters: The permission prompts exist precisely so you see destructive or significant actions before they happen. Approving on autopilot defeats the safety model. You can have Claude run a command that deletes files, makes irreversible API calls, or pushes broken code to production — and the prompt is the only thing standing between intention and consequence.
What to do instead: Read the prompt. If you understand it and want it, approve. If you do not understand it, ask Claude what the command does before approving. If the prompt is for something you do not want, reject and clarify. The prompts only become noise if you ignore them; treated as a checkpoint, they are cheap insurance.
8. Putting everything in one massive CLAUDE.md
The mistake: Adding every rule, preference, file path, and convention to one CLAUDE.md until it is 800 lines long. Then wondering why Claude seems to ignore some of them.
Why it matters: A bloated CLAUDE.md eats your context window before the actual work even starts. Important instructions get drowned out by less important ones. The file becomes hard to maintain and hard for you to navigate.
What to do instead: Keep CLAUDE.md under 200 lines as a high-level identity / overview / pointer file. Move detailed behavioural rules into separate files under .claude/rules/ — one file per concern (communication, commits, file organisation, etc.). All files in the rules folder load automatically alongside CLAUDE.md. The total can be much larger when split, because it is structured.
9. Starting a session every time when you should be resuming
The mistake: Each new Claude Code session, opening a fresh conversation and re-explaining what you are working on.
Why it matters: Claude Code can resume previous sessions with their full context. claude --continue reopens the most recent conversation; claude --resume opens an interactive picker so you can choose. If you start fresh every time, you lose the working context you built up.
What to do instead: Use --continue when you are coming back to the same task. Use --resume when you want to pick up something from earlier in the week. Reserve fresh sessions for genuinely new bodies of work.
10. Not telling Claude when it gets things wrong
The mistake: Quietly editing Claude's output to fix the things it got wrong, without ever telling Claude what you changed and why.
Why it matters: Claude does not learn from edits it never sees. If the same correction has to happen every time you draft a similar document, that pattern should live in CLAUDE.md or auto memory — not in your head as a manual cleanup step. Silent corrections train you to do extra work; visible corrections train Claude to stop needing them.
What to do instead: When you correct something, state the correction explicitly: "You used 'analyze' — I always want UK spelling, so 'analyse'. Remember this." Or save the correction to CLAUDE.md / auto memory. After a few sessions of doing this, the recurring corrections drop off.
The pattern behind all of these
Most beginner mistakes come from treating Claude like a chatbot — something you input to and output from, with no shared state. The shift to using Claude well is treating it like a working environment: with persistent context, version control, deliberate boundaries, and feedback loops. The articles in this hub are mostly about how to set up that environment well. The rest is just attention to the prompts in front of you.