Git sparse checkout changes which tracked files appear in your working directory. It does not limit what a person can read, fetch or see in history, and the Git manual does not present it as a security feature. If a team must not see a directory, sparse checkout will not enforce that.
What the manual says it does
The documentation for sparse checkout describes it as changing the working tree from having all tracked files to only a subset. Excluded paths are skipped by setting a flag in the index, and the entries stay in the index. Cone mode, the default, takes directories instead of patterns, and the older pattern mode is described as deprecated. The command is marked experimental.
Nothing on the page mentions permissions or restricting access. Its scope is convenience in a large repository.
What it does not do
- It does not control what a user is allowed to fetch.
- It does not remove files from history.
- It does not stop a user from turning the setting off.
The manual does not say whether object data for excluded paths is downloaded, so do not build a security argument on that either. Anyone with read access to the repository can change their own sparse settings.
Where access control really lives
Permissions in Git hosting apply to the repository as a whole. For separation inside a monorepo, you have these real options:
- Split sensitive code into its own repository with its own team access.
- Control writes with code owners and rulesets, so changes to a path need approval from its owners. This limits who can change code, not who can read it.
- Keep secrets and customer data out of the repository, since read access to one directory means read access to all.
Using sparse checkout well
Use it for speed and focus. Developers working on one service can check out only that directory. Treat it as a way to reduce noise and local disk use. Pair it with CODEOWNERS for review rules. See CODEOWNERS file pitfalls.
A quick decision test
Ask: if every developer in the company could read this directory, would that be acceptable? If yes, a monorepo is fine. If no, it belongs in a separate repository.
Teams sometimes reach for sparse checkout during an acquisition or when onboarding a contractor, hoping to show them only part of the code. That is the moment to be strict. Decide first what the person may read, then create a repository or access grant that matches. If the decision turns out to be that they may read everything, a sparse checkout is still a useful convenience, but it is a convenience and should be described that way in your onboarding notes.
Try it yourself
Click through it at your own pace, or open it full screen. Look at how dependencies from many directories roll into one inventory.
Quick check
Can sparse checkout stop a contractor from reading the payments directory?
No. It is a working tree setting that the user controls. Use separate repositories or avoid granting access.
Does it help with large monorepo performance?
That is its purpose: fewer files in the working directory. Check the current manual for details, as the command is marked experimental.
Sources
Last reviewed: 19 October 2026.
