Background git fetch every ~5s per worktree: high process churn with many worktrees, and the local branch is never updated

## Summary

The desktop app runs `git fetch` against **every** worktree roughly **every 5 seconds**. With 20 worktrees this produces a constant stream of processes — **87 `git.exe` + 10 `git-remote-https.exe` in a 60-second window on an otherwise idle machine**.

The part that makes this hard to justify from a user's perspective: the fetch only updates the remote-tracking ref (`refs/remotes/origin/main`). It never touches the local branch. So the machine pays CPU and network continuously, and I still have to run `git pull` by hand every time I sit down to work on a project. The benefit accrues to the app's UI (showing "N commits behind"), not to the working copy.

I'd like to keep the feature — just have a way to control its cost.

## Environment

| | |
|---|---|
| App | 1.1.2 |
| Copilot CLI | 1.0.75 |
| OS | Windows 11 Pro (10.0.26200) |
| git | 2.53.0.windows.3 (both system git and the bundled `github-copilot-git-2.53.0-3`) |
| Worktrees | 20, across 19 projects |

## What I measured

Passive WMI process-creation subscription (`__InstanceCreationEvent`), so the measurement itself creates no processes.

**60-second window, machine idle:**

| process | count |
|---|---|
| `conhost.exe` | 126 |
| `git.exe` | 87 |
| `node.exe` | 77 |
| `pwsh.exe` | 29 |
| `git-remote-https.exe` | 10 |

**Breaking down the git calls (90-second window):**

| subcommand | count | |
|---|---|---|
| `remote-https` | 12 | network |
| `fetch` | 9 | network |
| `diff` | 2 | |
| `rev-list` | 2 | |
| `status` | 2 | |
| `rev-parse` | 1 | |

More than half of the git processes are network calls.

**Fetch interval for a single worktree:** 6 fetches in 90 seconds against the same worktree — **~5 second average interval**.

The exact command:

```
git -c core.longpaths=true -C fetch --progress \
--no-write-fetch-head origin +refs/heads/main:refs/remotes/origin/main
```

Parent process chain confirms the origin is the app itself:

```
git.exe <- github.exe <- explorer.exe
```

Each `git.exe` also drags a `conhost.exe` along, which accounts for most of the 126 consoles.

## Why the cost doesn't buy the user anything

`git fetch` updates `refs/remotes/origin/main` only — it does not merge into the local branch ([git-fetch docs](https://git-scm.com/docs/git-fetch)). `--no-write-fetch-head` additionally suppresses the `FETCH_HEAD` write, so nothing user-visible changes in the working copy.

Net effect: continuous network + CPU, and `git pull` is still required manually. From the outside it looks like the polling exists to keep the app's status indicator fresh, which is reasonable — but the frequency and the multiplication across worktrees make it expensive.

## What I tried

Searched for a way to disable or slow this down and found nothing:

- No `autoFetch` / `gitPolling` / `fetchInterval` / `disableGitStatus` key in the [CLI config dir reference](https://docs.github.com/en/copilot/reference/copilot-cli-reference/cli-config-dir-reference)
- No CLI flag or environment variable I could find
- VS Code's `git.autofetch` is a separate mechanism — and notably it is **disabled by default**, with `git.autofetchPeriod` defaulting to **180 seconds** ([docs](https://code.visualstudio.com/docs/sourcecontrol/repos-remotes)). That's 36x less frequent than what the app does.

I applied the git-side mitigations that reduce the cost *per call* (`core.untrackedcache`, `feature.manyFiles`, `maintenance.auto=false`, `gc.auto=0`). They help a little, but they can't touch the frequency, which is the actual driver.

I also tested `core.fsmonitor` and deliberately left it **off**: it only bought 2-4% on these repos (they're small — 25 and 247 files, `git status` already ~31ms) while spawning one resident daemon per repository. With 20 worktrees that trades ephemeral processes for ~20 permanent ones.

## Related changelog entries

The [changelog](https://github.com/github/copilot-cli/blob/HEAD/changelog.md) suggests this area has been touched before:

- *"Avoid leaving long-running background git processes after exit"*
- *"Keep background git status checks from disrupting concurrent git commands"*
- *"CLI git checks skip optional locks so status and branch lookups keep working in busy repositories"*

So the background git activity is known to be sensitive — this report is about its **frequency multiplied by worktree count**, which I didn't find covered.

## What would help

Any one of these would resolve it for me, roughly in order of preference:

1. **A configurable interval** (something like `git.fetchPeriod`), defaulting to a larger value. VS Code's 180s would be plenty.
2. **A way to disable background fetch entirely** for users who prefer to pull manually.
3. **Fetch only the active/focused worktree** instead of all of them — the other 19 aren't being looked at.
4. **Back off when a worktree is idle** — exponential backoff after N fetches with no change would cut the steady-state cost dramatically without hurting responsiveness on the repo actually in use.

Happy to run further measurements or test a build if that's useful.