Claude Code: 문제 32,000개, 봇 종료율 49% – 버그 클러스터 수명 주기 1개

Claude Code Issue Tracker analysis Disclosure: This analysis was produced by Claude (Opus 4.6) in a Claude Code session. I asked the questions; Claude did the research, data gathering, and writing. Part 1 of 2 — see also: OpenCode vs Claude Code: Issue Tracker Comparison This analysis is based on publicly visible GitHub activity — issue comments, workflow files, and labels. It cannot account for internal issue tracking, private support channels, or fixes implemented without public discussion. Claude Code has ~6,000 open issues (3,554 labeled as bugs) and receives ~2,000–2,500 new issues per week. An estimated 49–71% of all closures are bot-driven (see methodology note). A deep dive into session rename/resume bugs reveals 12+ related issues spanning 2+ months, 70+ community comments, community-provided root cause analysis — and no visible staff engagement on those specific issues. A reported fix-then-regression went unacknowledged. A related consolidation issue (#27242, 45 thumbs-up) received one brief staff response but no follow-up. | Metric | Count | |---|---| | Repository age | ~13 months | | GitHub stars | 77,748 | | Total issues ever filed | 32,769 | | Currently open | ~5,978 | | Open bugs (labeled "bug") | 3,554 | | New issues per week (4-week avg) | ~2,003 | | Closed with duplicate label | 10,069 | | Closed with autoclose label | 5,502 | | Closed with stale label | 3,147 | | Closed with invalid label | 918 | | Bot-driven closures (est.) | 49–71% of all closures* | * See methodology note below for how this range was calculated. The question is not whether automation should exist at this scale, but why so much of it is visibly directed at classification and closure while so little is visibly directed at escalation and response. Before examining a specific bug, it's worth understanding a structural issue in the triage system that affects all bugs. The repo's public workflows (.github/workflows/ ) reveal a set of interacting bots: | Workflow | Model | Behavior | |---|---|---| claude-dedupe-issues.yml | Claude Sonnet 4.5 | Processes every new issue for duplicate detection. Posts "Found N possible duplicate issues" comment | auto-close-duplicates.yml | — | Daily sweep: auto-closes issues 3 days after the duplicate comment, unless the author thumbs-downed it | claude-issue-triage.yml | Claude Opus 4.6 | Labels every new issue (bug, needs-repro, needs-info, invalid, etc.). Does not comment | sweep.yml | — | Runs twice daily: marks issues stale after 14 days of inactivity, then closes them 14 days later | lock-closed-issues.yml | — | Locks closed issues after 7 days — no further comments allowed | issue-lifecycle-comment.yml | — | Posts timeout warnings when lifecycle labels are applied | These bots interact to create a self-reinforcing cycle for unfixed bugs: - User files a bug report with reproduction steps - Duplicate bot finds similar (also unfixed) issues, posts a duplicate comment - Auto-close bot closes the issue 3 days later - Lock bot locks it 7 days after closure — no further comments allowed - The bug persists. The user can't comment on the locked issue - User files a new issue - Duplicate bot finds the locked issue from step 3 as a match - Go to step 3 This cycle fragments community engagement across many issues, making it harder for any single report to accumulate enough visibility to trigger human review. Issues with 10+ thumbs-up are exempt from stale/autoclose, and authors can thumbs-down the duplicate comment to prevent auto-closure — but these escape hatches are not prominently documented. | Label | Timeout | Closures to date | |---|---|---| duplicate | 3 days | 10,069 | autoclose | 14 days | 5,502 | stale | 14 days (after 14 days inactive = 28 days total) | 3,147 | invalid | 3 days | 918 | needs-repro | 7 days | 11 | needs-info | 7 days | 15 | /rename stores the custom session title as a custom-title JSON line in the session JSONL file. The /resume picker uses a fast loader that only reads the last 16–64KB of the file. After a few conversation turns, the custom-title line gets pushed outside that tail window and silently disappears from the picker. This is part of a broader family of sessions-index.json bugs — at least 20 open issues track variants of the index falling out of sync with actual session files on disk. Community member @Astro-Han traced the exact code path in the compiled binary (v2.1.72): // uH8: reads head (first 64KB) + tail (last 64KB) of the JSONL let K = await R.read(q, 0, S3_, 0); // head — S3_ = 65536 let O = Math.max(0, T - S3_); // tail offset // ... // woK: searches for customTitle in TAIL only j = rg(K, "customTitle"); // if custom-title line is >64KB from end → gone Another user @rfaile313 found a 16KB window (BbR = 16384 ) in v2.1.39. Either way, 3–5 conversation rounds push the title out of range. Real-world verification: one user's session had the custom-title at byte offset 19,950,786 — but after 3 more rounds it was 253KB from the end, far beyond the 64KB read