[BUG] claude-code-assisted PR label never written — 4.5 months, 0 labels while analytics detects 23 PRs in last 7 days

Status Open
Reported on v2.1.224
Maintainer reply None cached
Activity 1 comment · opened Aug 7, 2026

Follow-up to #69141 (auto-closed as stale on 2026-07-29 without triage) and #35167 (auto-closed and locked before resolution). Re-verified from scratch on 2026-08-07 with fresh evidence, including PRs merged after #69141 was closed.

Symptom (unchanged): the claude-code-assisted label is never written to merged PRs, while Claude Code analytics detects those same PRs normally. Detection works; the GitHub label write-back does not.

The asymmetry, measured two independent ways

| Source | Result |
| --- | --- |
| claude.ai/analytics/claude-code, August 2026 alone | 23 PRs with Claude Code across our projects (15 mine) |
| GitHub, all time, all repos, all orgs I'm involved in | 0 PRs labeled claude-code-assisted |

Detailed audit of one repo (created 2026-06-29, 52 merged PRs):

  • 27 of 52 merged PRs contain at least one commit with the Co-Authored-By: Claude trailer
  • 0 of 52 merged PRs carry any label at all — not merely missing claude-code-assisted
  • No labeled timeline event has ever fired on any of them (checked per-PR via /issues/{n}/timeline)
  • Most recent Claude-authored PR merged 2026-08-06 — 8 days after #69141 was closed for inactivity, so this is current, not historical

Org-wide:

  • The claude-code-assisted label does not exist in any of our repositories (GET /repos/{owner}/{repo}/labels, paginated — zero labels matching claude)
  • org:<our-org> label:claude-code-assisted0 results
  • Broadened to label:claude-code-assisted involves:<my-user>0 results. The label has never been written anywhere I'm involved, in any org.

Note the two counts use different methods — analytics matches lines against session activity, while my 27/52 keys off the commit trailer — yet they land in the same range. They corroborate rather than conflict.

Every documented precondition is met

Checked against https://code.claude.com/docs/en/analytics#pr-attribution:

| Docs requirement | Our state |
| --- | --- |
| Claude GitHub app installed on the org | ✅ since 2026-03-25, repository_selection: "all", suspended_at: null, install record updated_at: 2026-08-05 |
| App subscribed to pull_request | ✅ events include pull_request, pull_request_review, push, issues, … |
| App can write labels | ✅ granted permissions include pull_requests: write and issues: write |
| Claude Code analytics enabled | ✅ dashboard populated |
| "GitHub analytics" toggle enabled | ✅ proven — contribution metrics render with real PR counts |
| Not a Zero Data Retention org | ✅ ZDR would disable contribution metrics entirely per the docs; ours work |
| PRs merged, not open | ✅ all 52 merged |
| Within the 21-days-before / 2-days-after attribution window | ✅ moot — most PRs are weeks to months past merge |

This rules out the permissions explanation, the app-not-installed explanation, the ZDR explanation, and the timing explanation. The docs' only troubleshooting hints — "GitHub app required" and "Data processing in progress" — are both dashboard-side messages, and we see neither. There is no documented way to trigger, retry, or backfill a missing label, and no troubleshooting entry for one.

The docs still promise this behaviour, and now depend on it more

I diffed the live docs against Wayback snapshots from 2026-06-16 (the day before #69141 was filed) and 2026-08-05. This sentence is byte-identical in all three, under PR attribution → Attribution process:

Merged pull requests containing Claude Code-assisted lines are labeled as claude-code-assisted in GitHub.

Stated as plain present-tense behaviour: no opt-in, no separate toggle, no "coming soon", no caveat of its own.

The companion mention under Access data programmatically was reworded in the meantime. June 2026:

To query this data through GitHub, search for PRs labeled with claude-code-assisted.

Current:

To query contribution data through GitHub instead, search for PRs labeled with claude-code-assisted.

That "instead" now follows directly after "The API is not available on the Teams plan." — so the label is documented as the fallback query path for Teams-plan orgs that cannot use the Enterprise Analytics API. That path returns zero results for us.

I'm aware contribution metrics are marked public beta overall. The labeling sentence carries no beta qualifier of its own, and it sits in the same section as attribution logic that demonstrably works — the analytics numbers above are produced by exactly that pipeline.

Steps to reproduce

  1. Install the Claude GitHub app on a GitHub org; enable Claude Code analytics and the GitHub analytics toggle.
  2. Use Claude Code to make changes; commit, push, open a PR, merge it.
  3. Confirm the PR appears in claude.ai/analytics/claude-code under "PRs with CC" — it does.
  4. Check the merged PR on GitHub — no claude-code-assisted label. Check the repo's label list — the label was never created.
  5. Search org:<your-org> label:claude-code-assisted — 0 results.

What's new versus #69141

  • Third independent org showing the identical symptom (#35167 was a different org again)
  • 4.5 months since app install with the label never applied once, across 6 repositories
  • PRs merged after #69141's stale-closure still unlabeled, so the auto-close did not coincide with a fix
  • Confirmed the app holds pull_requests: write — the obvious permissions hypothesis is eliminated
  • Confirmed via archived snapshots that the docs claim is current and load-bearing, not stale text awaiting cleanup

Ask

Either fix the label write-back, or correct the two places in the docs that promise it — the second of which is presented as the only GitHub-side query path for Teams-plan orgs.

Environment

  • Claude Code 2.1.224
  • GitHub Cloud, org-level app install (app_slug: claude)
  • Verified with gh 2.88.1 against the GitHub REST API on 2026-08-07

<!-- issue-watch:last-verified -->
---
Still reproducing as of 24 August 2026 (re-verified on Claude Code 2.1.233).

View original on GitHub ↗

This issue has 1 comment on GitHub. Read the full discussion on GitHub ↗