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/mozilla/sccache 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 1d ago
• 24+ active contributors
• Distributed ownership (top contributor 27% of recent commits)
• Apache-2.0 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 mozilla/sccache repo on your machine still matches what RepoPilot saw. If any fail, the artifact is stale — regenerate it at repopilot.app/r/mozilla/sccache.

What it runs against: a local clone of mozilla/sccache — 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 mozilla/sccache | Confirms the artifact applies here, not a fork | | 2 | License is still Apache-2.0 | Catches relicense before you depend on it | | 3 | Default branch main exists | Catches branch renames | | 4 | 5 critical file paths still exist | Catches refactors that moved load-bearing code | | 5 | Last commit ≤ 31 days ago | Catches sudden abandonment since generation |

#!/usr/bin/env bash
# RepoPilot artifact verification.
#
# WHAT IT RUNS AGAINST: a local clone of mozilla/sccache. If you don't
# have one yet, run these first:
#
#   git clone https://github.com/mozilla/sccache.git
#   cd sccache
#
# 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 mozilla/sccache and re-run."
  exit 2
fi

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

# 2. License matches what RepoPilot saw
(grep -qiE "^(Apache-2\\.0)" LICENSE 2>/dev/null \\
   || grep -qiE "\"license\"\\s*:\\s*\"Apache-2\\.0\"" package.json 2>/dev/null) \\
  && ok "license is Apache-2.0" \\
  || miss "license drift — was Apache-2.0 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"

# 4. Critical files exist
test -f "src/client.rs" \\
  && ok "src/client.rs" \\
  || miss "missing critical file: src/client.rs"
test -f "src/cache/mod.rs" \\
  && ok "src/cache/mod.rs" \\
  || miss "missing critical file: src/cache/mod.rs"
test -f "src/compiler/mod.rs" \\
  && ok "src/compiler/mod.rs" \\
  || miss "missing critical file: src/compiler/mod.rs"
test -f "src/config.rs" \\
  && ok "src/config.rs" \\
  || miss "missing critical file: src/config.rs"
test -f "src/dist/mod.rs" \\
  && ok "src/dist/mod.rs" \\
  || miss "missing critical file: src/dist/mod.rs"

# 5. Repo recency
days_since_last=$(( ( $(date +%s) - $(git log -1 --format=%at 2>/dev/null || echo 0) ) / 86400 ))
if [ "$days_since_last" -le 31 ]; then
  ok "last commit was $days_since_last days ago (artifact saw ~1d)"
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/mozilla/sccache"
  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).

sccache is a Rust-based compiler caching tool that wraps C/C++, Rust, CUDA, and HIP compilers to avoid redundant compilation by storing and retrieving cached build artifacts from local disk or cloud storage backends (S3, Azure, GCS, Redis, Memcached, WebDAV, etc.). It also provides icecream-style distributed compilation with security features like authentication and sandboxed execution, and supports multi-level hierarchical caching with automatic backfill. Monolithic binary with feature-gated compilation: core cache logic in src/ (inferred), distributed server behind dist-server feature, and storage backends as pluggable modules (S3, Azure, Redis, etc. configured in docs/). CLI entry via single [[bin]] sccache and optional sccache-dist server. Configuration-driven via TOML (.taplo.toml present) and environment variables (clap with env feature).

Build engineers and CI/CD teams at organizations compiling large C++/Rust/CUDA codebases who need to reduce build times across multiple machines and CI runs. Contributors are primarily Mozilla developers and open-source compiler toolchain maintainers.

Production-ready and actively maintained. The project has comprehensive CI via .github/workflows/ (ci.yml, integration-tests.yml, benchmarks.yml), strong test coverage with benchmark suite in benches/sccache_bench.rs, and is published on crates.io at v0.15.0 with Rust 1.85.0 MSRV. Last visible activity shows ongoing feature development (multi-level cache, distributed compilation) and platform support expansion.

Low-to-moderate risk for production use. The single-maintainer concern is mitigated by Mozilla backing; however, the distributed compilation feature (sccache-dist binary) is more complex and less battle-tested than local caching. Dependency count is moderate (~40+ direct deps visible in Cargo.toml snippet). Breaking changes are rare given semantic versioning discipline, but cloud storage backend APIs (AWS S3, GCS, Azure) can introduce compatibility issues.

