[FEATURE] Open source Claude Code CLI

Status Open
Maintainer reply None cached
Activity 12 comments · opened Jan 30, 2026

Preflight Checklist

  • [x] I have searched existing requests and this feature hasn't been requested yet
  • [x] 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.
  1. Limited extensibility: While MCP provides extension points, users cannot fix bugs, add features, or customize behavior at the core level.
  1. Transparency expectations: Many users discover this repository expecting source code (see #333, #1645, #1789, #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.
  1. Reduced triage burden: Users who need a fix urgently can fork and fix locally, reducing pressure on the official issue queue.
  1. Ecosystem growth: Third-party integrations, plugins, and forks can emerge, increasing Claude API adoption.
  1. 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
  • #59 - Original "open source?" question (2025-02-25), with team response
  • #8517 - Open source licensing concerns (MIT/Apache dependencies)
  • #11207 - Request for permissive license on devcontainer configs
  • #333, #1645, #1789, #19073 - User confusion about repository purpose
Competitor Comparison

| CLI Tool | License | GitHub Stars | Open Issues |
|----------|---------|--------------|-------------|
| Claude Code | Proprietary | 62K | 5,600+ |
| OpenAI Codex CLI | Apache 2.0 | 58K | ~900 |
| Google Gemini CLI | Apache 2.0 | 93K | ~1,800 |

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.

View original on GitHub ↗

11 Comments

chall37 · 7 months ago

Seconded. The CLI has significant usability and reliability issues, and keeping it closed source limits both Anthropic’s ability to benefit from external contributions and the community’s ability to work around problems that directly affect them.

A few observations on the current approach:

  • Shipping minified/obfuscated JavaScript is unlikely to meaningfully protect proprietary logic. Anyone sufficiently motivated can reverse it, while legitimate users are prevented from inspecting behavior, debugging issues, or proposing fixes.
  • Obfuscation does not materially improve security. In practice, it makes independent diagnosis harder without preventing misuse.
  • Even when a user can identify a precise defect, they cannot file a useful bug report, because “function zD at offset 1842 has a logic error” is not stable across versions.
  • Users cannot safely apply a temporary local patch for the same reason.
  • Paying customers are fully dependent on Anthropic's internal roadmap and prioritization, which may not align with their operational needs (namely, running a CLI that doesn't crash).
  • The rapid release cycle frequently introduces breaking changes, which suggests insufficient testing. At the same time, rolling back to a known-less-worse version has become increasingly cumbersome with the move to native installers.
X-15 · 6 months ago

Trippled: support for Windows is horrendous via git bash, this needs lots of attention. I have to assume nobody at anthropic using cli on windows and therefore it will always suck.

cdr-x · 6 months ago

Yes! We need this to be open source ASAP. >;O what's wrong with anthropic that they had to make this closed source?

ferrouswheel · 5 months ago

Bumping this issue because otherwise the aggressive bot will lock it, like it did to one of the linked issues. So now I will make a pointless comment every few days to avoid this issue going stale or being locked.

ferrouswheel · 5 months ago

Bumping this issue because otherwise the aggressive bot will lock it, like it did to one of the linked issues. So now I will make a pointless comment every few days to avoid this issue going stale or being locked.

armujahid · 5 months ago

I was planning to add an "effort" level to the status line hook/event, but unfortunately found that this is closed source. There are numerous people requesting this feature, yet delivery is slow due to the closed-source nature of Claude Code.

ferrouswheel · 5 months ago

I was planning to explore the exact behavior of some environment variables, and wasted some time before I realized this was a dummy repo.

They could at least say what the repo purpose is instead of being misleading and repeatedly wasting community members' time which is what I asked for in #19073 before they closed it without answer.

AuguB · 5 months ago

They could bootstrap this by rewarding contributors with free credits

Echo-Nie · 5 months ago

As you wish

baslr · 5 months ago

maybe the leak of the source map was on purpose. to see what is possible to build.

devproof · 1 month ago

Claude Code is used by Antrophic Agent SDK which is MIT license. It pulls in Claude Code as a transitive dependency. There is a mismatch and I think it make the licenses incompatible.

Showing cached comments. Read the full discussion on GitHub ↗