Claude Code on Windows: Installation, Plan Mode, Permissions and GitHub Actions Safety Guide

This piece walks through a workflow that holds up against Anthropic's documentation, with Windows specifics. It also flags several claims in the popular "Claude Code workflow" explainers that don't survive scrutiny.

What you need on Windows​

Anthropic's current setup documentation says Claude Code runs natively on Windows or inside WSL. Hardware requirements are 4 GB or more of RAM and an x64 or ARM64 processor, plus an internet connection. Shells supported include PowerShell and CMD.

Key setup points:

• Install: The recommended route is the native installer, run from PowerShell or CMD. Administrator rights aren't required. WinGet works too, using winget install Anthropic.ClaudeCode.
• Git for Windows: It's recommended on native Windows so Claude Code can use Git Bash for its Bash tool. Without it, Claude Code falls back to PowerShell as the shell tool. WSL setups don't need it.
• Verify: Open a new terminal and run claude --version. A working install prints a version number. If the shell can't find claude, the install directory isn't on your PATH yet.
• Diagnose: claude doctor prints read-only diagnostics on install health and settings-file errors without starting a session.
• Updates: Native installs update themselves in the background. WinGet and Homebrew installs need manual upgrades by default, using winget upgrade Anthropic.ClaudeCode on Windows.
• Account: You need a Pro, Max, Team, Enterprise or Console account. The free claude.ai plan doesn't include Claude Code. Third-party providers, including Microsoft Foundry, are also supported.

Older guides still say to run npm install -g @anthropic-ai/claude-code and require Node.js. Current documentation lists the native installer as the recommended path, so check which instructions you're following.

The five-step workflow, with safeguards​

1. Give it context and a goal​

Start Claude Code in the project directory. State the goal, the constraints, the reproduction steps and the acceptance criteria. For unfamiliar code, ask for an explanation of the relevant flow before asking for edits. This is a sensible practice, not a guarantee. The tool can still miss files or misread undocumented behavior.

2. Plan before editing​

Plan mode is the most useful safety control for risky work. Start it with claude --permission-mode plan. Anthropic's permissions documentation describes it this way: Claude reads files and runs read-only shell commands to explore but doesn't edit your source files. In plan mode, a permission "mod" can't approve a call that isn't read-only, such as a file edit or a shell command that writes.

You can also make it the project default. Merge a permissions.defaultMode value of plan into .claude/settings.json to start terminal sessions in plan mode.

Two details are easy to miss:

• Approving a plan exits plan mode. Approving exits Plan Mode and starts implementation under the selected permissions. Read which mode is being offered before you click.
• On Windows, Anthropic documents Alt+M as the alternative when the Node or Bun runtime does not enable VT input mode. That applies if Shift+Tab doesn't cycle modes for you.

Also note that the starting mode differs by account type. One third-party guide, citing the docs, says Pro, Max and Team accounts start in auto mode since version 2.1.228 (Windows: 2.1.233). The same guide says Enterprise plans, Console API keys, claude -p, the Agent SDK, and Bedrock, Vertex and Foundry start in Manual. Don't assume your session starts where a colleague's does. Check the status bar.

3. Keep implementation small and bounded​

Name the files or components in scope. State the conventions and the tests that must keep passing. Prefer small, reviewable batches over one sweeping rewrite. That is a risk-control recommendation, not a documented product limit. Project rules belong in a CLAUDE.md file, which the documentation describes as the place for conventions Claude should always follow.

The CLI also has permission controls for constraining behavior:

• --allowedTools and --disallowedTools set tool rules. A bare tool name such as Edit removes that tool entirely, while a scoped rule such as Bash(rm *) denies only matching calls.
• --max-turns limits agentic turns in print mode (-p) and exits with an error when the limit is hit.
• --max-budget-usd stops a print-mode run once estimated spend reaches a cap. Anthropic notes the figure is a client-side estimate that can differ from your bill, and spend can overshoot the cap.

4. Make verification explicit​

