9 Recommended Claude Settings | Ultimate Customization for Web and Code

Step 1: Overview of Recommended Claude Settings | Web Version and Claude Code Have Different Configuration Areas {#step1}

Claude comes in two main variants: the Web version at claude.ai, used via a browser, and Claude Code (CLI), invoked from the terminal. Because the settings UI and configuration files are completely separate, start by deciding which you primarily use and set your priorities accordingly.

For casual users, adjusting just three things in the Web version — privacy, memory, and style — is sufficient. Developers who work with code daily should tune CLAUDE.md and settings.json in Claude Code first; neglecting these means you'll only ever get half the potential out of the tool. If you use both, configure them in order: Web version first, then Claude Code — this removes any guesswork. Source

Step 2: Data Privacy in the Web Version | Turn Off Model Training and Shorten Retention to 30 Days {#step2}

By default, content you enter in the Web version of claude.ai may be used to improve Anthropic's models, and with training data sharing enabled, data can be retained for up to 5 years. If you discuss work conversations or customer information, you'll want to turn this off right away.

Here's how:

1. Click the account icon in the bottom right of claude.ai and open "Settings"
2. Go to the "Privacy" tab and select "Data Privacy Controls"
3. Toggle "Help improve Claude" to Off

That's it — your data retention period will be reduced to 30 days. Team and Enterprise plan users have this off by default, but Free, Pro, and Max users need to disable it manually. Source

Step 3: Memory Feature in the Web Version | Memories Persist on a Separate Layer — Regular Cleanup Is Essential {#step3}

⚠️ Warning: Deleting your conversation history does NOT delete your memories. Memories must be deleted separately under "Settings → Memory."

Claude's memory operates on a layer independent from conversation history — deleting past conversations does not erase the memories themselves. Many people delete conversations thinking that's enough, but it isn't.

Here are three recommended practices:

1. Once a month, open "Settings → Memory" and manually delete any unnecessary memories
2. Before discussing sensitive topics, temporarily disable automatic memory creation
3. When switching between projects, review and clean up memories from the previous project

While memories are convenient, they can be referenced in unexpected contexts. Think of "disable training" and "clean up memories" as a pair to stay safe.

Step 4: Response Style and Preferences | Lock In Tone and Language for Consistent Output {#step4}

To access this setting, click the account icon in the bottom right → open "Settings → Style" (or "How Claude responds") and enter your preferences in the text box.

Claude's "Style settings" let you declare a default tone and output rules for all conversations. Since you no longer need to add the same instructions at the start of every prompt, the impact is especially high for professional use.

Here are three lines we recommend registering in your preferences:

1. "Answer in English, concisely. Omit verbose preambles."
2. "When providing code, limit it to the minimal runnable example."
3. "If you cannot be certain, clearly indicate that it is a guess."

This alone reduces the perceived frequency of hallucinations and frees you from the stress of typing the same instructions every time. If you're sharing settings with a team, save the style text in Notion or similar so it can be reused.

Step 5: CLAUDE.md in Claude Code | Maintain an Instruction File That Is Automatically Loaded at Startup {#step5}

Claude Code automatically reads CLAUDE.md in the current directory at startup and treats its contents as context for all conversations. By consolidating your project's coding conventions, prohibited actions, and task granularity here, you dramatically reduce how much you need to type each session. Source

Here's what to include from the start:

1. Project overview (tech stack and main directory structure)
2. Conventions to follow (naming, testing, commit messages)
3. Things not to do (no direct push, hands off certain directories, etc.)
4. Contact information / reference links when stuck

Be careful about letting it grow too large — keeping it "concise, specific, and minimal" is the right philosophy for sustainable long-term use.

Step 6: Hierarchical Design of settings.json | Separate Global and Project Settings by Role {#step6}

Claude Code's behavior is controlled by two layers: ~/.claude/settings.json (global) and .claude/settings.json in the project root (project-specific). One common pitfall: settings are not inherited from parent directories — only the file in the startup directory is active.

Here's the recommended division of responsibilities:

What to put in the global file (~/.claude/settings.json)

• Notifications shared across all projects (completion sounds, Slack notifications, etc.)
• Read blocks for sensitive files (.env, keys, secrets.*)
• Global bans on dangerous commands (rm -rf *, git push --force)

What to put in the project file (.claude/settings.json)

• Repository-specific permission allowlists (specific Bash commands)
• Hooks that only fire on files within that repository
• Environment variables used only in that project

Deciding on this division upfront keeps things from spiraling out of control as settings accumulate over time.

Step 7: Permissions Allowlist | Block Dangerous Commands Before Enabling Auto Mode {#step7}

Claude Code has an Auto Mode that skips confirmation prompts, but blocklisting dangerous commands before turning it on is the minimum requirement to prevent accidents. Operations that can't be undone once run are prone to judgment errors even with confirmation dialogs — blocking them at the root is the right call.

Key commands to block at a minimum:

1. Recursive deletion (rm -rf and similar)
2. git push --force / git reset --hard
3. External script execution via curl ... | sh
4. Cloud-destructive commands like aws or gcloud
5. DROP TABLE / TRUNCATE on databases

For the allowlist, it's operationally easiest to only Allow operations you can recover from at worst — read-only commands, test runners, local builds, and so on. Source

Step 8: Recommended Uses for Hooks | Opt-In Patterns to Prevent Accidental Firing {#step8}

Hooks let you fire your own scripts in response to Claude Code events (SessionStart, PreToolUse, Stop, etc.) — a powerful tool for automating operational rules. However, Hooks that run unconditionally across all repositories are an accident waiting to happen, so designing with an opt-in principle is the rule.

Recommended patterns:

1. Marker file pattern: Only fire Hooks when a .claude-hooks-enabled file exists in the repository root
2. Check git status in PreToolUse: Prevent overwriting changes made by another session
3. Read important documents in SessionStart: Force Claude to read config files and SOPs at the start of every session
4. Notify via Stop hook: Alert Slack or the notification center on completion so you don't have to wait and watch

Avoid going "all in" — start with a single marker-file–based Hook to minimize the risk of accidental firing.

Step 9: Verification and Operations Tips After Changing Settings | Pair Live Testing With Monthly Reviews {#step9}

After making configuration changes, always verify behavior with real usage. For CLAUDE.md, send one small test request and confirm it follows your conventions. For permissions, intentionally try a blocked command to confirm it's stopped. For Hooks, visually check that SessionStart logs are being written correctly.

Three recommendations for long-term operation:

1. Monthly review: Spend 15 minutes reviewing memories, CLAUDE.md, and settings.json
2. Treat config changes as PRs: In team setups, manage .claude/settings.json in git and require review
3. Log failures: When something goes wrong or misfires, add it to CLAUDE.md under "Things not to do"

Settings are never finished on the first pass — treating them as something to "grow over time" is the key to getting long-term value from Claude.

Summary | Priority Order for Recommended Claude Settings: "Privacy → Rules → Permissions" {#summary}

Claude's settings may seem daunting at first glance, but covering the 3 Web version items (privacy, memory, style) + 4 Claude Code items (CLAUDE.md, settings.json, permissions, Hooks), plus an overview and verification — all 9 steps outlined in this article — will simultaneously raise both safety and productivity. In particular, just working through "data privacy → CLAUDE.md → permissions" in that order will eliminate nearly all unexpected accidents.

Casual users should handle the Web version only; developers should go further into Claude Code; and teams should keep settings.json and CLAUDE.md under git management. That is the current best practice. Start today by spending 15 minutes opening your profile settings and changing just one thing.