Code audit reports generated by Claude Code for open-source projects.
One page per project with the static audit, confirmed bug hunts, measured optimizations and fuzz crashes - filterable and sortable, with links to the raw files in this repo.
Each report was produced by a multi-agent static analysis pass over the full source tree, looking for bugs, panics, logic errors, performance issues, dead code, and architectural problems.
You can also download a single .html file from reports/ and open it in any web browser.
Help open-source maintainers find and fix real bugs - especially panics, logic errors, and other issues that are hard to spot during normal code review.
It contains some false positives, but also catches a large number of real problems.
You have two paths to help the open-source ecosystem:
- Validate findings and open issues for confirmed bugs in the project's repo
- Open pull requests for issues you have validated as correctly reported bugs
Some issues carry an "Easy" label, meaning the fix should be straightforward - a good place to start. For example, in the Wine codebase there is a bug that survived for 2 years unnoticed (many older bugs stay hidden from maintainers' view):
### CPY_36 `MEDIUM`
**Description:** In video_mixer_collect_output_types the output media-type height is computed from the geometric aperture using OffsetX instead of OffsetY (both width and height add aperture.OffsetX.value). Output render-target heights are wrong whenever the aperture has a non-zero vertical offset.
**Locations:**
"""
dlls/evr/mixer.c:780-781
780 | width = aperture.OffsetX.value + aperture.Area.cx;
781 | height = aperture.OffsetX.value + aperture.Area.cy;
"""
**Fix:** Change line 781 to: height = aperture.OffsetY.value + aperture.Area.cy;
As you can see, the issue comes pre-verified with a suggested fix.
In case of fixing big group of issues, I can easily generate a new report, to clarify, which problems were fixed and which not
reports/ProjectName_YYYYMMDD.html
The date means when the report was generated.
A project normally keeps one file, the newest. A few older reports are kept
in the repo root instead of reports/, because they are linked to from outside this repo and those links
should not break - they are listed under keep in projects.toml, and both
scripts/find_reports.py and the refresh skill leave them alone.
Only the interactive HTML files are stored in reports/ (ProjectName_YYYYMMDD.html).
Each report has severity filters (critical / high / medium / low), type filters,
and a "Copy as GitHub Markdown" button on each finding for easy issue reporting.
Reports are refreshed against the projects' current code, so what you read is not just what was true on the audit date:
- every finding carries the exact code snippet it was written against, and a refresh re-clones the project and checks whether that block of code still exists (line shifts and reindentation do not count as a change);
- a finding whose main location changed - fixed, rewritten, or removed - is dropped; if only one of its secondary locations changed, that location is dropped and the finding stays;
- locations that merely moved are rewritten to where the code is today, so the line numbers and permalinks point at the current revision;
- the date in the file name is the date of the last refresh, and the commit the report was verified against is shown in the report header.
Findings are never re-judged during a refresh: a refresh answers "is this still
in the code", not "was this ever a real bug". projects.toml records the
repository, branch and first audit date per project.
The refresh itself is .claude/skills/refresh-reports/ (just refresh), which
re-renders each report with the current version of the report generator - that
is how old reports end up in the same format as new ones.
scripts/find_reports.py gathers the audit output into this repo. It recursively searches a
source folder for findings-interactive.html files (the output of the code-audit pass)
and copies each one into reports/ under the canonical ProjectName_YYYYMMDD.html name.
python3 scripts/find_reports.py <source-folder> # e.g. python3 scripts/find_reports.py ~/test
scripts/find_details.py gathers the supporting ___BUGHUNT___ / ___OPTIMIZATIONS___
workspaces behind those reports (per-candidate RESULT.md, patch.diff, repro/) into
investigations/.
How names are resolved:
- the project name is the directory that contains
___FINDINGS___(.../<Project>/___FINDINGS___/findings-interactive.html-><Project>), falling back to the file's own parent directory if there is no___FINDINGS___; - the date is the report file's modification time.
Per-project rules when copying:
- if an identical report is already here, it is left untouched (never overwritten);
- if only older version(s) exist, they are deleted and the newer report takes their place;
- if a newer version is already here, the older source report is skipped (no downgrade).
fuzz-targets/<name>/ holds the crashes found by rust-fuzzer (rfuzz) for each library: fuzz.toml, crashes.md and one folder per crash with a standalone reproducer (src/main.rs, Cargo.toml, Cargo.lock, README.md). Targets that were already reported upstream carry an empty REPORTED file.
Refresh from a local rust-fuzzer checkout (default ~/Projekty/Rust/rust-fuzzer, reads targets/ and targets_reported/):
python3 scripts/find_targets.py [path] [--dry-run]
Unchanged targets are skipped, changed ones are rewritten and targets that disappeared from the source are removed. assets/, work/ and rfuzz internals (trace.ron etc.) are not copied.