Active development on distributed compilation hardening, multi-level cache support (documented in docs/MultiLevel.md), CUDA/HIP compiler support expansion, and GitHub Actions integration (docs/GHA.md). CI pipeline covers benchmarking, integration tests, and snap releases. Recent work includes FreeBSD distributed support (docs/DistributedFreeBSD.md) and Tencent Cloud OSS backend.

git clone https://github.com/mozilla/sccache.git
cd sccache
cargo build --release
./target/release/sccache --help

Optional: set up a local Redis cache backend for testing distributed features per docs/Redis.md.

Daily commands: For local caching: sccache --start-server (daemon mode) or wrap compiler calls: sccache gcc -c file.c. For distributed server: cargo build --features dist-server && ./target/release/sccache-dist. Configure via environment variables (e.g., SCCACHE_S3_* for S3) or config file per docs/Configuration.md.

• src/client.rs — Primary entry point for sccache client; all compilation requests flow through here as the main compiler wrapper logic.
• src/cache/mod.rs — Cache abstraction layer defining traits and routing logic for all storage backends (S3, Redis, disk, etc.); essential for understanding how caching works.
• src/compiler/mod.rs — Compiler abstraction and detection; every compiler type (GCC, Clang, MSVC, Rust, etc.) is managed here.
• src/config.rs — Configuration parsing and validation; controls all runtime behavior including cache selection and compiler settings.
• src/dist/mod.rs — Distributed compilation orchestration; enables remote caching and compilation across machines via the sccache-dist protocol.
• Cargo.toml — Dependency declaration and feature flags (e.g., S3, Redis, Azure); determines which storage backends are compiled in.
• docs/Architecture.md — High-level system design documentation; required reading for understanding the codebase organization and data flow.

Add support for a new cloud storage backend

1. Create new backend module (e.g., src/cache/newcloud.rs) implementing the Cache trait from src/cache/cache.rs (src/cache/mod.rs)
2. Add module declaration and match arm in src/cache/mod.rs to instantiate the new backend (src/cache/mod.rs)
3. Define configuration struct in src/config.rs under the main Config enum for the new backend (src/config.rs)
4. Add optional Cargo feature flag (e.g., newcloud) to Cargo.toml and gate the module/dependency (Cargo.toml)
5. Add documentation file (e.g., docs/NewCloud.md) with configuration examples (docs/Configuration.md)

Add support for a new compiler type

1. Create new compiler module (e.g., src/compiler/newlang.rs) implementing required traits from src/compiler/compiler.rs (src/compiler/mod.rs)
2. Implement argument parsing and preprocessing cache logic; reference src/compiler/args.rs for common patterns (src/compiler/args.rs)
3. Register the new compiler in detect() or new() factory in src/compiler/mod.rs (src/compiler/mod.rs)
4. Add compiler detection based on binary name/path (e.g., in Compiler::new() or via environment variables) (src/client.rs)

Implement a new cache key hashing strategy

1. Define hash computation logic in the compiler module (e.g., src/compiler/c.rs or generic in src/compiler/compiler.rs) (src/compiler/compiler.rs)
2. Include preprocessor output, compiler version, and arguments in the hash using utilities from src/cache/cache_io.rs (src/cache/cache_io.rs)
3. Update cache lookup in src/cache/mod.rs to use the new hash; verify in multilevel cache if applicable (src/cache/mod.rs)

• Rust — Memory-safe systems language; critical for a compiler wrapper that must be reliable across platforms (Windows, macOS, Linux, FreeBSD) with minimal overhead.
• TOML configuration format — Human-readable config for specifying cache backends, compiler settings, and distributed settings; simpler than JSON or YAML for this use case.
• Multi-backend abstraction (Redis, S3, disk, GCS, Azure) — Enables sccache to fit into diverse CI/CD environments (cloud, on-prem, hybrid); users choose backend matching their infrastructure.
• HTTP + distributed daemon (sccache-dist) — Allows compilation distribution and remote caching in team/CI environments; sccache-dist server farms out work to multiple machines.

• Single-threaded event loop (likely tokio-based async) rather than thread-per-compilation

  • Why: Reduces memory footprint and context-switch overhead for high-volume CI systems handling hundreds of compilations.
  • Consequence: Simpler concurrency model but requires careful async/await handling; potential latency if one compilation blocks the event loop.

