Using Claude Code on a React Project: CLAUDE.md, Permissions, and Workflow Tips
Needs reviewLast verified August 12, 2026·4 min read
Claude Code has no React-specific mode — what actually makes it effective on a React codebase is the same CLAUDE.md and permissions setup that works on any project, applied deliberately. This guide walks through what to put in CLAUDE.md for a React app, which commands to allow, and how to structure a component or test-fixing session.
Claude Code doesn't know it's looking at React — until you tell it
There's no React-specific configuration flag or mode in Claude Code. It reads and edits .jsx/.tsx files the same way it reads and edits any other text file, using whatever TypeScript, ESLint, or bundler tooling your project already has set up. The thing that actually changes how well it works on a React codebase is the same lever that changes how well it works on any codebase: what you've told it in CLAUDE.md, and what you've allowed it to run.
This guide is ClaudeDetails' own practical guidance for applying those real, general Claude Code mechanisms to a typical React project — it isn't a claim that Anthropic publishes React-specific documentation, because they don't.
Start with /init, then make it React-specific
Running /init inside a React project gives you a starting CLAUDE.md scaffold based on what Claude Code can infer from your repo. Treat that as a first draft, not a finished file. Worth adding by hand:
Which tooling you're actually on — Vite, Next.js, Create React App, or something custom. The dev server command, build command, and test command differ enough between them that spelling this out once saves Claude Code from guessing (or asking) every session.
Your testing setup — Jest vs. Vitest, whether you use React Testing Library, and where test files live relative to the components they cover (co-located *.test.tsx vs. a separate __tests__ directory).
State management approach — plain useState/useReducer, Context, or a library like Redux or Zustand. Without this, a model asked to "add state" has no way to know which pattern your codebase actually uses.
Styling approach — CSS Modules, Tailwind, styled-components, or plain CSS. Same reasoning: this determines what a correct-looking change actually looks like in your project.
Put your real commands in CLAUDE.md
Claude Code can run shell commands through its Bash tool, subject to whatever permission mode you're using — but it has to know what to run. Listing your actual package.json scripts in CLAUDE.md (npm run dev, npm test, npm run build, npm run lint) means Claude Code can run the right one directly instead of guessing at a command that might not match your project.
Set permissions around your real workflow, not the defaults
The Claude Code permissions guide covers how allow/ask/deny rules work in general. Applied to a typical React project, the practical split is usually:
Low-friction to allow: running the test suite, running the linter, starting the dev server — none of these mutate anything you can't easily regenerate.
Worth keeping gated: anything that touches package.json/lockfile installs, git operations that rewrite history, or deployment commands — the same caution that applies to any codebase, not something specific to React.
A concrete workflow: fixing a failing test
A pattern that works well in practice: point Claude Code at a specific failing test file rather than the whole suite, and ask it to make that test pass without changing the test's intent. Because it can run your real test command (once CLAUDE.md and permissions are set up as above), it can iterate — run the test, read the failure, adjust the component, run again — instead of guessing at a fix and waiting for you to report back whether it worked.
The same pattern applies to component work: ask Claude Code to follow the conventions of an existing, similar component in your codebase rather than describing the pattern from scratch each time. This is exactly what documenting your conventions in CLAUDE.md is for — it turns "follow our patterns" into something Claude Code can actually check against instead of inferring fresh every session.
MCP servers if you need external context
If your workflow involves things outside the repo itself — an issue tracker, a design system's component docs, a deployed preview environment — connecting an MCP server can give Claude Code access to that context directly. The MCP directory is a real, growing list of servers if you're looking for one that matches a tool you already use; there's nothing React-specific about this step either — it's the same general MCP setup covered elsewhere on this site.
claudedetails.com is an independent publication and is not affiliated with, endorsed by, or sponsored by Anthropic. "Claude" is a trademark of Anthropic, PBC, used here for identification purposes only. Product details can change — always confirm specifics on Anthropic's own site before making decisions based on this post.
FAQ
Does Claude Code work differently for Next.js, Vite, or Create React App?
Not at the tool level — there's no per-framework mode. The real differences are in the commands and conventions you document in CLAUDE.md (dev server command, build command, file structure), not in how Claude Code itself behaves.
Do I need TypeScript configured for Claude Code to work with JSX/TSX files?
No — Claude Code reads and edits these files like any other source file. If your project uses TypeScript or ESLint, Claude Code works with whatever errors or conventions that tooling already surfaces; it doesn't require extra setup beyond what your project has.
Can Claude Code run my test suite automatically?
It can run any command you've approved via its permission settings, including your project's real test script — see the Claude Code permissions guide for how allow/ask/deny rules work.
Is a CLAUDE.md file required to use Claude Code on a React project?
No, but it meaningfully reduces how much context Claude Code has to re-infer each session — see the CLAUDE.md and auto memory guide for what it does and how to generate a starting one with /init.
This guide walks through the everyday prompt patterns Anthropic documents for Claude Code: getting an overview of an unfamiliar codebase, locating relevant files, fixing bugs from error messages, refactoring legacy code safely, adding tests for uncovered code, creating pull requests, and generating documentation. It also notes related workflows the docs cover, such as resuming sessions, running parallel sessions with worktrees, planning before edits, delegating research to subagents, and piping Claude into scripts.
This guide explains how to create a custom Claude Code plugin from scratch. It covers when to use a plugin versus standalone configuration in the .claude directory, how to structure a plugin directory with a .claude-plugin/plugin.json manifest, how to add a skill using a SKILL.md file, how to test the plugin locally with the --plugin-dir flag, and how to make skills accept user input with the $ARGUMENTS placeholder. It is based on Anthropic's documentation for Claude Code plugins.
This guide explains how to connect Claude Code to external tools and data sources using the Model Context Protocol (MCP). It covers what MCP connections enable, such as working with issue trackers, databases, and monitoring tools; where to find reviewed connectors; how to scaffold your own server with the official mcp-server-dev plugin; and how to install remote HTTP, remote SSE, and local stdio servers, including transport-specific flags, JSON configuration pitfalls, and environment variables like CLAUDE_PROJECT_DIR.
ClaudeDetails