[FEATURE] Support shallow/partial/sparse clone for large repositories in cloud environments

Preflight Checklist

• [x] I have searched existing requests and this feature hasn't been requested yet
• [x] This is a single feature request (not multiple features)

Problem Statement

Claude Code on the web performs a fresh, full git clone of the repository at the start of every session. For any repository with a large git history or large tracked assets (design files, fixtures, ML model weights, generated screenshots, video/audio samples, vendored dependencies, etc.), this makes every single new session slow to start — before any actual work begins.

There's currently no environment-level control over clone behavior. Network access, environment variables, and setup scripts don't touch the clone step. SessionStart hooks only run after the clone has already finished, so they can't reduce it. Environment caching persists setup-script output (installed toolchains/deps), not the clone itself, so repeat sessions don't get faster either — each one re-pays the full clone cost from scratch.

This is a common shape of problem, not a niche one: many real-world repos are large for reasons that have nothing to do with the source code a given task touches — accumulated history, binary test fixtures, generated assets, monorepos with unrelated packages. Users in that situation currently have two bad options: pay for Git LFS (adds ongoing bandwidth/storage cost and migration effort), or rewrite git history to shrink it (breaks commit SHAs for every collaborator, high-risk, one-way door). Neither should be required just to make a cloud dev session start reasonably fast.

Proposed Solution

Add clone-behavior controls to environment configuration, alongside the existing network access / env vars / setup script options:

• Shallow clone depth (equivalent to git clone --depth=N) — skip old history that isn't needed for the current task
• Partial clone filters (--filter=blob:none / --filter=tree:0) — fetch tree structure without downloading blob contents until touched
• Sparse-checkout path allow/deny lists — exclude specific directories (e.g. large asset folders) from checkout entirely, applied at clone time rather than after

These would ideally be configurable per-environment, similar to how network access level works today, so a repo owner sets it once and every session benefits automatically. Git already supports all three natively — this is about exposing them as first-class environment settings rather than requiring users to work around a full clone after the fact.

Alternative Solutions

• Git LFS: shifts large files out of the repo, but adds recurring bandwidth/storage costs that scale with usage — not viable for many teams, especially those with large media/asset directories.
• Rewriting git history (git filter-repo / BFG) to remove large blobs: reduces repo size, but rewrites every commit SHA, breaking history for all collaborators and any external references (CI, issue links, blame). High-risk and typically irreversible in practice.
• A SessionStart hook that runs git sparse-checkout after the session starts: doesn't help, since the expensive full clone has already completed by the time any hook runs.

None of these actually solve the underlying problem — they just relocate the cost or introduce new risk.

Priority

Medium - Would be very helpful

Feature Category

Performance and speed

Use Case Example

1. A team works in a repository that has grown large over time — years of history, or tracked binary assets (screenshots, fixtures, models, media) that aren't needed for most day-to-day source changes.
2. A developer starts a new Claude Code on the web session to make a small, focused change.
3. Session startup is dominated by cloning the full repository — history and assets included — even though the task only touches a handful of source files.
4. This tax is paid on every new session, compounding across a team and across the lifetime of the repo as it keeps growing.
5. With shallow/sparse clone support, the environment is configured once (e.g. "shallow clone, depth 1" and/or "exclude /assets, /fixtures from checkout"). Every subsequent session clones only what's needed, startup time drops significantly, and full history/assets remain available on request when a task actually needs them.

Additional Context

Relevant docs describing current clone behavior: https://code.claude.com/docs/en/claude-code-on-the-web#the-cloud-environment ("Cloud sessions start from a fresh clone of your repository")

Comparable prior art:

• git clone --filter=blob:none --sparse (native git partial/sparse clone, widely used for large monorepos)
• GitHub Codespaces devcontainer sparse-checkout support
• GitLab CI GIT_STRATEGY and sparse-checkout settings

This would benefit any team whose repository is large for reasons unrelated to the specific task at hand — a common situation, not an edge case.