Use claude config to View and Manage All Your Settings from the CLI
Claude Code settings live in JSON files at three different scopes, and it's easy to lose track of what's set where. The claude config command lets you inspect and modify everything from your terminal.
# List all current settings
claude config list
# See where a specific setting is configured
claude config get allowedTools
You can set values at any scope — local (machine-specific, gitignored), project (shared with your team), or user (global defaults):
# Set a project-wide default model
claude config set --project model sonnet
# Set a personal preference that stays out of git
claude config set --local model opus
# Set a global default for all projects
claude config set --user theme dark
The three scopes layer on top of each other — local overrides project, which overrides user. This is the same hierarchy as the JSON files, but without needing to remember where each file lives.
Some useful commands:
# See which MCP servers are configured
claude config get mcpServers
# Check your current permissions setup
claude config get permissions
# Remove a setting
claude config unset --local model
# List everything, showing which scope each value comes from
claude config list --all
This is especially handy when debugging unexpected behavior. If Claude is using the wrong model or missing an MCP server, claude config list --all shows you exactly which setting file is responsible.
Stop editing JSON files by hand — claude config gives you a clean CLI for every setting across every scope.
via Claude Code
Log in to leave a comment.
When Claude writes error messages, button labels, validation text, or onboarding flows, it defaults to generic developer-speak. Add a "Users" section to your CLAUDE.md describing who your actual users are — their technical level, industry jargon, and what they care about — so Claude writes copy that makes sense to THEM, not to developers.
Use the --agent flag with custom markdown files in .claude/agents/ to launch purpose-built Claude sessions with restricted tools and scoped system prompts.
Every project has traps — the billing module that silently fails if you forget to queue the job, the legacy table with column names that don't match the model, the config value that must be set before tests run. Document these gotchas in your CLAUDE.md so Claude avoids the same mistakes your team spent days debugging.