Feature Request: Introduce a Formal Extension System for Bundling Configurations

Title: Feature Request: Introduce a Formal Extension System for Bundling Configurations

Labels: feature-request, enhancement, configuration, extensions

Body:

Is your feature request related to a problem? Please describe.

First, I want to say that the extensibility of Claude Code is incredibly powerful. Features like hooks, the Model Context Protocol (MCP), and custom slash commands provide a fantastic foundation for tailoring the tool to specific workflows.

However, these extensibility features are currently configured in disparate locations:

• Tool permissions and hooks are in settings.json.
• Custom slash commands are in .claude/commands/.
• MCP servers are configured via the CLI or in .mcp.json.

This separation makes it difficult to package, share, and manage a cohesive "bundle" of functionality. For example, if a team wants to create an integration for an internal tool (e.g., Jira), they would need to provide instructions for developers to:

1. Add an MCP server configuration.
2. Add a set of custom slash commands for common actions.
3. Update their settings.json to allowlist the necessary MCP tools.
4. Provide a CLAUDE.md file with instructions on how to use the new tools.

This manual, multi-step process is error-prone and creates friction for onboarding developers to a customized Claude Code environment.

Describe the solution you'd like

I propose introducing a formal extension system, inspired by the design found in Google's Gemini CLI (docs/extension.md). This system would allow developers to bundle related configurations into a single, shareable package.

Here's how it could work:

1. Extension Directory: Claude Code would look for extensions in ~/.claude/extensions/ (user-level) and ./.claude/extensions/ (project-level).

1. Extension Structure: Each extension would be a subdirectory, for example, ./.claude/extensions/my-jira-integration/.

1. Manifest File: Inside each extension directory, there would be a manifest file, e.g., claude-extension.json, that defines the resources the extension provides.

An example claude-extension.json manifest might look like this:

{
  "name": "my-internal-tool-integration",
  "version": "1.0.0",
  "description": "Integrates Claude Code with our internal Jira and documentation server.",

  "mcpServers": {
    "internal-jira": {
      "command": "npx @my-company/jira-mcp-server --api-key ${JIRA_API_KEY}"
    }
  },

  "contextFiles": [
    "./jira-instructions.md"
  ],

  "permissions": {
    "allow": [
      "mcp__internal-jira__create_ticket",
      "mcp__internal-jira__get_ticket_status"
    ],
    "deny": [
      "mcp__internal-jira__delete_project"
    ]
  }
}

When Claude Code starts, it would discover these extensions and merge their configurations into its main configuration, following a clear precedence order (e.g., project settings > extension settings).

What are the benefits of this feature?

• Modularity: Encapsulates all related functionality for a specific integration into a single, self-contained unit.
• Shareability: Teams can check extensions directly into their repositories. A developer only needs to git pull to get the latest tools and configurations, dramatically simplifying setup.
• Simplified Management: Updating an integration becomes a matter of updating the extension files, rather than tracking changes across multiple configuration files.
• Discoverability: A command like /extensions could list all active extensions, improving user awareness of the tools available to them.
• Ecosystem Growth: This would create a clear standard for the community and internal teams to build and distribute "plugins" for Claude Code, enhancing its value and adaptability.

This system would build upon the excellent extensibility already present in Claude Code, making it even more powerful and manageable for both individual developers and large teams.

Thank you for considering this proposal