sashiko

Sashiko

Sashiko (刺し子, literally "little stabs") is a form of decorative reinforcement stitching from Japan. Originally used to reinforce points of wear or to repair worn places or tears with patches, here it represents our mission to reinforce the Linux kernel through automated, intelligent patch review.

Sashiko is an agentic Linux kernel code review system. It uses a set of Linux kernel-specific prompts and a special protocol to review proposed Linux kernel changes. Sashiko can ingest patches from mailing lists or local git. It's fully self contained (doesn't use any external agentic cli tools) and can work with various LLM providers.

If you are a kernel maintainer, please see our Guide for Kernel Maintainers for information on interacting with Sashiko.

Quality of reviews

Sashiko is not perfect, but in our measurements the quality of reviews is high: in our tests sashiko was able to find 53.6% (with Gemini 3.1 Pro) of bugs based on unfiltered last 1000 upstream commits with Fixed: tags. In some sense, it's already above the human level given that 100% of these bugs made it through human-driven code reviews and were accepted to the main tree. The rate of false positives is harder to measure, but based on limited manual reviews it's well within 20% range and the majority of it is a gray zone.

Please, note that as with any other LLM-based tools, Sashiko's output is probabilistic: it might find or not find bugs (or find other bugs) with the same input.

Features

• Automated Ingestion: Monitors mailing lists (lore.kernel.org), GitHub PRs, and GitLab MRs for new patch submissions.
• Manual Ingestion: Can ingest patches from local git repositories or specific PRs/MRs.
• Forge Integration (Experimental): Automatic PR/MR review via GitHub and GitLab webhooks. This feature is unofficial and unsupported — use at your own risk.
• Self-contained: Doesn't depend on 3rd-party tools and works with multiple LLM providers (Gemini, Claude, GitHub Copilot CLI and goose are currently supported).
• Web interface and CLI: Provides a web interface for monitoring and a CLI tool for local development. Email support will be added soon.

Prompts

Sashiko uses a multi-stage review protocol to evaluate patches thoroughly from multiple perspectives, mimicking a team of specialized reviewers.

Review Stages

Stages are identified by name. The analysis stages run in parallel; the consolidation stages then run in sequence over what they produced.

Analysis stages. goal, implementation and execution-flow always run. The planning stage decides which of the rest a patch warrants, and --stages overrides that choice by name.

• goal -- the big picture: architectural flaws, UAPI breakages, and conceptual correctness.
• implementation -- whether the code matches the commit message's claims, checking for missing pieces, undocumented side-effects, and API contract violations.
• execution-flow -- traces C code execution, checking for logic errors, missing return checks, unhandled error paths, and off-by-one errors.
• resources -- memory leaks, use-after-free (UAF), double frees, and object lifecycles across queues, timers, and workqueues.
• locking -- concurrency issues, deadlocks, RCU rule violations, and thread-safety.
• security -- buffer overflows, OOB reads/writes, TOCTOU races, and information leaks (like copying uninitialized memory).
• hardware -- driver and hardware code: register accesses, DMA mapping, memory barriers, and state machine constraints.

Consolidation stages, in order:

• deduplication -- consolidates feedback from the analysis stages, merges duplicates, and groups overlapping issues.
• conflict-resolution -- compares consolidated concerns against consolidated dismissed concerns and keeps only concerns that survive concrete code-based conflict checks.
• verification -- validates the remaining concerns, filters false positives, and estimates severity.
• report -- converts confirmed findings into a polite, standard, inline-commented LKML email reply.

Also Sashiko is using per-subsystem and generic prompts, initially developed by Chris Mason:

• review-prompts

Important Disclaimers

Before using Sashiko, please be aware of the following:

1. Data Privacy and Code Sharing

Sashiko operates by sending patch data and potentially extensive portions of the Linux kernel git history to your configured Large Language Model (LLM) provider.

• What is shared: This may include not just the patch being reviewed, but also related commits, file contents, and other context from the configured kernel repository to provide the LLM with sufficient context.
• Your responsibility: You must ensure you are authorized and comfortable sharing this code and data with the third-party LLM provider.
• Liability: The authors of Sashiko assume no responsibility for any consequences regarding data privacy, confidentiality, or intellectual property rights resulting from the transmission of this data.

2. Operational Costs

Running an automated review system like Sashiko can be computationally expensive and may incur significant API costs.

• Cost factors: The total cost depends heavily on the volume of patches reviewed, the complexity of individual patches, and the pricing model of your chosen LLM provider and specific model.
• Monitoring: It is the user's sole responsibility to monitor token usage and billing. While Sashiko may provide usage estimates, these are approximations and should not be relied upon for billing purposes.
• Liability: The authors of Sashiko are not responsible for any financial costs, fees, or unexpected charges incurred by the use of this software.

Prerequisites

• Rust: Version 1.90 or later.
• Git: For managing the repository and kernel tree.
• LLM Provider API Key: Access to an LLM provider (e.g., Google's Gemini or Anthropic's Claude).

Installation

From crates.io

cargo install sashiko

From source

1. Clone the repository:

git clone --recursive https://github.com/sashiko-dev/sashiko.git
cd sashiko

Note: The --recursive flag is important to initialize the linux kernel source submodule.

2. Configuration:

Copy Settings.toml to customize your configuration. For a full reference of every setting, see the Configuration Reference. The default Settings.toml includes sections for:

• Database: SQLite database path (sashiko.db).
• NNTP: Server details and groups to monitor.
• AI: Provider and model selection.
• Server: API server host and port.
• Git: Path to the reference kernel repository.
• Review: Concurrency and worktree settings.
• Forge (Experimental): GitHub/GitLab webhook integration (optional, unsupported). See forge setup guides below. * When enabling [forge], the NNTP (mailing list) ingestor is disabled by default. If you need to monitor both, set disable_nntp = false in the [forge] section of your config.
• Subsystems: Map file patterns to subsystems for targeted reviews (optional). Works with both mailing lists (recipient matching) and git forges (file path matching).

Configuring the LLM Provider

Sashiko supports multiple LLM providers. To get started with the default (Gemini):

cp docs/examples/Settings.example.toml Settings.toml
export LLM_API_KEY="your-api-key-here"

When installed with cargo install, create the user config with:

sashiko init

This writes ~/.config/sashiko.toml by default. Use sashiko init --print to print the template or sashiko init --path to choose a different location.

For Claude, Claude Code CLI, GitHub Copilot CLI, AWS Bedrock, Vertex AI, Kiro CLI, Devin CLI, goose, and OpenAI-compatible endpoints, see the LLM Provider Configuration Guide.

3. Build:

cargo build --release

Usage

Sashiko requires a configuration file to run (usually ~/.config/sashiko.toml or ./Settings.toml). You can initialize a default configuration with:

sashiko init

Sashiko can be run in two modes: Local Review (standalone, no daemon required) or as a Daemon (for automated monitoring, web UI, and team integration).

1. Local Review (Recommended)

Sashiko can review your patches locally without starting the daemon, sending emails, or updating the database.

Run it from the Linux source checkout containing the commits to review:

# Review the latest commit
sashiko review

# Review a range of commits
sashiko review HEAD~3..HEAD

This mode:

• Does not start the daemon or open the Sashiko database.
• Does not fetch or configure git remotes.
• Uses a temporary scratch clone for patch application, leaving your source checkout and its git metadata untouched.

For local review, Sashiko loads settings from ./Settings.toml if it exists in the current directory, otherwise from ~/.config/sashiko.toml. Use --settings to point to a specific settings file.

2. Daemon Mode

The daemon is responsible for monitoring mailing lists (NNTP), managing the database, and coordinating the AI review process. It also provides a Web UI and an API.

To start the daemon:

sashiko

(Or from source: cargo run, or via Nix: nix run github:sashiko-dev/sashiko)

Web Interface

Once the daemon is running, you can access the Web UI. The daemon will print the URL to access it from localhost.

3. CLI (Interacting with the Daemon)

The CLI tool sashiko-cli allows you to interact with a running Sashiko daemon.

# Submit patches to the running daemon
sashiko-cli submit HEAD~3..HEAD

# Check review status
sashiko-cli show latest

(From source: cargo run --bin sashiko-cli -- [OPTIONS] [COMMAND], or via Nix: nix profile add github:sashiko-dev/sashiko)

For the full command reference, see the CLI Reference.

Benchmarking

Sashiko includes a benchmark tool to evaluate review quality against known bugs. See the Benchmarking Guide for setup and usage.

Security & Data Privacy

Sashiko implements stateless JWT-based authorization and login via sign-in links. API mutations are strictly controlled by a fine-grained, capability-based Access Control List (ACL) configured in Settings.toml ([server.acl]). Administrators assign user identities directly to specific capability arrays (ingest, cancel, review), adhering strictly to the principle of least privilege. Two further arrays cover the Linux kernel bug tracker: security lists the kernel security list, whose members read and comment on every bug and read the raw AI transcripts without gaining any other capability, and bug_reporters lists the principals permitted to file a bug over HTTP, which ships empty so that only admins can. Authority over an individual bug is not a capability array: it is resolved per request from MAINTAINERS, so a maintainer reaches exactly the bugs filed against the subsystems they are listed for. In addition, an explicit blocklist array denies access unconditionally, taking precedence over every capability, over admin rights and over every bypass. If the ACL configuration is omitted or the arrays are empty, the server transparently falls back to a completely secure, "Fail-Closed" mode where no remote mutations are permitted. The server operates without persistent traditional user accounts and retains no user data aside from the explicit comments, actions, and review history metadata submitted directly onto the hosted bugs.

Communication

We welcome contributions and feedback through two main channels:

• GitHub: Feel free to use GitHub issues for bug reports and feature requests, and submit Pull Requests for c