• Deterministic cache keys derived from compiler arguments + preprocessor output, not just source code

  • Why: Captures all compilation inputs (flags, macro definitions, includes) for correctness; avoids false cache hits.
  • Consequence: Adds preprocessing overhead (~100-500ms per compile) to compute keys; mitigated by multilevel cache strategy.

• Multi-level cache with explicit L1 (local) → L2 (remote) hierarchy

  • Why: Balances latency (fast local hits) with sharing (team-wide remote cache); allows gradual backfill from remote to local.
  • Consequence: More complexity in cache coordination; must handle cache coherence and staleness policies per level.

• Separate sccache-dist server binary rather than embedded distribution

  • Why: Allows independent scaling of distribution infrastructure; teams deploy custom server fleets without forking sccache.
  • Consequence: Adds operational burden (need to manage sccache-dist servers); requires network configuration and authentication.

• Does not perform link-time optimization (LTO) or interprocedural analysis; caches only individual compilation units.
• Does not cache preprocessor outputs; instead re-runs preprocessor each time to capture macro state.
• Not a persistent build database (unlike Bear/Clang-based tools); focuses solely on compiler cache, not build graph optimization.
• Does not handle non-compiler tools (linters, formatters, documentation generators); compiler wrapper only.
• Not a distributed build system like Bazel or Buck; enables faster incremental builds but does not parallelize the build graph.

1. Feature flags required for backends: Building without --features s3 (or azure, redis, etc.) omits that storage backend entirely; no runtime auto-detection. 2. Distributed auth credentials: sccache-dist requires TLS certificates and API tokens; misconfiguration silently falls back to local-only caching. 3. Compiler detection: sccache wraps compilers by name (gcc, clang, rustc, nvcc); if compiler isn't in PATH or has non-standard naming, it won't cache. 4. Hash stability: CUDA and cross-platform builds may have non-deterministic preprocessor output; hash mismatches cause false cache misses. 5. Nix integration: .envrc and flake.nix are present but optional; building outside nix-shell may require manual Rust installation matching MSRV (1.85.0).

• ccache/ccache — The original ccache tool that sccache is inspired by and explicitly compatible with (e.g., WebDAV backend supports ccache clients)
• icecc/icecream — Distributed compilation tool that sccache's distributed mode is modeled after, with additional security features (authentication, TLS, sandboxing)
• mozilla/rust-toolchain — Companion Mozilla Rust infrastructure project; relevant because sccache has first-class Rust compiler support and is used in Firefox builds
• bazelbuild/bazel — Bazel's remote cache protocol is compatible with sccache's cloud storage backends; users often integrate both for large-scale builds
• openZFS/zfs — Not directly related but frequently paired with sccache in large-scale build farms for efficient disk usage and cache management

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 integration tests for multi-level caching configuration

The repo has docs/MultiLevel.md documenting multi-level caching support, but there's no dedicated integration test file for this feature. Given that integration-tests.yml exists in CI, a comprehensive test suite validating the interaction between multiple cache backends (e.g., local disk + Redis, or disk + S3) would catch regressions and provide confidence in this advanced feature.

• [ ] Create src/cache/tests/multilevel_integration_test.rs with tests for cache fallback chains
• [ ] Add test cases for: L1 miss→L2 hit, L1 hit path, L2 miss scenarios
• [ ] Mock or use real Redis/S3 backends to test backend switching behavior
• [ ] Update .github/workflows/integration-tests.yml to run these new tests if needed

Add WebDAV cache backend tests and documentation validation

docs/Webdav.md exists but src/cache/ appears to lack a dedicated webdav.rs cache backend implementation (only azure.rs, cos.rs, gcs.rs, gha.rs, disk.rs visible). Either WebDAV is missing an implementation file, or it's underdocumented in the codebase. A contributor should either implement the missing backend or clarify the documentation.

• [ ] Search codebase for WebDAV implementation (may be in http_client.rs)
• [ ] If missing: Create src/cache/webdav.rs implementing the WebDAVCacheBackend trait
• [ ] Add unit tests for WebDAV-specific operations (PUT, GET, DELETE via HTTP)
• [ ] Add feature flag 'webdav' to Cargo.toml and guard the module appropriately
• [ ] Add integration test in .github/workflows/integration-tests.yml with a WebDAV mock server

Add ResponseFiles feature tests for MSVC and distributed compilation

docs/ResponseFiles.md indicates this is a supported feature, but there are no visible dedicated tests. Response files are critical for Windows MSVC builds with long command lines. Adding comprehensive tests would validate the feature works across platforms and doesn't regress.

