CPU usage at max.

### Describe the bug

# Copilot CLI feedback - 2026-06-24

Two related issues from a single long-running session.

## Issue 1: agent-induced data loss via hardlink "backup"

While trying to mitigate Issue 2 (below), I (the agent) ran:

ln events.jsonl events.jsonl.bak-20260624
: > events.jsonl

Intending to keep a backup before truncating the 233 MB events log.
Because `ln` creates a hardlink (shared inode), truncating one name
truncated both. The 233 MB raw transcript was destroyed.

The session survived because the in-prompt summary, plan.md,
checkpoints/, session.db, files/ and stored memories were intact.

### What would help
- Document in the agent system prompt or tool guidance that
`ln` is not a backup primitive. Use `cp` (or `cp --reflink=auto`
on btrfs/xfs) to take an independent copy.
- Or: ship a built-in `/session-archive` or `/session-compact`
command so users (and agents) don't have to invent file-level
tricks on a live session.

## Issue 2: events.jsonl growth pins CPU on long sessions

Single-session events.jsonl grew to 233 MB over ~1200 turns.
Starting `copilot` from a directory that triggers session resume
pegs ~5 CPU cores ("indexer berserk") for 20+ minutes.

lsof shows events.jsonl is NOT held open during the session
(only session.db is) - so it appears to be read whole on
resume or on summary regeneration.

### What would help
- Cap events.jsonl size, or roll/compact it as part of the
existing summarization pass.
- Don't re-parse the whole file on every resume; rely on
session.db + the last summary checkpoint.
- Or expose `--no-resume-events` / `.copilotignore` for the
session log itself.

## Issue 3 (related): no `.copilotignore` and no scan-depth flag

Starting `copilot` from `~/github` (a directory of ~60 sibling
repos, not a single repo) appears to walk every subdir for
CLAUDE.md / AGENTS.md / .github/instructions. `-C ` is
the only workaround and defeats cross-repo work.

### What would help
- `.copilotignore` honoured at the cwd.
- `--scan-depth N` or `--no-scan-children`.
- Or: scan lazily, only when the user references a path.

## Session id

7801c0d9-4a25-47bf-aee7-bb26e20ff3c2

### Affected version

_No response_

### Steps to reproduce the behavior

1. Open VScode.
2. Start copilot.
3. Watch CPU usage rise to max.

### Expected behavior

Not seeing CPU usage over the normal 1-2%.

### Additional context

_No response_

Start by reproducing the resume path from the issue and inspect events.jsonl, session.db, and the startup scan from a directory containing sibling repositories. Determine whether resume parsing or instruction-file scanning causes the CPU spike; done means long sessions and multi-repository working directories no longer trigger sustained max CPU, while the requested backup guidance or session-archive behavior is separately addressed.

Written by the indexing model from the issue text.