[FEATURE] Open source Claude Code CLI #22002

Preflight Checklist

• I have searched existing requests and this feature hasn't been requested yet
• This is a single feature request (not multiple features)

Problem Statement

Claude Code CLI is currently closed-source, while the main competitors (OpenAI Codex CLI, Google Gemini CLI) are open-source under Apache 2.0.

This creates several challenges:

1. Issue burden without community contribution: There are currently 5,600+ open issues, but the community cannot contribute fixes via pull requests. Maintainers bear the full cost of triaging and fixing, without the benefit of community contributions.

2. Limited extensibility: While MCP provides extension points, users cannot fix bugs, add features, or customize behavior at the core level.

3. Transparency expectations: Many users discover this repository expecting source code (see Did someone delete the codebase? #333, Mismatch between this repo and the NPM page for this product. #1645, Empty repo for a proprietary product? #1789, [DOCS] Admit that claude-code isn't open source. #19073), leading to confusion and frustration.

I understand that in March 2025, the team mentioned they weren't ready to be "good public stewards yet" (#59). Nearly a year has passed, and I'd like to respectfully ask whether the situation has changed.

Proposed Solution

Release Claude Code CLI under a permissive open-source license (e.g., Apache 2.0, MIT).

This would enable:

1. Community bug fixes: Users who encounter bugs can submit PRs instead of just filing issues. Maintainers review and merge, rather than investigating and implementing from scratch.

2. Reduced triage burden: Users who need a fix urgently can fork and fix locally, reducing pressure on the official issue queue.

3. Ecosystem growth: Third-party integrations, plugins, and forks can emerge, increasing Claude API adoption.

4. Competitive parity: Matching competitors' openness (Codex CLI, Gemini CLI are both Apache 2.0).

Alternative Solutions

• Status quo: Keep the CLI closed-source. This works, but leaves community contributions untapped.
• Partial open-sourcing: Release specific components (e.g., TUI layer, tool definitions) while keeping others closed. This is more complex but could be a middle ground.
• Source-available license: Release source for inspection without full OSS freedoms. Provides transparency without full contribution model.

Priority

Medium - Would be very helpful

Feature Category

Other

Use Case Example

Current state:

1. User encounters a bug (e.g., edge case in file editing)
2. User files an issue with reproduction steps
3. Issue joins 5,600+ open issues
4. User waits for official fix, or works around the issue

With OSS:

1. User encounters a bug
2. User investigates the source, identifies the cause
3. User submits a PR with a fix
4. Maintainers review and merge (or provide feedback)
5. Bug is fixed faster, with less maintainer effort

Additional Context

Related Issues

• open source? #59 - Original "open source?" question (2025-02-25), with team response
• [DOCS] Open Source Licensing #8517 - Open source licensing concerns (MIT/Apache dependencies)
• [BUG] Consider permissive license for devcontainer configs #11207 - Request for permissive license on devcontainer configs
• Did someone delete the codebase? #333, Mismatch between this repo and the NPM page for this product. #1645, Empty repo for a proprietary product? #1789, [DOCS] Admit that claude-code isn't open source. #19073 - User confusion about repository purpose

Competitor Comparison

Community Contribution Precedent

From #59, @FeepingCreature noted:

"Gptme has 224 closed pull requests. Aider has 400 closed pull requests. Dozens to hundreds of people are standing by to help you improve this tool at no cost but review."

✍️ Author: Claude Code (Dev Container) with @carrotRakko

Note: This issue was written and submitted by an AI agent (Claude Code), with human review and approval.