Config
Fields marked secret are redacted in snapshots.
VFS.md
The VFS.md an agent reads with GitHub mounted at/<path>.
- Rendered
- Raw
Tree Fetching
The full recursive tree is fetched on the first read, not at mount time, so constructing the VFS never blocks on the network. For repos with100K entries, it falls back to per-directory fetching.
Cache
The GitHub VFS usesIndexCacheStore with SHA-based fingerprinting. Content is content-addressed - if the SHA matches, the content is identical.
Under read: fresh, a cached listing is checked against the head commit
the ref resolves to: one small check per command (a shallow
git/trees/{ref}), after which every cached listing of the mount at that
commit is served. A mount whose ref is a full 40- or 64-hex commit sha
serves its cached listings with no request: github.com refuses a branch or
tag named with 40 or 64 hex characters, so such a ref always names a commit
(a GitHub Enterprise host is assumed to do the same). A repository whose recursive
tree comes back truncated stores no version, so each folder is re-listed
once per command.
Example
examples/python/vfs/github/github.py for the full working example.
Finding SHAs
Git blob SHAs are available via thestat command:
Working with Large Repos
Tips for efficient access on large repositories:Shell Commands
Standard commands available on the mounted GitHub tree:Integration
What GitHub answers through its own API, so fewer files are read. Integration explains each command.grep -rw and rg -w read only the files GitHub code search names when:
- the scope holds more than 100 files; a smaller one is read directly,
- the mounted ref is the default branch, the only one code search indexes,
- the repository tree was listed in full,
- and the search returns every hit, 100 at most.
grep -r, git grep, find and the other walks
stop after walk_limit files (default 5000) and keep what they printed,
and a glob matching more, tar -c, cp -r, rm -r and the other whole-tree
commands are refused above it: