CPU usage at max.
- Linguagem predominante
- Shell
- Estrelas
- 11.2k
- Forks
- 1.9k
- Merge médio
- 14h 16min
- PRs com merge (30d)
- 6
Descrição
### 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_
Guia de contribuição
Direção de pesquisa
Comece reproduzindo o caminho de retomada da issue e inspecione events.jsonl, session.db e a varredura de inicialização de um diretório que contém repositórios irmãos. Determine se a análise da retomada ou a varredura de arquivos de instruções causa o pico de CPU; considera-se concluído quando sessões longas e diretórios de trabalho com vários repositórios não provocarem mais uso sustentado da CPU no máximo, enquanto a orientação de backup solicitada ou o comportamento de arquivamento de sessões é tratado separadamente.
Escrita pelo modelo de indexação a partir do texto da issue.
Avaliação
- Domínio
- cli, performance
- Tipo de issue
- Bug
- Dificuldade
- 4/5
- Tempo estimado
- 3-5 dias
- Status de atividade
- Pouca atividade
- Clareza
- Precisa de esclarecimento
- Facilidade para iniciantes
- 28/100