Bug
Every auto-generated PR from cc-taskrunner includes an unsolicited modification to the target repo's `.gitignore`, adding:
```
cc-taskrunner worktree protection
C:*
node_modules/
.pnpm-store/
pycache/
```
Concrete example
Observed on `Stackbilt-dev/stackbilt-memory` PR #12 (`feat(recall): add after/before ISO8601 recency filter`) which was an autonomous run of task `8db68535-36dd-425f-9fa3-a2d7d9457b2d`. Full diff at https://github.com/Stackbilt-dev/stackbilt-memory/pull/12/files.
The PR's scope was adding a recency filter to `recall()` — an ~~80-line feature change. Instead it shipped ~~80 feature lines plus 5 unsolicited `.gitignore` modifications that have nothing to do with the task.
Why this matters
- Failure mode: first-glance PR review bounce. An operator reviewing the PR sees `C:*` (a Windows drive-letter glob) being added to the `.gitignore` of a Cloudflare Worker repo on a Linux/WSL host. That's obviously wrong, obviously unrelated to the task, and makes the rest of the PR look careless even when the feature work is correct.
- `node_modules/` is usually a no-op dup — most target repos already have this line, so the addition is noise.
- `C:*` is a leaked WSL/Windows path from the operator's host environment — it doesn't belong in any checked-in gitignore.
- This affects EVERY task's PR, not just one. It's a framework-level contamination that compounds across the cc-task fleet.
- Trust trial cost. The first taskrunner trial (memory#11) had to be audited specifically for this. Every subsequent operator review will cost the same attention.
Root cause (hypothesis, not verified)
The taskrunner is applying a worktree-protection `.gitignore` layer during container setup to prevent its own tooling state (Windows path leakage, pnpm store, Python bytecode) from getting picked up by git in the worktree. Then it forgets to unstage those changes before running `git add` / committing the feature work, so the worktree-local `.gitignore` edits end up in the PR.
If that's the shape, the fix is one of:
- Scope the worktree protection to `.git/info/exclude` instead of `.gitignore` — that file is worktree-local and never committed
- Stash or revert the `.gitignore` changes before the task's feature commit
- Use `git update-index --assume-unchanged .gitignore` if the local modifications need to persist across commands
- Don't modify `.gitignore` at all — instead make the taskrunner's own tooling respect an unusual worktree layout
Operator impact
Every auto-generated PR needs a cleanup commit stripping those 5 lines before merge. For the memory#11 trial this was a known gotcha we worked around. For bulk autonomous work it's a trust-eroding tax on every PR.
Related
Bug
Every auto-generated PR from cc-taskrunner includes an unsolicited modification to the target repo's `.gitignore`, adding:
```
cc-taskrunner worktree protection
C:*
node_modules/
.pnpm-store/
pycache/
```
Concrete example
Observed on `Stackbilt-dev/stackbilt-memory` PR #12 (`feat(recall): add after/before ISO8601 recency filter`) which was an autonomous run of task `8db68535-36dd-425f-9fa3-a2d7d9457b2d`. Full diff at https://github.com/Stackbilt-dev/stackbilt-memory/pull/12/files.
The PR's scope was adding a recency filter to `recall()` — an ~~80-line feature change. Instead it shipped ~~80 feature lines plus 5 unsolicited `.gitignore` modifications that have nothing to do with the task.
Why this matters
Root cause (hypothesis, not verified)
The taskrunner is applying a worktree-protection `.gitignore` layer during container setup to prevent its own tooling state (Windows path leakage, pnpm store, Python bytecode) from getting picked up by git in the worktree. Then it forgets to unstage those changes before running `git add` / committing the feature work, so the worktree-local `.gitignore` edits end up in the PR.
If that's the shape, the fix is one of:
Operator impact
Every auto-generated PR needs a cleanup commit stripping those 5 lines before merge. For the memory#11 trial this was a known gotcha we worked around. For bulk autonomous work it's a trust-eroding tax on every PR.
Related