Skip to main content
When Claude ignores an instruction or a feature you configured doesn’t appear, the cause is usually that the file didn’t load, it loaded from a different location than you expected, or another file overrode it. This guide shows how to inspect what Claude Code actually loaded so you can narrow down which applies. For installation, authentication, and connectivity problems, see Troubleshoot installation and login instead.

​
See what loaded into context

The /context command shows everything occupying the context window for the current session, broken down by category: system prompt, system tools, MCP tools, custom subagents with the source each loaded from, memory files, skills, and conversation messages. Run it first to confirm whether your CLAUDE.md, rules, or skill descriptions are present at all. For detail on a specific category, follow up with the dedicated command: If a memory file is missing from the /context breakdown, check its location against how CLAUDE.md files load. Subdirectory CLAUDE.md files load on demand when Claude reads a file in that directory with the Read tool, not at session start. If /context confirms the file loaded but Claude still isn’t following a particular instruction, the issue is likely how the instruction is written rather than whether it loaded. CLAUDE.md works well for the kinds of guidance you’d give a new teammate, such as project conventions, build commands, and where files belong. Adherence drops when an instruction is vague enough to interpret multiple ways, when two files give conflicting direction, or when the file has grown long enough that individual rules get less attention. Write effective instructions covers the specificity, size, and structure patterns that keep adherence high.
CLAUDE.md and permissions solve different problems. CLAUDE.md tells Claude how your project works so it makes good decisions. Permissions and hooks enforce limits regardless of what Claude decides. Use CLAUDE.md for “we do it this way here.” Use permissions or hooks for security boundaries and anything that must never happen, where you need a guarantee instead of guidance.

​
Check resolved settings

Settings merge across managed, user, project, and local scopes. Managed settings always win when present. Among the rest, the closer scope overrides the broader one in the order local, then project, then user. Some settings can also be set by command-line flags or environment variables, which act as another override layer. When a setting doesn’t seem to apply, the value you set is usually being overridden by another scope or an environment variable. Run /doctor to check your configuration and installation. It reports what it finds, including invalid settings files, duplicate installations, unused extensions, and checked-in CLAUDE.md content Claude can derive from the codebase, then proposes fixes it applies only after you confirm. The CLAUDE.md trim check requires Claude Code v2.1.206 or later. Before v2.1.205, /doctor opened a read-only diagnostics screen and pressing f sent the report to Claude to fix. From the terminal, claude doctor prints read-only installation and settings diagnostics without starting a session. Run /status to see which settings sources are active, including whether managed settings are in effect. To understand which scope wins for a given key, see How scopes interact.

​
Check MCP servers

Run /mcp to see every configured server, its connection status, and whether you have approved it for the current project. A server can be defined correctly but still not provide tools for a few common reasons:
  • Project-scoped servers in .mcp.json require a one-time approval. If the prompt was dismissed, the server stays disabled until you approve it from /mcp.
  • A server that fails to start shows as failed in /mcp. Relative file paths in command or args are a frequent cause, since they resolve against the directory you launched Claude Code from rather than the location of .mcp.json.
  • A server that shows as connected but lists zero tools has started successfully but isn’t returning a tool list. Select Reconnect from /mcp. If the count stays at zero, run claude --debug mcp to see the server’s stderr output.
For configuration locations and scope rules, see MCP.

​
Check hooks

Run /hooks to list every hook registered for the current session, grouped by event. If a hook you defined doesn’t appear, it isn’t being read: hooks go under the "hooks" key in a settings file, not in a standalone file. If the hook appears but doesn’t fire, the matcher is the usual cause. Check it for these mistakes:
  • The matcher field is a single string that uses | to match multiple tool names, for example "Edit|Write". A , separator is equivalent, so "Edit,Write" matches the same tools. Before v2.1.191, a comma fell through to regex evaluation and the matcher never matched, so use | if you aren’t on v2.1.191 yet.
  • A misspelled tool name produces a matcher that matches nothing, so the hook fails silently.
  • An array value is a schema error: Claude Code shows a settings error notice and rejects the whole user, project, or local settings file, claude doctor reports the validation failure, and no hook from that file appears in /hooks. In managed settings, only the invalid entry is stripped and the file’s other hooks still apply.
Edits to settings.json take effect in the running session after a brief file-stability delay. You don’t need to restart. If /hooks still shows the old definition a few seconds after saving, run /hooks again to refresh the view. If /hooks shows the hook but it still does not fire, the next step is to watch hook evaluation live. Start a session with claude --debug hooks and trigger the tool call. The debug log records each event, which matchers were checked, and the hook’s exit code and output. See Debug hooks for the log format and hooks troubleshooting for common failure patterns.

​
Test against a clean configuration

Start with claude --safe-mode, which launches a session with all customizations disabled, including CLAUDE.md, skills, plugins, hooks, MCP servers, and custom commands and agents. Authentication, model selection, built-in tools, and permissions work normally. If the problem disappears in safe mode, one of those surfaces is the cause; use the targeted checks above to find which. Safe mode still applies managed hooks and settings policy from your organization. Managed plugins, skills, CLAUDE.md, and MCP servers are turned off. If the problem persists in safe mode, or your settings themselves are suspect, compare against a session that loads nothing from your usual setup. Point CLAUDE_CONFIG_DIR at an empty directory to bypass everything under ~/.claude, and launch from a directory that has no .claude folder, .mcp.json, or CLAUDE.md so project configuration is also skipped.
The clean session has no user or project settings, hooks, MCP servers, plugins, or memory. On the first launch, expect the first-run setup screens, starting with theme selection. If you see them, the clean configuration directory is in effect. Later launches with the same directory skip these screens because Claude Code saves onboarding state there.
  • Managed settings still apply if your organization deploys them, since they live at a system path outside ~/.claude
  • On Linux and Windows, you’ll be prompted to log in again because credentials are stored under the configuration directory
  • On macOS, credentials are in the Keychain and carry over to the clean session
If the problem disappears here, the cause is somewhere in your real ~/.claude or project .claude files. Reintroduce them one at a time, by copying files into the temporary directory or by launching from your project, to find which one. If it persists in the clean session, the cause is outside your user and project configuration. Run /status to check whether managed settings are in effect, look for environment variables that affect Claude Code, then see Troubleshooting.

​
Check common causes

Most configuration surprises trace back to a small set of location and syntax rules. Check these before assuming a bug: For full reference on each configuration surface, see the dedicated page: