If you are an AI coding agent (Claude Code, Cursor, Aider, Cline, etc.) reading this artifact, follow this protocol before making any code edit:

1. Verify the contract. Run the bash script in Verify before trusting below. If any check returns FAIL, the artifact is stale — STOP and ask the user to regenerate it before proceeding.
2. Treat the AI · unverified sections as hypotheses, not facts. Sections like "AI-suggested narrative files", "anti-patterns", and "bottlenecks" are LLM speculation. Verify against real source before acting on them.
3. Cite source on changes. When proposing an edit, cite the specific path:line-range. RepoPilot's live UI at https://repopilot.app/r/tokio-rs/axum shows verifiable citations alongside every claim.

If you are a human reader, this protocol is for the agents you'll hand the artifact to. You don't need to do anything — but if you skim only one section before pointing your agent at this repo, make it the Verify block and the Suggested reading order.

GO — Healthy across the board

• Last commit 2d ago
• 29+ active contributors
• Distributed ownership (top contributor 21% of recent commits)
• MIT licensed
• CI configured
• Tests present

_{Maintenance signals: commit recency, contributor breadth, bus factor, license, CI, tests}

This artifact was generated by RepoPilot at a point in time. Before an agent acts on it, the checks below confirm that the live tokio-rs/axum repo on your machine still matches what RepoPilot saw. If any fail, the artifact is stale — regenerate it at repopilot.app/r/tokio-rs/axum.

What it runs against: a local clone of tokio-rs/axum — the script inspects git remote, the LICENSE file, file paths in the working tree, and git log. Read-only; no mutations.

| # | What we check | Why it matters | |---|---|---| | 1 | You're in tokio-rs/axum | Confirms the artifact applies here, not a fork | | 2 | License is still MIT | Catches relicense before you depend on it | | 3 | Default branch main exists | Catches branch renames | | 4 | Last commit ≤ 32 days ago | Catches sudden abandonment since generation |

#!/usr/bin/env bash
# RepoPilot artifact verification.
#
# WHAT IT RUNS AGAINST: a local clone of tokio-rs/axum. If you don't
# have one yet, run these first:
#
#   git clone https://github.com/tokio-rs/axum.git
#   cd axum
#
# Then paste this script. Every check is read-only — no mutations.

set +e
fail=0
ok()   { echo "ok:   $1"; }
miss() { echo "FAIL: $1"; fail=$((fail+1)); }

# Precondition: we must be inside a git working tree.
if ! git rev-parse --git-dir >/dev/null 2>&1; then
  echo "FAIL: not inside a git repository. cd into your clone of tokio-rs/axum and re-run."
  exit 2
fi

# 1. Repo identity
git remote get-url origin 2>/dev/null | grep -qE "tokio-rs/axum(\\.git)?\\b" \\
  && ok "origin remote is tokio-rs/axum" \\
  || miss "origin remote is not tokio-rs/axum (artifact may be from a fork)"

# 2. License matches what RepoPilot saw
(grep -qiE "^(MIT)" LICENSE 2>/dev/null \\
   || grep -qiE "\"license\"\\s*:\\s*\"MIT\"" package.json 2>/dev/null) \\
  && ok "license is MIT" \\
  || miss "license drift — was MIT at generation time"

# 3. Default branch
git rev-parse --verify main >/dev/null 2>&1 \\
  && ok "default branch main exists" \\
  || miss "default branch main no longer exists"

# 5. Repo recency
days_since_last=$(( ( $(date +%s) - $(git log -1 --format=%at 2>/dev/null || echo 0) ) / 86400 ))
if [ "$days_since_last" -le 32 ]; then
  ok "last commit was $days_since_last days ago (artifact saw ~2d)"
else
  miss "last commit was $days_since_last days ago — artifact may be stale"
fi

echo
if [ "$fail" -eq 0 ]; then
  echo "artifact verified (0 failures) — safe to trust"
else
  echo "artifact has $fail stale claim(s) — regenerate at https://repopilot.app/r/tokio-rs/axum"
  exit 1
fi

Each check prints ok: or FAIL:. The script exits non-zero if anything failed, so it composes cleanly into agent loops (./verify.sh || regenerate-and-retry).

Axum is a modular, ergonomic HTTP framework for Rust built on Tokio that enables fast, type-safe web servers with minimal boilerplate. It provides routing, middleware, extractors, and response handling through composable layers (axum-core, axum-extra) that emphasize Rust's type system to catch errors at compile-time rather than runtime. Monorepo with workspace root (Cargo.toml) managing three crates: axum-core (foundational extractors, response traits, body handling in axum-core/src/extract/, axum-core/src/response/), axum (main routing/handler layer), and axum-extra (optional features like cookies, cached extractors). Each crate has independent CHANGELOG.md and Cargo.toml but shares workspace lints and Rust version constraints.

Backend Rust developers building REST APIs, microservices, and web applications who want maximum type safety, composable middleware patterns, and async/await ergonomics without sacrificing performance. Contributors are typically experienced Rust programmers interested in web infrastructure and async runtime ecosystem work.

Production-ready and actively maintained. The workspace enforces strict Clippy lints (forbid unsafe_code, warn on 40+ categories), uses CI/CD via GitHub Actions (CI.yml, release-plz.yml), spans ~1.1M Rust lines of code across axum, axum-core, and axum-extra packages, and follows semantic versioning with a maintained CHANGELOG.md. Minimum Rust version is 1.80, indicating recent toolchain demands.

Low risk for production use. The single unsafe_code = forbid lint eliminates entire categories of bugs, and workspace is organized as 3 interdependent crates (axum, axum-core, axum-extra) with clear separation of concerns. Main risk is tight coupling to Tokio ecosystem; any breaking changes in Tokio's API directly impact axum. No obvious maintainer bus-factor issues visible from structure.

Active release cycle managed by release-plz.yml. Recent focus areas inferred from file structure: error handling improvements (axum-core/src/error.rs), request/response trait extensions (axum-core/src/ext_traits/), extractor patterns and rejection handling (axum-core/src/extract/rejection.rs), and optional body adapters (axum-extra/src/body/async_read_body.rs). No specific PR/issue data visible, but CI is fully integrated.

git clone https://github.com/tokio-rs/axum.git
cd axum
cargo build
cargo test

Optional: cargo test --all to test all workspace members (axum, axum-core, axum-extra).

Daily commands: No traditional dev server; axum is a library. To run examples (inferred): cargo run --example <example_name> from axum package. To verify changes: cargo test --all runs full test suite across workspace. For lint checks: cargo clippy --all -- -D warnings.

• axum-core/src/extract/mod.rs: Defines FromRequest and FromRequestParts traits—the fundamental abstraction for parsing HTTP requests into typed Rust values
• axum-core/src/response/into_response.rs: Core response conversion trait allowing any Rust type to become an HTTP response, enabling composable response building
• axum-core/src/extract/rejection.rs: Error handling for extractors; defines how parse failures are communicated back as HTTP responses
• axum-core/src/body.rs: Abstraction over HTTP body types, critical for streaming responses and request payloads
• axum-core/src/ext_traits/mod.rs: Extension trait implementations for Request and RequestParts, adding ergonomic utility methods
• Cargo.toml: Workspace configuration showing rust-version = 1.80 requirement and strict lint enforcement (unsafe_code forbid)
• .clippy.toml: Clippy configuration customizing linting rules across workspace (type_complexity explicitly allowed)

Adding extractors: modify axum-core/src/extract/mod.rs or create new file in axum-core/src/extract/, implement FromRequest/FromRequestParts traits. Adding responses: edit axum-core/src/response/into_response.rs or response/mod.rs. Routing/handlers: axum/src likely contains Router and handler registration (not listed but core concept). Middleware: likely in axum/src or use tower crate integration. Request utilities: axum-core/src/ext_traits/request.rs and request_parts.rs for extension methods.

No unsafe code permitted: axum-core forbids unsafe entirely (workspace lints), so any feature requiring unsafe must be carefully justified. Extractor tuple limit: axum-core/src/extract/tuple.rs likely has a finite number of tuple implementations; extracting >16 fields may require custom FromRequest. Body consumption: once a request body is extracted by one extractor, it cannot be read again—order matters. Tower middleware compatibility: must implement tower::Layer and tower::Service traits; mismatches cause confusing trait bound errors. MSRV 1.80: features like const generics or newer syntax require bumping workspace rust-version in Cargo.toml.

• Extractor Pattern (FromRequest trait) — Axum's core innovation—type-driven request parsing moves HTTP parsing logic from route handlers into the type system, reducing boilerplate and enabling compiler-checked safety
• Tower Service/Layer Middleware — Axum middleware must implement tower::Service trait; understanding request/response wrapping and async composition is mandatory for custom middleware
• IntoResponse Trait Composition — Enables any Rust type (Result, custom structs, tuples) to automatically convert to HTTP responses; critical for ergonomic error handling and response building
• Request Extension Context (State Pattern) — Axum uses typed extensions (axum-core/src/ext_traits/) to pass request-scoped data through middleware without runtime downcasts; enables type-safe application context
• Body Abstractions & Streaming — Understanding axum-core/src/body.rs is essential for streaming responses, chunked uploads, and working with large payloads without buffering entire bodies in memory
• Rejection Error Types & HTTP Status Mapping — Axum's rejection system (axum-core/src/extract/rejection.rs) maps Rust errors to HTTP status codes; understanding this enables custom extractors with proper error semantics
• Zero-Unsafe Constraint (forbid unsafe_code lint) — Workspace enforces complete absence of unsafe Rust; this design choice shapes memory safety guarantees and determines which libraries axum can depend on

• tokio-rs/tokio — Axum's required async runtime; understanding Tokio's task spawning and I/O traits is essential for axum internals
• tower-rs/tower — Tower provides the middleware and service abstraction layers that axum builds upon; tower::Service is fundamental to understanding handler composition
• hyperium/hyper — Low-level HTTP primitives (Request, Response, Body) that axum wraps; knowledge of hyper::Body and http crate types required for advanced use
• actix/actix-web — Alternative Rust web framework with similar goals; comparing macro-free extractors in axum vs procedural macros in actix reveals design philosophy differences
• tokio-rs/bytes — Efficient buffer management for HTTP bodies; axum depends on Bytes for zero-copy response payloads

To work on one of these in Claude Code or Cursor, paste: Implement the "<title>" PR idea from CLAUDE.md, working through the checklist as the task list.

Add comprehensive integration tests for axum-extra/src/extract/multipart.rs

The multipart extractor is a complex feature that handles file uploads and form data. Currently, there are no dedicated integration tests visible in the file structure for multipart handling. Given the complexity of HTTP multipart parsing and the potential for edge cases (boundary handling, large files, malformed data), adding thorough tests would prevent regressions and improve maintainability. This is a high-value contribution since multipart handling is security-sensitive and widely used.

• [ ] Create tests/multipart_integration.rs with test cases for: valid multipart data, missing boundaries, oversized payloads, special characters in field names
• [ ] Test interaction with axum-core's default_body_limit.rs to ensure size limits are enforced
• [ ] Add tests for edge cases: empty multipart bodies, missing content-type headers, malformed field data
• [ ] Verify tests run in CI and document any platform-specific considerations

Implement comprehensive documentation examples in axum-extra/src/extract/cookie/mod.rs, private.rs, and signed.rs

The cookie extraction modules (including private and signed variants) are security-critical features but lack visible usage examples in the codebase. Given the workspace lints enforce missing_docs = "warn", adding documented examples with runnable code snippets for cookie handling, encryption, signing, and validation would help users understand best practices. This prevents security misconfigurations and improves API adoption.

• [ ] Add rustdoc examples to axum-extra/src/extract/cookie/mod.rs showing basic cookie extraction patterns
• [ ] Document axum-extra/src/extract/cookie/signed.rs with examples of how to properly sign and verify cookies, including key management
• [ ] Document axum-extra/src/extract/cookie/private.rs with encryption examples and security warnings about key handling
• [ ] Ensure all examples compile by testing with cargo test --doc in axum-extra workspace

Create middleware integration tests and benchmarks for axum-extra/src/middleware.rs

The middleware module is a core abstraction for request/response handling, but there's no visible test coverage in the file structure for middleware composition, ordering, and performance characteristics. Adding integration tests that verify middleware execution order, error handling, and state propagation would catch regressions. Additionally, benchmarks comparing different middleware patterns would help users make informed architectural decisions.

• [ ] Create tests/middleware_integration.rs with tests for: middleware execution order, error propagation through middleware chains, state extraction in middleware
• [ ] Test interaction between axum-extra middleware and axum-core extractors to ensure compatibility
• [ ] Add benches/middleware_perf.rs with criterion benchmarks comparing middleware overhead for different composition patterns
• [ ] Document performance characteristics in axum-extra/README.md or as rustdoc examples

• Add comprehensive doctests to axum-core/src/extract/tuple.rs showing multi-field extractor patterns; currently only impl for fixed tuple sizes without examples of composition limits
• Implement missing Debug derives for rejection types in axum-core/src/extract/rejection.rs (missing_debug_implementations is a workspace warning); audit all error types and add #[derive(Debug)]
• Write integration tests for axum-core/src/response/into_response_parts.rs demonstrating response header manipulation patterns; file exists but no obvious example coverage

The axum codebase demonstrates strong security practices with forbidding unsafe code, comprehensive clippy linting, and no obvious injection vulnerabilities detected in the file structure. However, the lack of a SECURITY.md file and limited visibility into dependency vulnerability management are minor gaps. The HTTP routing library design appears sound with no exposed credentials, hardcoded secrets, or SQL/XSS injection patterns visible in the file names and structure. Regular dependency auditing and formal security policy documentation would further strengthen the security posture.

• Low · Missing SECURITY.md File — Repository root. No SECURITY.md file found in the repository. This file should document the security policy, including how to responsibly report security vulnerabilities. Fix: Create a SECURITY.md file following GitHub's security policy guidelines. Include contact information for security reports and a responsible disclosure timeline.
• Low · Clippy Lint Configuration Could Be Stricter — .clippy.toml and Cargo.toml [workspace.lints.clippy]. While the workspace has comprehensive clippy lints enabled, the configuration allows some potentially problematic patterns like 'type_complexity' to be set to 'allow'. This reduces static analysis coverage. Fix: Review the 'allow' list in clippy configuration and evaluate whether additional lints should be enforced, particularly for security-sensitive patterns.
• Low · Unsafe Code Forbidding Reliance — Cargo.toml [workspace.lints.rust]. The workspace forbids all unsafe code via '[workspace.lints.rust] unsafe_code = "forbid"'. While this is a security best practice, it means the codebase depends entirely on safe Rust. Any unsafe code in dependencies could pose risks. Fix: Regularly audit dependencies using 'cargo-audit' and 'cargo-deny' to detect known vulnerabilities. Consider using 'cargo-crev' for community-based dependency review.

LLM-derived; treat as a starting point, not a security audit.

• Open issues — current backlog
• Recent PRs — what's actively shipping
• Source on GitHub

Generated by RepoPilot. Verdict based on maintenance signals — see the live page for receipts. Re-run on a new commit to refresh.