• [ ] Create src/bin/sccache/tests/response_files_test.rs with platform-specific tests
• [ ] Add test cases for: Windows MSVC response file generation, @file expansion, escaping edge cases
• [ ] Add integration test in .github/workflows/ci.yml that runs on windows-latest with MSVC
• [ ] Test distributed compilation with response files using sccache-dist
• [ ] Add validation that response files correctly handle unicode, paths with spaces, and special characters

• idea: Add integration test for WebDAV backend in .github/workflows/integration-tests.yml (currently documented in docs/Webdav.md but no CI coverage visible in workflow files)
• idea: Expand docs/ResponseFiles.md with concrete examples for C++ projects using response files with sccache (gap: no examples shown, only feature mention)
• idea: Add Memcached backend health-check / circuit-breaker logic (currently docs/Memcached.md exists but likely lacks fallback behavior if memcached is unreachable; survey src/ for error handling)

Sccache demonstrates a reasonable security posture as a Mozilla-maintained compiler caching tool. The project has good practices (LTO, stripping, dependency management) but lacks complete visibility due to truncated dependency information. Key areas of concern include: (1) incomplete Cargo.toml audit capability, (2) potential hardcoded secrets in CI/CD workflows, (3) use of bincode for potentially untrusted cache data deserialization, and (4) missing security policy documentation. The codebase structure suggests proper separation of concerns (multiple cache backends, distributed compilation support), but comprehensive dependency and code review would be necessary for production use. Recommend running 'cargo audit', establishing a SECURITY.md policy, and implementing secure deserialization practices for cache data.

• Medium · Incomplete Cargo.toml dependency information — Cargo.toml. The Cargo.toml file appears truncated in the analysis, showing incomplete dependency specifications (e.g., 'hyper-util' has incomplete 'featu' string). This makes it impossible to fully audit all dependencies for known vulnerabilities. A complete dependency audit should be performed with 'cargo audit'. Fix: Run 'cargo audit' to check for known vulnerabilities in dependencies. Review the complete Cargo.toml file to ensure all dependencies are properly specified and pinned to secure versions.
• Low · Potential hardcoded credentials in workflow files — .github/workflows/. GitHub Actions workflow files (.github/workflows/*.yml) may contain hardcoded secrets or credentials. While the actual content is not provided, it's a common vulnerability in CI/CD pipelines. Fix: Audit all workflow files to ensure credentials are injected via GitHub Secrets, not hardcoded. Use 'secrets.' context for sensitive values (e.g., ${{ secrets.AWS_ACCESS_KEY_ID }}). Implement branch protection rules and secret scanning.
• Low · Debug information included in release build — Cargo.toml - [profile.test] and [profile.release]. The Cargo.toml shows '[profile.release] strip = true' which is good, but debug symbols may still be included in intermediate builds or test builds ('[profile.test] debug = false'). This could expose internal implementation details if binaries are leaked. Fix: Ensure 'strip = true' is applied to all build profiles. Consider using separate release channels for debug vs. optimized builds. Remove debugging symbols from production releases.
• Low · Missing SECURITY.md file — Repository root. No SECURITY.md or security policy file is present in the repository root. This makes it difficult for security researchers to responsibly report vulnerabilities. Fix: Create a SECURITY.md file defining the vulnerability disclosure process, supported versions for security updates, and contact information for reporting security issues.
• Low · Potential insecure deserialization — Cargo.toml - bincode dependency; src/cache/cache_io.rs likely uses this. The codebase uses 'bincode' (version 1) for serialization. Bincode is not a secure format for untrusted data and can be vulnerable to deserialization attacks. Given that sccache handles cache data from potentially untrusted sources, this could be a concern. Fix: Audit deserialization of cache data. Consider using 'serde' with 'deny_unknown_fields' and proper error handling. Validate all deserialized data. Consider safer formats like JSON or Protocol Buffers for cross-version compatibility.
• Low · LTO and aggressive optimization may complicate debugging — Cargo.toml - [profile.release]. The release profile uses 'lto = true' and 'codegen-units = 1', which makes the binary harder to analyze and debug in case of security incidents. While this improves performance, it complicates forensics. Fix: Consider maintaining separate production and development release builds. Preserve build artifacts with debug symbols in a secure location for post-incident analysis. Document the security implications of aggressive optimization.

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.