Build Your Perfect Claude Code Setup

The Problem

You just installed Claude Code. It works. But every time it reads a file — "Allow?" Every time it runs a test — "Allow?" You tell it your project uses TypeScript and functional components, and tomorrow it forgets. Your coworker's Claude Code somehow knows the project conventions, runs tests without asking, and never suggests class components. Yours feels like a brand new hire every morning.

What You're Building

A fully configured Claude Code environment: global settings that kill the permission spam, a memory file that teaches Claude your conventions permanently, project permissions your team can share via git, an MCP server that connects Claude to GitHub, and a safety hook that catches you before accidental pushes. After this, Claude Code works like it actually knows you.

Milestone 1: Kill the Permission Prompts

Every "Allow read?" dialog is a context switch. Your flow is broken, you click yes, and you've lost your thought. Let's fix that in one shot.

Prompt:

Create a file at ~/.claude/settings.json that allows these tools without asking: Read, Edit, Write, Glob, and Grep. Also allow Bash for git and npm commands using wildcard patterns like "Bash(git *)" and "Bash(npm *)". Set the default permission mode to "default".

What Claude Code does: It creates your global settings file — ~/.claude/settings.json. This is the top-level config that applies to every project. The permissions.allow array tells Claude Code which tools can run without prompting. Wildcard patterns like Bash(git *) mean any git command is pre-approved.

Try it: Open a new Claude Code session. Ask it to read any file — no permission prompt. Ask it to run git status — runs immediately.

Milestone 2: Give Claude a Memory

You told Claude this is a React project with functional components yesterday. Today it suggests a class component. CLAUDE.md fixes this permanently.

Prompt:

Create a CLAUDE.md file in the root of my current project. Include these instructions: this is a TypeScript project using React 18. Always use functional components with hooks. Prefer named exports over default exports. Tests go in __tests__ folders next to their source files. Use CSS modules for styling. Error messages should be user-friendly, never show raw error objects.

What Claude Code does: It creates a CLAUDE.md memory file in your project root. Claude Code reads this file at the start of every session — it's persistent context. Think of it as onboarding documentation that Claude actually reads. Every rule you put here applies automatically, every session, without repeating yourself.

Try it: Start a new Claude Code session in this project. Ask it to "create a Button component." It should generate a functional component, use named export, create a CSS module, and place tests in a __tests__ folder. You didn't specify any of that — CLAUDE.md did.

Milestone 3: Lock Down Project Permissions

Your global settings are permissive — that's fine for personal projects. But this project has a production database. You want tests to run freely but destructive commands blocked. Project settings let you tighten things per repo.

Prompt:

Create a .claude/settings.json file in my project that allows Bash for test commands using patterns like "Bash(npm test *)" and "Bash(jest *)" and "Bash(vitest *)". Allow Bash for build commands like "Bash(npm run build)" and "Bash(npm run dev)". Deny Bash for destructive commands using patterns like "Bash(rm *)" and "Bash(rmdir *)".

What Claude Code does: It creates a project-level settings file at .claude/settings.json. Project settings override global settings — they're more specific. Deny rules always take priority over allow rules, so even if your global config allows all Bash commands, rm is blocked in this project. Since this file lives in your repo, your whole team gets the same guardrails when they clone it.

Try it: Ask Claude Code to run your tests — it should execute without prompting. Then ask it to run rm -rf node_modules. It should be denied.

Milestone 4: Connect Claude to GitHub

Claude Code can read your files, run commands, and remember your conventions. But it can't browse your GitHub issues, check PR reviews, or look up workflows — it's limited to your local filesystem. MCP servers break that wall.

Run this command in your terminal (not inside Claude Code):

Prompt:

claude mcp add --scope project --transport http github https://api.githubcopilot.com/mcp/

What Claude Code does: This registers a Model Context Protocol (MCP) server — an external tool that extends Claude's capabilities beyond your local machine. The --scope project flag saves the config to .mcp.json in your project root so teammates get it automatically. When you start Claude Code, it'll prompt you to authenticate with GitHub via OAuth.

Try it: Run claude mcp list to see it registered. Start Claude Code and complete the GitHub auth flow. Then ask "what are the open issues on this repo?" — Claude can now pull that data directly from GitHub.

Milestone 5: Add a Push Safety Net

You're in flow. Claude is committing and pushing. Then you realize it pushed to main. A hook can catch that before it happens.

Prompt:

Add a PreToolUse hook to my .claude/settings.json that matches the "Bash" tool. The hook should run this command: bash -c 'input=$(cat); cmd=$(echo "$input" | grep -o "\"command\":\"[^\"]*\"" | head -1); if echo "$cmd" | grep -q "push"; then echo "WARNING: About to push to remote. Confirm this is intentional." >&2; exit 2; fi; exit 0'. Set the timeout to 10 seconds.

What Claude Code does: It adds a hook to your project settings. Hooks fire automatically before or after tool use. PreToolUse runs before Claude executes any Bash command. The hook reads the command from the JSON input piped to stdin, checks if it contains "push", and either blocks it (exit code 2 sends the warning message to Claude) or allows it (exit code 0). This is your safety net — a programmable guardrail that catches risky commands before they run.

Try it: Ask Claude Code to run git push origin main. The hook fires, blocks the push, and shows the warning. Ask it to run git status — goes right through.

What You Built

Remember the Claude Code that asked permission for everything and forgot your conventions daily? That's gone.

You now have:

• Global settings that pre-approve safe tools across all projects
• CLAUDE.md that teaches Claude your project's rules — once, permanently
• Project permissions that your team shares through git
• An MCP server that connects Claude to GitHub
• A safety hook that catches accidental pushes

Five files. Fifteen minutes. Claude Code now works like it actually knows you and your project.

Take It Further

• Add a ~/.claude/CLAUDE.md for personal preferences that apply everywhere — your coding style, preferred libraries, formatting rules
• Create .claude/rules/*.md files with path-specific rules — different conventions for frontend vs backend code in the same monorepo
• Set up more MCP servers — connect Claude to your database, Sentry, or Slack using claude mcp add