Six Claude Code skills cover the interactive security loop
The repository starts with guided work that a security engineer can inspect as it happens. Its Claude Code skills create a threat model, scan source, triage findings, draft patches, and customize the pipeline. The static path reads and writes files without building the target. It produces named Markdown and JSON artifacts, which makes the handoff between stages visible and gives a team something concrete to review or integrate into an existing case system.
That path has a deliberate limit. The README says static findings on ordinary targets can contain more false positives because no candidate is built or executed. A canary fixture exists to demonstrate confirmation and deduplication, but a planted vulnerable file can also be dismissed as test code. The useful lesson is procedural: define exposure first, preserve evidence, and keep triage separate from discovery. The skills help enforce that order; they do not turn model output into a confirmed vulnerability.
The autonomous path uses 7 stages and a gVisor boundary
The full pipeline builds a C or C++ target with ASAN, maps attack surfaces, runs parallel find agents, verifies each crash in a clean container, deduplicates it, writes an exploitability report, and grades a proposed patch. A crash must reproduce 3 out of 3 times before it advances. Only the proof-of-concept input crosses from the finding agent to the separate verifier, reducing the chance that hidden workspace changes manufacture a result.
Autonomous agents execute target code, so the launcher requires a gVisor sandbox unless the operator overrides the check. Setup builds agent images and restricts outbound traffic to the Claude API. Target directories are still trusted executable configuration: they define images, build commands, test commands, and harness behavior. A safe deployment must review those files, limit mounted paths, protect host credentials, and keep the egress allowlist narrow.
What happened when we ran it
Our sandbox installed 35 Python packages in 18 seconds and used 39 MB. The build then passed in 8 seconds. Pytest ran for 20 seconds and exited with code 1: 411 tests passed, 14 failed, 5 were skipped, and 1 hit a collection or setup error out of 426. Pip-audit found 0 known vulnerabilities in the installed Python dependencies.
The failure tail was consistent. Fourteen test_patch_grade cases raised FileNotFoundError: [Errno 2] No such file or directory: 'docker', and tests/test_patch_grade_e2e.py failed during setup for the same reason. Our unprivileged container did not provide Docker. The log does not show a Python assertion or grading mismatch behind those cases, but absence of Docker is still a real setup failure for a project whose dynamic verification depends on containers.
The reference is small, while each target carries the hard work
The checkout was 1.7 MB with 161 files and roughly 14,975 source lines. It had a tests directory, no root Dockerfile, and 0 CI workflow files. Its installation added only 35 packages. Those figures make the harness code readable enough to study, but operational cost moves into target images, sanitizers, repeated model calls, result storage, and the engineering needed to define a trustworthy crash signal.
The supplied reference uses ASAN for C and C++ memory errors. Porting it means deciding what counts as a finding, what proof of concept the verifier receives, and how the target builds and runs. An HTTP request sequence might replace a crashing file; an exception or canary write might replace an ASAN signature. Those choices determine whether the system verifies the vulnerability you care about or rewards an agent for producing an unrelated failure.
Claude access and source handling need a written policy
A run needs access to Claude through an Anthropic API key, a Claude Code OAuth token, or supported Bedrock, Vertex, or Azure configuration. The sandbox's egress policy controls where agent traffic can go, but the model still needs enough code and runtime evidence to perform its task. Security teams should decide which repositories may be processed by each provider route, how transcripts and findings are retained, and who can approve patches.
The /patch skill is safer on static artifacts because it only reads and writes files. When given pipeline results, it executes target code to grade the fix and therefore returns to the gVisor boundary. Even after a patch passes its ladder, the README warns that verified patches are not always suitable for upstreaming. Ownership, regression risk, disclosure, and business severity remain human decisions.
The repository is explicitly unmaintained despite recent GitHub activity
GitHub reported 7,365 stars, 23 combined open issues and pull requests, and a last push on August 6, 2026. No latest release endpoint existed. Several open pull requests from July propose fixes to sandbox parsing, target supply-chain controls, argument construction, and artifact validation. That activity does not override the first-page policy: Anthropic says the repository is not maintained and will not accept contributions.
This makes the harness useful architecture and risky infrastructure. Copy its separation of threat modeling, finding, independent verification, deduplication, and patch grading. Keep the gVisor refusal and restricted egress. Then own a fork, dependency updates, tests, model changes, and target definitions as an internal security system. A team unwilling to take that maintenance burden should use a supported scanner or Anthropic's managed product instead.