Feature Request: Configuration and Memory Inspector for Improved Visibility and Debugging

Title: Feature Request: Configuration and Memory Inspector for Improved Visibility and Debugging

Labels: enhancement, configuration, dx (Developer Experience), feature-request

Problem Statement

Claude Code's configuration system is extremely powerful, deriving its context from a complex hierarchy of settings files (settings.json), memory files (CLAUDE.md), command-line flags, and dynamically loaded components like sub-agents and MCP servers.

This layered approach, while flexible, creates a significant challenge for discoverability and debugging. It is difficult for a user to determine the exact, fully-resolved state of their session. This opacity makes it very hard to answer common questions:

• "Why was this Bash command allowed/denied? Which permission rule was responsible?"
• "Which of the many CLAUDE.md files (from the project, parent directories, my home folder, etc.) are currently active?"
• "Is the model I specified via a CLI flag being used, or was it overridden by a settings file?"
• "Why isn't Claude following the instructions I put in a specific CLAUDE.md file?"
• "Which sub-agents and MCP tools are available for use in this specific project?"

The current system relies on the user manually checking multiple file locations (~/.claude/, .claude/), remembering CLI flags, and understanding the precedence rules. This makes troubleshooting inefficient and can lead to unexpected or unpredictable agent behavior.

Proposed Solution

We propose the creation of a Configuration and Memory Inspector command. This would be a read-only diagnostic tool that provides a comprehensive, formatted report of the fully resolved configuration for the current Claude Code session.

A potential command could be /inspect-context or an enhancement to /doctor.

This tool would introspect all configuration sources (Enterprise Policy, CLI flags, project settings, user settings, memory files, etc.) and present a unified, clear view of the agent's current operating parameters. This empowers users to understand and debug the "why" behind the agent's behavior.

Feature Breakdown

The inspector command should output a structured report covering the following areas:

1. Resolved Memory Context

• Loaded Memory Files: A list of all CLAUDE.md and CLAUDE.local.md files that were loaded, including their absolute paths, to clarify the scope (User, Project, parent directories).
• Import Tree: A tree view of any files that were recursively imported via the @path/to/file syntax within the memory files, showing the import hierarchy.
• Final Merged Memory: The final, concatenated text from all memory sources that is being provided to the model as part of the system prompt. This allows the user to see exactly what instructions the agent is working with.

2. Resolved Settings & Permissions

• Settings Precedence: A clear breakdown of key settings (e.g., model, permissionMode, cleanupPeriodDays) and their final values. For each setting, the report must indicate the source that provided the winning value (e.g., "from --model CLI flag", "from .claude/settings.json", "from Enterprise Policy").
• Permission Rules: The final, merged allow and deny lists for tool permissions. Each active rule should indicate its source file (e.g., ~/.claude/settings.json). The report should explicitly show how precedence was resolved (e.g., DENY 'Bash(git push*)' (from .claude/settings.local.json) overrides ALLOW 'Bash(*)' (from ~/.claude/settings.json)).
• Working Directories: A list of all active working directories Claude has access to, including the primary cwd and any added via /add-dir or settings files.

3. Tool & Agent Roster

• Available Tools: A complete list of all tools the agent can currently use, including built-in tools (Read, Bash, Edit, etc.) and any tools dynamically loaded from active MCP servers.
• Available Sub-agents: A list of all loaded sub-agents, specifying their name, scope (Project vs. User), and the path to their definition file.

Acceptance Criteria

• A new user-facing command (e.g., /inspect-context) is available in the interactive REPL.
• Executing the command prints a formatted, read-only report to the terminal containing the sections described in the "Feature Breakdown".
• The report accurately reflects the final, resolved state after applying the full configuration hierarchy (Enterprise Policy > CLI > Project Local > Project > User).
• The command is purely diagnostic and does not alter the current session's state.

Describe alternatives you've considered

1. Enhanced Verbose Logging (--verbose):

We considered simply adding more configuration details to the existing verbose logging output. However, this was deemed insufficient. A verbose log is a stream of events and debug information, making it difficult for a user to find a specific, resolved setting. The goal is a clean, structured, on-demand report of the final state, not a noisy log of the configuration loading process.

1. Relying on Documentation and Manual Inspection:

The status quo is to have the user read the documentation and manually check all possible file locations. This is precisely the problem we aim to solve. This approach is inefficient, error-prone, and requires the user to mentally compute the precedence rules, which can be complex.

1. Multiple, Granular Inspection Commands:

An alternative was to create several smaller commands, such as /inspect-permissions, /inspect-memory, /inspect-model, etc. This was rejected in favor of a single, comprehensive report because the core problem is the fragmented nature of the configuration. A unified inspector provides a holistic view, which is far more valuable for debugging than running multiple separate commands.

Justification

This feature directly aligns with Claude Code's philosophy as a power tool for developers. By providing transparency into its own configuration, we empower users to harness its full potential, reduce frustration, and debug complex interactions effectively. It moves configuration from a "black box" to a clear, inspectable system, which will significantly improve the overall developer experience (DX) and build user trust.