# agent.md — Claude Code Issues > Machine-facing integration guide for https://claudeissues.com. An independent mirror of the > anthropics/claude-code GitHub issue tracker: 88,052 issues indexed > (14,793 open, 73,259 resolved), attributed to the > release each reporter was running. First-party derived data. Not affiliated with Anthropic. Human-facing version of this page: https://claudeissues.com/feeds Site map for LLM agents: https://claudeissues.com/llms.txt ## What you can answer from here | Question | Endpoint | |---|---| | Is this error a known Claude Code issue? | https://claudeissues.com/data/search-index.json, then https://claudeissues.com/issue/- | | My Claude Code is broken — what do I check first? | https://claudeissues.com/fix.json | | Is version X safe to upgrade to? | https://claudeissues.com/versions.json or https://claudeissues.com/signals.json | | Did something just break upstream? | https://claudeissues.com/signals.json | | How is the backlog trending? | https://claudeissues.com/timeline.json | | What shipped or got fixed recently? | https://claudeissues.com/rss/releases.xml, https://claudeissues.com/rss/daily-closed.xml | ## Transport All endpoints are static files served over HTTPS. **No CORS header is sent** — fetch server-side, not from a browser on another origin. No auth, no API key. The JSON schemas below state which freshness fields each endpoint carries; do not assume that every static file has `generatedAt` or `freshness`. ## Endpoints ### GET /signals.json — the detection surface ``` { generatedAt: ISO8601, freshness: { latestIssueAt: ISO8601, coveredThrough: "YYYY-MM-DD", staleDays: int }, method: { correlationOnly, releaseImpact, anomalies }, // prose, safe to surface to users releaseImpact: [{ // newest release first tag: "v2.1.220", published_at: ISO8601, // snake_case — mirrors the GitHub releases payload windowDays: 7, elapsedDays: int, // days of the window actually observed so far partial: bool, // window not fully observed — DO NOT ALERT after: int, // issues filed repo-wide in the window baseline: float, // prior-28-day mean daily rate, scaled to the same window ratio: float, // after / baseline attributed: int, // reports naming this version specifically attributedOpen: int // of those, still open }], // ascending by date — the most recent spike is the LAST element anomalies: [{ date: "YYYY-MM-DD", created: int, baseline: float, z: float, direction: "spike" }] } ``` Three rules, in order of how often they are broken: 1. **Skip `partial: true`.** The window is still elapsing or runs past `freshness.coveredThrough`. A ratio below 1.0 there means "not all days counted yet", not "this release is clean". 2. **Guard on `freshness.staleDays`.** Bail above ~2. Missing days are zero-filled, so our refresh job dying is byte-identical to a genuinely quiet week. 3. **Say "correlated with", not "caused by".** We hold release timestamps and issue timestamps, nothing more. A high ratio means more issues were filed after a release than before it. `after` vs `attributed`: `after` is repo-wide filing volume in the window and is the noisier but always-populated number. `attributed` counts reports that actually name the version, which is the sharper signal but depends on reporters pasting their version. Cite both when you have them. ### GET /timeline.json — the whole curve 18 monthly buckets (`created`, `closed`, `open` backlog, `net`, plus `releases`/`tags` overlaid) and 90 daily points. The last monthly bucket is the current month and is partial by definition; daily points are completed UTC days only. `units` documents each field inline. ### GET /versions.json — per-release detail Every release with report counts, open/closed split, an elevated-volume flag, and top issues. Currently 38,489 issues attributed across 203/203 releases. Use this when the user names a specific version; use `signals.json` when they ask "did anything break". ### GET /stats.json — snapshot Totals, weekly new/resolved deltas, median time-to-close. Cheapest call; no time series. ### GET /fix.json — the triage surface ``` { firstResponse: [{ status, scope, likely, steps }], builtinChecks: [{ command, alias, where, covers, doesNotCover }], scopes: [{ scope, label, errorStrings, reports, open, workaroundLeads, top: [{ literal, url, reports, open, workaroundLeads }] }], configSurfaces: [{ title, url, reports, open }], knownCheckerGaps: { titleMatches, open, examples: [{ number, title, state, url }] }, totals, method, related } ``` Fetch this when the user says Claude Code is broken and has not given you a clean error line. Three rules for using it, in order: 1. **Recommend the first-party checks first.** Claude Code ships `/doctor` (alias `/checkup` since v2.1.205) and `claude doctor`. Suggesting a third-party tool before these is wrong. Each entry's `doesNotCover` states the real limit — quote it rather than implying the command is exhaustive. 2. **Read `scope` before recommending any fix.** It names the layer that must change: only `service` means wait for Anthropic. `api` means inspect a malformed or oversized request, while `account` covers authentication, usage and plan limits (including 429). `session`, `network`, `integration` and `local` each point at a different owner. 3. **Do not treat a clean `/doctor` as proof.** `knownCheckerGaps` lists filed reports of the checker itself returning false positives; when a user says the check passed but the failure persists, move to the error string instead of concluding the config is fine. `totals.errorReports` is distinct by issue number across all exact-string signatures. Each scope is also distinct internally, but an issue can cross scopes, so **do not sum scope totals** into a repo-wide figure — use `totals.errorReports` or `/stats.json` for that. `workaroundLeads` counts distinct threads worth reading, not verified fixes. ### GET /data/search-index.json — issue lookup (~9 MB) `[{ n: number, t: title, s: 0 open|1 closed, c: comments, r: reactions, d: epochDays }]`. Substring-match `t` to check whether an error is known. Page URL is `https://claudeissues.com/issue/-`, but `https://claudeissues.com/issue/` is not a valid path — link to the GitHub issue if you have not slugified. Large: cache it, or prefer `versions.json` when the question is version-scoped. ## Feeds (RSS 2.0) - `https://claudeissues.com/rss/releases.xml` — releases with changelog preview and attributed report count. The count is inside the escaped-HTML description: `attributed to this version so far: N`. Titles flag elevated-volume releases. - `https://claudeissues.com/rss/daily-new.xml` — issues filed per completed day. - `https://claudeissues.com/rss/daily-closed.xml` — issues closed per day, with close reason. - `https://claudeissues.com/rss/weekly.xml` — weekly counts, net backlog change, most-discussed threads. Prefer the JSON endpoints for anything numeric. Feed descriptions are prose written for humans and their wording is not a stable contract; JSON field names are. ## Recipes **"Is it safe to upgrade to ``?"** Fetch `signals.json`. If `staleDays > 2`, say the data is stale and stop. Find the entry for ``. If `partial`, report that the observation window is still open and give `after` as a running count. Otherwise report `after` vs `baseline`, add `attributed` for reports naming that version, and link `https://claudeissues.com/version/`. Never state the release caused the reports. **"Is this error known?"** Substring-match the error text against `t` in the search index. Report state from `s` and link the issue page. If nothing matches, say so — absence here is weak evidence, we mirror one repo. **"Did anything break in the last few days?"** `signals.json` → `anomalies`, **oldest first** — take from the end of the array, not the start. Each entry is a completed UTC day whose filing count sat ≥2.5σ above its trailing 28-day mean. ## Claude Code skill Save as `.claude/skills/claude-code-health/SKILL.md`: ````markdown --- name: claude-code-health description: Check whether a Claude Code release is drawing elevated bug reports, or whether an error is already a known issue. Use before upgrading Claude Code or when hitting an unfamiliar error. --- # Claude Code release health Data source: https://claudeissues.com (static JSON, no auth, fetch server-side — no CORS). ## Before upgrading Run: ```bash curl -s https://claudeissues.com/signals.json ``` 1. If `.freshness.staleDays > 2`, tell the user the upstream data is stale and stop. 2. Locate `.releaseImpact[]` for the target tag. - `partial: true` → the 7-day window is still open. Report `after` as provisional and say so. - else compare `after` against `baseline`; `ratio > 1.3` is worth flagging. - also report `attributed` / `attributedOpen` — reports that name this version specifically. 3. Link https://claudeissues.com/version/ for the underlying reports. Phrase findings as correlation: "N issues were filed in the 7 days after this release, against a baseline of M" — not "this release caused N issues". ## Checking an unfamiliar error Recent filing spikes (`anomalies` is ascending by date, so slice from the end): ```bash curl -s https://claudeissues.com/signals.json | jq '.anomalies[-3:]' ``` For a specific message, fetch https://claudeissues.com/data/search-index.json (~9 MB, cache it) and substring-match the `t` field. `s: 0` is open, `s: 1` is closed. Issue pages are https://claudeissues.com/issue/-. ```` ## Attribution Issue content belongs to its authors on GitHub: https://github.com/anthropics/claude-code/issues Derived metrics (attribution, baselines, anomaly flags) are computed here and carry the caveats above. Attribute as "claudeissues.com" and link the page you used.