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_

まず issue に記載された再開パスを再現し、events.jsonl、session.db、および兄弟リポジトリを含むディレクトリに対する起動時スキャンを調査します。CPU スパイクの原因が再開処理なのか、指示ファイルのスキャンなのかを特定します。長時間のセッションや複数のリポジトリを含む作業ディレクトリで CPU 使用率が継続的に最大になることがなくなれば完了とし、要求されたバックアップのガイダンスまたはセッションアーカイブの動作については別途対応します。

索引モデルが issue の本文から書いたものです。