This guide explains Claude Code’s configuration and environment management: where settings live, how project and personal settings differ, how to protect secrets, how to use the CLAUDE.md memory file to give the assistant project context, and how to use the claude CLI for quick configuration checks and edits. Follow the examples to secure sensitive data and make team-wide settings consistent.Documentation Index
Fetch the complete documentation index at: https://notes.kodekloud.com/llms.txt
Use this file to discover all available pages before exploring further.
Quick overview: settings types and typical uses
| Settings Type | Scope | Typical Path(s) | Use Case |
|---|---|---|---|
| User-level | Single user / machine | macOS/Linux: ~/.claude/settings.jsonWindows: C:\Users\<YourUser>\AppData\Roaming\ClaudeCode\settings.json | Personal preferences (editor, telemetry opt-in, UI flags). Not usually checked into source control. |
| Project-level | Repository-scoped | <repo>/.cloud/settings.json or <repo>/.claude/settings.json | Team-shared rules, tool permissions, environment overrides. Committed to repo. |
| Local (untracked) | Developer override | <repo>/settings.local.json (gitignored) | Personal experiments, local tokens, per-developer preferences. |
| Managed / Enterprise | Organization-managed | macOS: /Library/Application Support/ClaudeCode/managed-settings.jsonLinux/WSL: /etc/claude-code/managed-settings.jsonWindows: C:\ProgramData\ClaudeCode\managed-settings.json | Centrally enforced policies for telemetry, tool access, denied paths. |
User-level settings
User preferences are kept in a user settings file. Examples: macOS / Linux:code (VS Code CLI) isn’t installed on macOS you may see:
Project-level settings (checked into source control)
To share configuration across the team, add a.cloud or .claude folder at the repository root and place a settings.json there. These project-scoped settings are typically committed to the repo so teammates receive the same permissions and environment overrides.
Example project settings.json:
| Field | Purpose |
|---|---|
permissions.allow | Controls which automatic/invoked tools or file reads the assistant can perform. |
permissions.deny | Blocks access to sensitive files, folders and commands. |
defaultMode | Controls edit behavior (for example, acceptEdits). |
additionalDirectories | Grants the assistant access to sibling repos or extra project paths. |
env | Environment variables to set when running tools or the assistant in the project context. |
Local, untracked project preferences
Usesettings.local.json at the project root for developer-specific overrides that must not be committed. Claude Code will add this file to .gitignore when it detects it.
Example settings.local.json:
Enterprise / Managed settings
For centralized administration in larger organizations, putmanaged-settings.json in system-wide locations:
Important: protecting secrets
A core security practice is using thepermissions block to prevent the assistant from reading secrets and environment files. Example deny rules:
Deny patterns are powerful. Use them to explicitly block access to environment files, a secrets directory, or other sensitive build output.
- Prefer explicit deny patterns for any credential or token files.
- Deny recursive folders (e.g.,
secrets/**) to block subdirectories. - Keep project-level deny rules in the committed
settings.jsonto ensure the whole team is protected.
The memory file: CLAUDE.md
CLAUDE.md is a project-scoped memory file that is loaded at assistant startup to provide context: setup steps, common commands, dependencies, and the project layout. This helps the assistant provide accurate, context-aware suggestions. Example CLI output when Claude Code generates CLAUDE.md:CLAUDE.md contents for a Python Flask METAR reader:
Keep CLAUDE.md concise and focused on the commands and structure the assistant needs to bootstrap tasks quickly. Include setup commands, test commands, and any environment quirks.
CLI: viewing & setting configuration
Claude Code offers a CLI for inspecting and changing settings quickly. Common commands:- List all config:
- Get a config key:
- Set a config key (local to the repository):
- Set a config key globally (machine-wide):
env variables in settings are incorrect:
env in your user, project, or managed settings and verify valid values (for example grpc, http/protobuf) per your OpenTelemetry exporter. See OpenTelemetry docs: https://opentelemetry.io/docs/.
Preferences & UX features
Claude Code supports several toggles and UX options that can be set via UI or the CLI:- Auto-compact
- Use todo list (true/false)
- Checkpointing (recommended)
- Verbose output
- Auto-updates
- Theme (dark/light)
- Editor mode
- Model selection
- Diff tool
- Auto-install IDE extension
Summary — Best practices for secure, consistent configuration
- Use the user-level
~/.claude/settings.jsonfor machine-specific preferences. - Commit project-wide settings to
.cloudor.claude/settings.jsonso team members share rules and denies. - Keep
settings.local.jsonfor per-developer untracked overrides and local experiments. - Apply
managed-settings.jsonin enterprise environments to centrally enforce policies. - Deny reading of
.env,secrets/, build output, and other sensitive paths inpermissions.deny. - Create and maintain a concise
CLAUDE.mdmemory file with setup commands and the project structure to prime the assistant. - Use the
claude configCLI to inspect and update settings; correct OpenTelemetry environment variables if you receive OTEL-related errors.
Links and references
- Claude Code settings reference: https://docs.anthropic.com/en/docs
- OpenTelemetry: https://opentelemetry.io/docs/
- JSON Schema for settings (example): https://json.schemastore.org/claude-code-settings.json