Hmbown/CodeWhale · error · std::io::Error
workspace too large for snapshots: over
Error message
workspace too large for snapshots: over {cap_bytes} bytes of snapshot-eligible content in {workspace} What it means
open_or_init_with_cap estimates snapshot-eligible workspace content via estimate_workspace_size_bounded against cap_bytes; when the estimate exceeds the cap the gate error's describe() is returned as ErrorKind::InvalidInput. This protects against building enormous snapshot repos; large workspaces get aggressive pruning only after the repo exists.
Solutions
- Add large generated content to .gitignore so it is not snapshot-eligible, and clean build artifacts.
- Raise the size cap (MAX_SNAPSHOT_SIZE_MB-derived cap_bytes) if the workspace legitimately needs it.
- Move the large data out of the workspace or exclude it from the snapshot workspace path.
Example fix
// before: workspace with 5GB of artifacts // .gitignore missing // after echo -e "target/\ndist/\n*.iso\nnode_modules/" >> .gitignore
Defensive patterns
Strategy: validation
Validate before calling
// estimate eligible bytes before opening
let eligible: u64 = WalkDir::new(workspace)
.filter_entry(|e| !is_ignored(e))
.filter_map(|e| e.metadata().ok())
.filter(|m| m.is_file())
.map(|m| m.len())
.sum();
if eligible > cap_bytes { eprintln!("workspace exceeds snapshot cap"); } Try / catch
match open_or_init_with_cap(ws, cap) {
Err(e) if e.to_string().contains("too large for snapshots") => eprintln!("gitignore large artifacts or raise MAX_SNAPSHOT_SIZE_MB"),
r => r?,
} Prevention
- Keep .gitignore current for build outputs and datasets
- Store large data outside the workspace
- Raise MAX_SNAPSHOT_SIZE_MB deliberately for known-large workspaces
When it happens
Trigger: Calling open_or_init_with_cap on a workspace whose estimated snapshot-eligible bytes exceed cap_bytes within SIZE_WALK_MAX_ENTRIES walked entries.
Common situations: Opening codewhale in a directory containing large datasets, build artifacts, videos, or node_modules outside .gitignore; workspaces that grew past the cap mid-session.
Understand the failure class
Background: "File too large" / "file size exceeds limit" errors: why libraries cap file sizes and how to fix them — this error's family across 46 libraries.
Related errors
- <workspace size gate message>
- workspace snapshots are disabled for
- AutomationEditorInvalidWorkspace
- bounded provider catalog cache exceeds its write limit
- bundle at is bytes; the limit is bytes
AI-assisted analysis of Hmbown/CodeWhale@433685b202 (2026-09-15).
Data as JSON: /api/errors/4f854adb8bc60c40.
Report an issue: GitHub.
Appendix: source
Thrown at crates/tui/src/snapshot/repo.rs:348
));
}
let _ = ensure_snapshot_dir(&work_tree)?;
let git_dir = snapshot_git_dir(&work_tree);
let needs_init = !git_dir.exists();
if needs_init {
// First-init size guard. Skipping this on subsequent opens
// is intentional: paying a workspace walk on every snapshot
// would defeat the purpose of the cap, and a workspace
// that fit on first init is allowed to grow within the
// existing repo's `MAX_SNAPSHOT_SIZE_MB` budget. Users on
// workspaces that grew past the cap mid-session get the
// existing aggressive-pruning path in `snapshot()`.
if let Err(gate) =
estimate_workspace_size_bounded(&work_tree, cap_bytes, SIZE_WALK_MAX_ENTRIES)
{
return Err(io::Error::new(
io::ErrorKind::InvalidInput,
gate.describe(cap_bytes, workspace),
));
}
let parent = git_dir.parent().ok_or_else(|| {
io::Error::new(io::ErrorKind::InvalidInput, "snapshot dir has no parent")
})?;
std::fs::create_dir_all(parent)?;
// `git init` here uses the parent directory as the work tree
// and stores metadata in `.git`. We then continue to use
// explicit `--git-dir` / `--work-tree` flags for every other
// command so behaviour is invariant of cwd.
let init = crate::dependencies::Git::command()
.ok_or_else(|| io_other("git not found on PATH"))?
.arg("init")
.arg("--quiet")
.arg(parent)
.output()View on GitHub (pinned to 433685b202)