You do not need to become a developer to get useful work out of this. The tool is genuinely good at the kind of tasks in this guide, and the setup is straightforward. Your first month is about three things: starting in the right folder, understanding what Claude is asking to do, and building habits that let you verify everything yourself. Confidence comes from recoverability — and that is easy to set up.
The people who get comfortable with Claude Code fastest are not the ones who trust it most. They are the people who create the calmest environment for clear results to show up.
CLAUDE.md files, Auto mode, PowerShell preview tuning, elaborate permission rule sets, and anything that starts with "just use bypassPermissions." You will not need any of that in the first weeks. What you need is folder control, permission judgment, and visible proof — the rest can wait. 14PowerShell is a good starting terminal on Windows, and WSL is optional. The one thing you do need upfront is Git for Windows. Native Windows Claude uses Git Bash internally, even when you launch from PowerShell. If a blog or forum post says Git is optional, the official docs disagree — trust the official docs. 124
Start in a clean local folder on a normal local drive — one you made for practice, with no real secrets in it. Session transcripts under ~/.claude are plaintext, so if Claude reads a .env file or you print a secret, it can end up there. 1 Starting in a clean practice folder means you never have to worry about that.
Keep things local at first. Official security guidance warns against broadly allowing UNC paths like \\* or enabling WebDAV, because local-looking file access can become remote network access. A simple local folder avoids all of that. 1
Launching Claude from PowerShell does not mean Claude is using PowerShell as its command backend. On native Windows it still uses Git Bash by default. 1
"Permissions" are also worth understanding properly. They are not the same as hard containment. Deny rules for Read or Edit, and even denying WebFetch, do not constrain what Bash can do. The real OS-level boundary is sandboxing, and on Windows that is limited: WSL2 supports it, but the PowerShell preview does not. 1 You do not need to worry about this yet — default mode with a clean folder is a comfortable starting point.
One billing note worth checking now: if ANTHROPIC_API_KEY is set in your environment, Claude Code bills to the API instead of your Max subscription. If you are on a Max plan, make sure this variable is unset. You can check with /usage. 1
You know the exact folder Claude is working in, you know that folder contains no real secrets, and Claude starts there without Git Bash errors.
Good news: read-only tools such as Read, Grep, and Glob work without any approval at all. You can explore freely. Tools that change things or reach outward — Bash, Edit, Write, PowerShell, WebFetch, WebSearch — ask permission first. 1
Learn /permissions early. It shows the effective rules and where they came from. Rules are evaluated in the order deny > ask > allow, with the first match winning. 1
On Windows, path form matters. Prefer forward slashes when you talk to Claude, and note that permission rules use POSIX-normalized Windows paths like //c/Users/Andy/Project, not raw C:\Users\Andy\Project. 13
The two "make it faster" approvals are not equal.
For Bash, "Yes, don't ask again" becomes a persistent per-project, per-command rule that can outlive the current session. For file edits, the "allow all edits" style approval is session-only. 1
This means persistent Bash rules deserve more thought than session-only edit allowances. That is the main thing to keep in mind.
Do not memorize exact button labels. The briefings say official docs define the semantics, but current wording varies across CLI, Desktop, and bug reports. Trust the behavior, not the exact phrase. 34
You might accidentally create a persistent Bash allowance for a command you do not fully understand. Or a Windows path normalization difference might mean a rule does not match what you expected. Both are fixable — /permissions will show you what is actually in effect.
For Bash prompts, ask Claude to explain the exact command in plain English before you approve it.
Use approve once by default.
If edit prompts are getting repetitive, a session-only edit allowance is a comfortable next step — much lower commitment than a persistent Bash rule.
If Claude wants to touch .git, .vscode, .idea, .husky, or most of .claude, pause and think. Those are protected paths for a reason. 12
You can explain the difference between one-time approval, session-only edit allowance, and persistent Bash approval without guessing.
Do one small task that produces a visible result. Good early wins: a new Markdown file, a cleaned template, an index file, or a renamed copy of a small folder. Choose work where success is something you can open and look at, not something hidden in logs or system state.
Use plan-first behavior. Ask for a plan first, ask which files Claude wants to touch, and approve the smallest next step. The briefings flag a conflict about whether Plan mode can execute commands, but you do not need to depend on exact mode semantics — just ask for a plan and approve step by step. 4
Also know that Claude's Bash is not a persistent shell session. Each command runs in a separate process, and environment variables do not persist across commands. 1
One successful task does not mean Claude now "understands your setup." Starting in a folder does not mean Claude can only read that folder. Write scope is narrow by default, but read scope is broader than many beginners assume. 1
You cannot find a file Claude created. Claude asks to read .env or print a secret. You approve a change to a protected path because the filename looked harmless. All of these are recoverable — just pause.
Ask Claude to state the exact output path before it creates anything.
Ask it to list the files it plans to edit and why.
Approve one small step, then open the result and judge it yourself.
If it asks to read .env, echo environment variables, or touch protected paths, just say no and reassess.
You can complete one visible task, find the output without hunting across your drive, and explain exactly what changed.
Now you build repeatability — and you have a few useful tools for that.
/clear resets the conversation completely. Claude forgets everything discussed, but file changes stay. Use it when you are confused or switching tasks. /compact compresses a long conversation to stay within context limits without losing it entirely. Use it when a long session starts feeling sluggish. 1
Expect some Windows rough edges. Community reports describe Git Bash detection glitches, repeated prompts, path normalization hiccups, and CRLF edit failures. The official changelog shows Windows and permission fixes were still landing in late March and early April 2026. If something feels flaky, it may well be a known issue — not your mistake. 23
CRLF (Windows line endings) can still break edits or shell scripts. The briefings show active fixes but do not claim the issue is fully resolved. 23
The permission model is worth understanding properly: denying Read, Edit, or WebFetch does not stop Bash from reading files or using network tools. Sandboxing is the real perimeter, and on Windows that means WSL2 Bash only — not the PowerShell preview. 1
/permissions is not an advanced command. It is how you inspect why prompts are behaving the way they are.
The PowerShell tool is not a maturity upgrade yet. It is preview-only, with no sandboxing, no $PROFILE, no Auto mode, and Git Bash still required. Treat it as optional and limited. 12
Permission prompts keep reappearing. Path rules do not match because of normalization differences. Edits fail because of CRLF. Git Bash is installed but not detected. On some Windows setups, credential persistence is unreliable — community reports say OAuth tokens may not persist in Git Bash/MSYS, and the VS Code extension may sign out on reopen. 3
Most of these have straightforward fixes — see the troubleshooting table below.
Keep one project per folder.
Work on copies, not originals.
Prefer forward-slash paths consistently.
Use /permissions when behavior feels irrational.
Only create persistent Bash "don't ask again" rules for harmless, repetitive commands you fully understand inside one project.
You can recover from a path or prompt problem without widening permissions blindly, and you can finish two or three small projects with visible outputs and clean checkpoints.
This is where you become operationally independent. That does not mean removing guardrails. It means choosing work that is local, reversible, and easy to judge with your own eyes — and doing it with less friction.
Once you can reliably review changes, acceptEdits is a natural next step. It auto-approves file edits and a limited set of filesystem commands inside the working directory or added directories, while other commands still prompt. 12
acceptEdits readiness checklist — switch when you can say yes to all of these:There is no rush. Default mode is perfectly productive.
Do not graduate to bypassPermissions. Official docs say bypassPermissions / --dangerously-skip-permissions should be used only in isolated VMs, containers, or devcontainers without internet access. 1
bypassPermissions is not a convenience feature. If you are on your normal Windows machine with normal internet access, it is the wrong tool. 1
More autonomy is not the same as more independence. Real independence is being able to keep the scope small, prove results, and stop when the task outgrows your understanding.
Mass renames on original files, work across UNC/WebDAV paths, automation over real credentials, or trust in hidden system state you cannot verify — these are signs to pause and scope down.
Keep each automation in its own local folder.
Use copies for anything destructive.
Require a visible proof step before every checkpoint.
Keep the blast radius small: one folder, one result, one review, one checkpoint.
You can start with a blank folder, ask for a map and a plan, approve only what you understand, verify the result, and either checkpoint or roll back without outside rescue.
WebFetch and you've blocked networking." Ignore this. Bash can still use network tools like curl or wget. 1Read or Edit on .env and secrets are fenced off." Ignore this. Bash can still read files. Sandboxing is the real boundary. 1bypassPermissions is just a faster beginner mode." Ignore this. Official docs say isolated VM/container only. 1| Step | What to ask Claude | Why it matters |
|---|---|---|
| Map | "Map this folder. Tell me what it is, what files matter, and what looks risky. No changes." | Prevents wrong-folder mistakes and surfaces sensitive files early. |
| Plan | "Plan only. List the exact files you want to touch, the output path, and the smallest next step. Wait." | Lowers false confidence and keeps scope visible. |
| Change | "Make only the smallest change needed for a visible result. Stop if you need Bash or a protected path." | Keeps the blast radius small. |
| Prove | "Show me exactly what changed and how I can verify it with my own eyes." | Forces evidence instead of vibes. |
| Commit/ | "Is this ready for a checkpoint, or should we roll back and try smaller?" | Creates a clean stopping point and protects you from drift. |
Use this loop even if you are not relying on explicit Plan mode, because the briefings say official docs currently conflict on the exact command-execution behavior of that mode. 4
Why first: mostly reading, one new output file, easy to judge.
Success: one human-readable file listing the folder contents with short descriptions.
Use a clean folder to create or improve a few reusable text files: meeting note, follow-up email, checklist, proposal stub.
Why second: still visible, still low risk, but now Claude is editing multiple files you can inspect.
Success: a few files you can open and judge without technical tools.
First ask for a rename plan and a before/after manifest. Then do it only on a copy.
Why third: it teaches path discipline, permissions, and verification without touching originals.
Success: filenames visibly improved, plus a manifest you can review.
.env files, API keys, or auth tokens.| Problem | Likely cause | Do this |
|---|---|---|
| Git Bash not found | Git for Windows missing, not on PATH, or detection issue | Follow official Windows guidance: install Git for Windows, restart the terminal/app, and use CLAUDE_CODE_GIT_BASH_PATH if the official troubleshooting says to. Ignore community claims that Git is optional. 134 |
| Permission prompts keep reappearing | Session-only edit allowance expired, Bash rule did not match exact command/path, or recent bug | Run /permissions. Check the normalized path and command. Remember: Bash "don't ask again" is persistent per project/per command; "allow all edits" is session-only. If it still looks wrong, suspect a bug rather than widening permissions. 123 |
| Claude seems confused | Too much scope, hidden state, or Bash state not persisting | Use /clear to reset the conversation. Restate the current folder, the desired output, and the smallest next step. Ask for map-only or plan-only. Shrink to one file or one visible output. 1 |
| Session feels slow or degraded | Long conversation exceeding context limits | Use /compact to compress the conversation without losing it, or close the terminal and start fresh. 1 |
| You can't find the created file | Wrong working folder or unclear path form | Ask Claude for the exact output path in forward-slash form before and after the change. Do not mix C:\, C:/, and //c/. 13 |
| Bad Windows paths | Git Bash/Windows normalization mismatch | Prefer forward slashes in prompts. For permission rules, use POSIX-normalized paths like //c/Users/.... 1 |
| CRLF edit failure | Windows line endings | Suspect CRLF if edits fail oddly or scripts break. The briefings say CRLF issues still show up in community reports and do not claim they are fully resolved. 23 |
Running claude opens Desktop instead of CLI |
Older Desktop install shadowing the CLI | The official troubleshooting documents this Windows shadowing problem. Follow that path rather than assuming the CLI itself is broken. 1 |
| Claude keeps asking me to sign in | Credential persistence unreliable on Windows | Community reports say OAuth tokens may not persist in Git Bash/MSYS, and VS Code extension may sign out on reopen. No official fix identified as of Apr. 2026. 3 |
| Charges API instead of subscription | ANTHROPIC_API_KEY is set in environment |
Unset the variable. Claude Code bills to the API key when one is present, bypassing Max subscription usage. 1 |
At first, the terminal feels unfamiliar.
Then permission prompts feel like friction.
Then you start to wonder if Claude is getting things right.
Usually the real issue is smaller and more fixable than it feels: wrong folder, vague task, invisible success criteria, or a trust decision that happened too quickly. All of these have simple resets.
A week or two in, the work gets calmer. You stop asking for magic and start asking for maps, plans, and proof. That is when the tool starts feeling genuinely useful.
The most important moment to stay careful is the first day you feel fast. That is when people start skipping the habits that were quietly protecting them. If you notice yourself skipping the work loop, that is a sign to slow down, not speed up.
Real confidence feels boring: you know where the files are, which prompts to decline, and when to reset smaller. That boring feeling is the goal.
This section is experience/opinion, not sourced fact.
acceptEdits later; never bypassPermissions on a normal connected machine. 1.env files are not beginner practice material.Stop when you cannot answer all four of these:
Also stop when Claude wants Bash you cannot explain, wants to touch .env or protected paths, or when you feel tempted to use bypassPermissions just to get unstuck.
The reset is simple and always available: make a fresh copy, narrow the task to one folder and one visible output, go back to the work loop, and approve less. You can always start smaller, and starting smaller always works.