[ENHANCEMENT] Tasks feature: each task's .git folder consumes ~1GB, totaling 33GB+ on disk

[kokorolx]

Problem (one or two sentences)

Describe the bug
The Tasks feature creates task directories that each contain a .git
folder. Each .git is ~1GB in size. With ~33 tasks accumulated, total
disk usage has grown to 33GB.

Context (who is affected and when)

Environment

• OS: macOS
• Discovered via: dust (disk usage tool)

Steps to reproduce

1. Use Roo Code Tasks feature over time
2. Run dust on the tasks directory to inspect disk usage
3. Observe large .git directories inside each task folder

Desired behavior (conceptual, not technical)

Expected behavior
Task .git directories should either not be created, be
pruned/compressed automatically, or users should be warned about disk
growth.

Actual behavior
Each task accumulates ~1GB in its .git folder. 33 tasks = 33GB disk
usage.

Constraints / preferences (optional)

No response

Request checklist

• I've searched existing Issues and Discussions for duplicates
• This describes a specific problem with clear context and impact

Roo Code Task Links (optional)

No response

Acceptance criteria (optional)

Expected behavior
Task .git directories should either not be created, be
pruned/compressed automatically, or users should be warned about disk
growth.

Proposed approach (optional)

Reasonable middle grounds they could offer:

• Shallow clone / --depth=1 to limit history size
• Auto-prune tasks older than X days
• git gc --aggressive after task ends
• Make git tracking opt-in, not default

Trade-offs / risks (optional)

Pro

• Full history of every file change Roo made during the task — you can
  git diff, git log, revert mistakes
• Isolated per-task, no cross-contamination

Con

• Unbounded disk growth (~1GB/task × N tasks)
• Most users never look at task git history
• No auto-cleanup or size warning

The tradeoff: You're paying 1GB per task for a full audit trail that
most users never use.

[roomote-v0]

I've analyzed this issue and here's my proposed implementation plan:

Root Cause

The checkpoints feature (RepoPerTaskCheckpointService) creates a full shadow git repo at globalStorageDir/tasks/{taskId}/checkpoints/ for every task. Each shadow repo tracks the entire workspace via core.worktree, staging and committing all non-excluded files on every checkpoint. Git loose objects accumulate rapidly, and no git gc is ever run -- not after init, not after checkpoints, and not when a task finishes.

Proposed Changes

1. Run git gc after shadow repo initialization (ShadowCheckpointService.ts)

After the initial commit in initShadowGit(), run git gc --auto to pack loose objects. This is lightweight (git skips it if thresholds aren't met) and prevents the initial full-workspace commit from leaving a large set of loose objects.

2. Run periodic git gc --auto after checkpoint saves (ShadowCheckpointService.ts)

In saveCheckpoint(), after a successful commit, run git gc --auto. The --auto flag means git will only actually do work when the number of loose objects exceeds its threshold (default ~6700), so this adds negligible overhead for tasks with few checkpoints but kicks in for longer-running tasks.

3. Run git gc --aggressive --prune=now on task completion/disposal

When a task finishes (in the checkpoint service disposal path or when clearTask is called), run a more aggressive gc to maximize compression of the final state. Since the task is done, the extra CPU time is acceptable.

4. Add tests

• Unit tests for the gc behavior in ShadowCheckpointService.spec.ts
• Verify git gc --auto is called after init and checkpoint saves
• Verify aggressive gc is called on disposal

Files to Modify

• src/services/checkpoints/ShadowCheckpointService.ts -- add gc calls in initShadowGit(), saveCheckpoint(), and a new dispose() method
• src/services/checkpoints/__tests__/ShadowCheckpointService.spec.ts -- add test coverage
• src/core/checkpoints/index.ts -- wire up disposal gc when task ends

Trade-offs

• git gc --auto is very cheap when there's nothing to do (just checks thresholds), so the per-checkpoint overhead is minimal
• Aggressive gc on task completion may take a few seconds for very large repos, but since the task is already done this is acceptable
• This does not address the fundamental issue of unbounded task accumulation (no auto-pruning of old tasks), but it should reduce per-task .git size significantly (often 50-80% reduction)

Future Considerations (out of scope for this PR)

• Auto-pruning tasks older than X days
• A user-facing setting to disable checkpoint git tracking
• Shallow history / --depth=1 equivalent for shadow repos

Please mention @roomote in a comment saying that you approve this plan, and I'll proceed with the implementation.