# Sashiko: an agentic reviewer for Linux kernel patches

> Sashiko is a Rust tool, developed under the Linux Foundation, that reviews Linux kernel patches with an LLM through parallel analysis stages and sequential verification, so a commit is checked for concurrency bugs, use-after-free, UAPI breakage and register access in parallel. It runs locally against your checkout or as a daemon watching mailing lists and forges.

**sashiko-dev/sashiko** — Agentic review of Linux Kernel code changes

- Repository: https://github.com/sashiko-dev/sashiko
- Website: https://sashiko.dev
- Stars: 1,392 · Forks: 268
- Language: Rust
- License: Apache-2.0
- Published: 2026-10-19 · Updated: 2026-10-19 · Language: en
- Canonical page: https://hysenlabs.com/projects/sashiko-dev-sashiko

## The name, and the claim

Sashiko takes its name from the Japanese form of decorative reinforcement stitching, literally little stabs, originally used to reinforce points of wear or to repair torn places with patches, and the project maps that onto its mission of reinforcing the Linux kernel through automated, intelligent patch review. The substance is described as a self-contained, agentic Linux kernel code review system that uses kernel-specific prompts and a multi-stage verification protocol to review proposed changes, either locally from your git checkout or automatically from mailing lists at lore.kernel.org and from git forges. The project carries a Linux Foundation Project badge and is licensed under Apache 2.0 with the copyright held by the Linux Foundation and its contributors. Its audience is stated in the README's own structure, with a guide for kernel maintainers covering mailing list tracking, subsystem prompts and email policies, a mailing list for announcements and discussion, a press file collecting what maintainers and the media have said, and a note that Sashiko is exploring covering other open source projects beyond the kernel, with a request to get in touch with Roman Gushchin if you want to bring it to your project.

## Local review is four commands and one API key

The easiest way to use Sashiko is `sashiko review`, which reviews commits directly in your local Linux kernel checkout without running a daemon or a database. The setup has three steps. You install it, which requires Rust 1.90 or newer, Git and an LLM provider API key:

```bash
cargo install sashiko
```

You initialise a configuration file, which lives at ~/.config/sashiko.toml by default or ./Settings.toml in the working directory, and you export your key:

```bash
sashiko init
export LLM_API_KEY="your-api-key-here"
```

And then you review, from inside the checkout:

```bash
# Review the latest commit
sashiko review

# Review a range of commits (pass --report-preexisting to also report pre-existing bugs)
sashiko review HEAD~3..HEAD
sashiko review --report-preexisting
```

One implementation detail matters more than the rest. Local review uses a temporary scratch clone for patch application, leaving your working tree and your git metadata untouched, so you can run it on a dirty checkout without worrying about what it does to your state. Gemini is the default provider, and the configuration guide covers Claude, OpenAI-compatible endpoints, AWS Bedrock, Vertex AI, Claude Code CLI, GitHub Copilot CLI, Kiro CLI, Devin CLI and goose.

## The analysis stages, and what each one hunts for

Sashiko evaluates a patch through specialized parallel analysis stages followed by sequential consolidation stages, using per-subsystem prompts that were initially developed by Chris Mason. The analysis stages run in parallel, with goal, implementation and execution-flow always running while the planning stage selects the others, unless you override the list with --stages. Each stage is looking for a different class of defect, which is the point of splitting them. goal covers architectural flaws, UAPI breakages and conceptual correctness. implementation checks whether the code matches the commit message, undocumented side effects and API contract violations. execution-flow looks for logic errors, missing return checks, unhandled error paths and off-by-one errors. resources hunts memory leaks, use-after-free, double frees and object lifecycles across queues, timers and workqueues. locking covers concurrency issues, deadlocks, RCU rule violations and thread safety. security looks for buffer overflows, out of bounds reads and writes, TOCTOU races and uninitialized memory leaks. hardware checks register accesses, DMA mapping, memory barriers and state machine constraints. If you write kernel code, the useful part of that list is the vocabulary: it is a checklist of the failure modes that a reviewer of a kernel patch is expected to hold in their head.

## Consolidation, hard cases and the LKML report

The consolidation stages run in sequence, and they are where the model is asked to argue with itself. The verification stage consolidates concerns and dismissed concerns across the analysis stages, emits well-justified findings and dismissals directly, and routes contested or speculative candidates to a holding area called hard_cases. The post-verification stage then runs parallel per-finding verification stages, named post-verification-1 through post-verification-10, with repository tools available to validate or disprove the candidates in hard_cases. The final report stage formats the confirmed findings into a standard inline-commented LKML review report, which means the output is in the shape a kernel maintainer expects to read, with the comment attached to the line it concerns. The multi-stage structure is the main design claim of the project, and it is a sensible one: an LLM asked for a single verdict tends to be confidently wrong, while an LLM asked to find candidates and then asked to prove them is a different and more tractable task. Whether that holds in practice is what the published numbers are for.

## The measured numbers, and the caveat attached to them