Give the tool the exact test, lint or build command and the expected result. Anthropic's own advice, as summarized in the source material, is that Claude does better when it has a way to check its work. Then check it yourself. Read the diff and rerun the tests independently. A plausible explanation or a freshly generated test is not proof of correctness.

5. Use Git and human review as the gate​

Treat the output as a proposed patch. Review it, confirm security-sensitive behavior, and then decide what to commit. For isolation, claude --worktree <name> starts a session in a separate git worktree under .claude/worktrees/. That keeps experimental changes away from your main working tree.

GitHub Actions: more limited than the hype​

Popular summaries say an @claude mention can create a pull request automatically. Anthropic's action documentation says otherwise for default behavior:

• Branches: On an issue, the action creates a new branch. On an open PR, it pushes to that PR's branch. On a closed PR, it creates a new branch.
• Pull requests: By default it commits to a branch and gives you a link to a prefilled PR page. A person has to click through and create the PR.
• What it cannot do: It cannot approve a PR, submit a formal GitHub review, merge or rebase. Arbitrary Bash commands are unavailable unless you allow them through the allowed_tools configuration.
• Access control: Only users with write access can trigger it. Bots are blocked by default. Setting allowed_bots to '*' on a public repository is called out as risky, and the docs say to prefer an explicit list.

Prompt injection is a real concern​

Anthropic warns that external contributors can hide instructions in HTML comments, invisible characters or hidden attributes. The action strips several of these, but the docs openly say new bypass techniques may emerge. The recommendation is to review the raw content of external input. On public repositories, include_comments_by_actor lets you allowlist whose comments reach Claude.

If you run it in CI, keep workflow permissions minimal. Store credentials in GitHub secrets, never in workflow files. Leave show_full_output off, because on public repos the logs are publicly visible and could expose secrets.

What the productivity numbers do and don't show​

The 2025 Stack Overflow survey found 84% of respondents are using or planning to use AI tools. I'm taking that figure from the survey's AI section as retrieved for this article. The same survey says 51% of professional developers use AI tools daily. It also reports that more developers distrust AI accuracy (46%) than trust it (33%). Adoption is high, and so is caution.

DORA's 2025 research says 90% of technology professionals use AI at work and over 80% believe it raised their productivity. DORA also reports that higher AI adoption is associated with both more delivery throughput and more delivery instability. Its analysis says time saved writing code is often re-spent on auditing and verification. It also points to a review burden: one author can generate a huge change faster than a reviewer can read it.

None of these studies measures Claude Code specifically. They show that AI-assisted development has real trade-offs. They don't show that this tool makes any given team faster.

DORA's practical advice lines up with the workflow above: work in small batches, invest in test automation, and measure impact rather than lines of code produced.

Claims to treat with caution​

• Tool availability: Lists of every surface the tool runs on (Slack, GitLab, scheduled routines and so on) need individual verification. Documentation reviewed for this article confirms the CLI, the desktop app, Windows and WSL setup, and the GitHub Action.
• MCP: The Model Context Protocol is an open standard for connecting AI applications to external systems. Support for the protocol doesn't mean any particular tracker, database or internal API is safe to connect. Vet each server and its permissions.
• Future-dated product claims: The explainer behind this story mentions an n8n MCP server update dated 2027. There is no supporting evidence for it, so I've left it out.
• Bypass mode: Reserve bypassPermissions for isolated containers or VMs. It skips permission prompts, and it doesn't belong on a primary machine holding credentials or uncommitted work.

Bottom line​

A defensible Claude Code workflow on Windows looks like this:

1. Install natively, or in WSL if your project lives there, and confirm with claude --version and claude doctor.
2. Start unfamiliar or high-risk tasks in plan mode, and read the plan before approving it.
3. Keep changes small, with project rules in CLAUDE.md.
4. Supply real test commands, then run them yourself.
5. Review the diff in Git as you would a junior colleague's pull request.
6. In CI, use least privilege, restrict who can trigger the action, and treat contributor input as hostile.

The tool shifts effort from typing to reviewing. Teams that already have strong tests and review habits will probably get the most out of it. Teams that don't may just produce unreviewed code faster.