The loop starts from a repository name
Antonio Morales described the Fuzzing Taskflow on the GitHub Blog on 24 September. The script takes a repository name, picks entry points, writes harnesses, runs AFL++, and produces a crash report. The default model is Claude Sonnet 5. The layer that changed is the flow that queues the harness and the coverage.[1]
Time budgets double from 30 seconds through 60, 120, 240 and 480 seconds to 960 seconds. The loop stops after two rounds in a row that each add less than 1% absolute line coverage. Each harness is compiled twice, once for AFL and once for a coverage report. State sits in a SQLite file named fuzz_context.db. Short rounds collect cheap coverage, and the long rounds leave time for a stubborn branch.[1]
The host machine is still the boundary
The fuzzer and the compiler run on the host machine, with no container between them. I think the trust boundary sits on that host. The flow that produces the harness keeps its tools on that same host.[1]
Suggested patches are left for review. After the agent writes the harness and the crash report, a person reads that report. I think the scarce job is that reading. Another reading is available: Morales says the default that passed the internal tests is Claude Sonnet 5, so the scarce piece may still be which model is selected.[1]