The README publishes a quality section with concrete figures. In benchmarks against the last 1,000 unfiltered upstream commits with Fixes: tags, Sashiko with Gemini 3.1 Pro detected 53.6% of the bugs that had originally passed human review and been merged into mainline. Based on manual sampling, the false-positive rate is under 20%, mostly gray-area concerns. The project also states the obvious limitation of the approach, that as with any LLM-based tool the output is probabilistic and may vary across runs on the same input. Both numbers should be read with care. The benchmark set is filtered by Fixes tags, so it is a set of commits whose authors said they fixed something, which is a different population from all commits, and the 20% false positive rate is described as based on manual sampling rather than exhaustive review. Still, a tool that finds half of the bugs that human review merged is interesting, and the fact that the project publishes the false positive figure at all is a good sign about how the maintainers intend it to be used.

## What it costs and what leaves your machine

The README carries an important note under data privacy and API costs. Sashiko sends patch data and relevant surrounding files and history from your repository to your configured LLM provider, and you are told to ensure you are authorized to share that code with the provider and to monitor token usage and billing, because multi-stage reviews can incur significant API costs. The authors assume no liability for data transmission or API charges. For a kernel patch that is a small amount of code, the cost is manageable, but the surrounding history and files are what make the review useful, and that is also what makes it sensitive. Since a kernel checkout is a public repository, the confidentiality concern is low for upstream work, but the same tool pointed at an internal kernel fork raises different questions, and the vendor and legal questions are the ones to settle before a wide rollout. The provider list is broad enough that a team with a policy about which model may see its code can usually find a compliant path.

## Server mode, forge hooks, and one version inconsistency

Beyond the local workflow there is a server mode, documented in a file on running the daemon, which covers building from source, monitoring mailing lists over NNTP and monitoring forges, a web interface, the sashiko-cli tool for submitting patches and querying status on a running daemon, and server ACL security. The forge integration is marked experimental and covers webhook setup for GitHub and GitLab plus webhook security, and there is a CLI reference for sashiko-cli and a configuration reference for Settings.toml, email_policy.toml, Patchwork integration and environment variables. The Makefile shows the engineering discipline: a build target, an fmt target, a lint target that runs clippy with all targets and all features with warnings denied, then a format check and yamllint, a local clippy profile for the local-review feature set, unit and integration tests, and a check-pr target that runs fast diff-aware local checks over a RANGE that defaults to HEAD~1..HEAD. There is also a check-db-invariants target and a sob target that checks Signed-off-by tags, which matters because the contributing guide asks for DCO sign-off. One detail deserves a flag. The README says the install requires Rust 1.90 or newer, while the Dockerfile builds on rust:1.88-bookworm, so the container build and the stated requirement do not agree. The last push was on 2026-10-15, and the crate version in the manifest is 0.5.1 with no GitHub releases published.

## Conclusion

Adopt Sashiko if you are a Linux kernel subsystem maintainer or a developer sending patches upstream, and you want a second opinion that looks for concurrency, lifetime and API breakage issues before a human reviewer does. Do not adopt it as a general code reviewer for your own project, since the prompts are kernel-specific and the project is explicitly exploring other code bases only as an invitation. Before you run it, read the data privacy note, because patch data and surrounding repository history are sent to your configured LLM provider, and measure the token cost on a small range first, since the project reports that multi-stage reviews can incur significant API charges.

## FAQ

### What is Sashiko?

It is a self-contained, agentic Linux kernel code review system written in Rust, licensed under Apache 2.0 and developed under the Linux Foundation. It uses kernel-specific prompts and a multi-stage verification protocol to review proposed changes locally or automatically from mailing lists and git forges.

### How do I install and run Sashiko on my own commits?

Install it with `cargo install sashiko`, which needs Rust 1.90 or newer, Git and an LLM provider API key. Run `sashiko init` to create the configuration, export LLM_API_KEY, then run `sashiko review` inside your kernel checkout, or `sashiko review HEAD~3..HEAD` for a range. Local review uses a scratch clone and leaves your working tree untouched.

### Which LLM providers does Sashiko support?

Gemini is used by default, and the provider configuration guide covers Claude, OpenAI-compatible endpoints, AWS Bedrock, Vertex AI, and the Claude Code CLI, GitHub Copilot CLI, Kiro CLI, Devin CLI and goose. The Cargo features include bedrock and vertex for the cloud providers.

### What accuracy does the Sashiko project claim?

In benchmarks against the last 1,000 unfiltered upstream commits with Fixes: tags, Sashiko with Gemini 3.1 Pro detected 53.6% of bugs that had passed human review and been merged into mainline, with a false-positive rate under 20% based on manual sampling. The output is probabilistic and may vary between runs.

### What are the costs and privacy implications of running Sashiko?

Sashiko sends patch data and relevant surrounding files and history from your repository to your configured LLM provider, so you must be authorized to share that code and should monitor token usage and billing, since multi-stage reviews can incur significant API costs. The authors assume no liability for data transmission or API charges.

## Sources

- [Issues](https://github.com/sashiko-dev/sashiko/issues)
- [License: Apache-2.0](https://github.com/sashiko-dev/sashiko/blob/main/LICENSE)
- [Project website](https://sashiko.dev)
- [README](https://github.com/sashiko-dev/sashiko/blob/main/README.md)
- [sashiko-dev/sashiko on GitHub](https://github.com/sashiko-dev/sashiko)

---

Hysen Labs editorial analysis, written from the project's own repository and release notes. Cite the canonical page: https://hysenlabs.com/projects/sashiko-dev-sashiko