-
Notifications
You must be signed in to change notification settings - Fork 1.7k
CPU usage at max. #3907
Copy link
Copy link
Open
Labels
area:configurationConfig files, instruction files, settings, and environment variablesConfig files, instruction files, settings, and environment variablesarea:context-memoryContext window, memory, compaction, checkpoints, and instruction loadingContext window, memory, compaction, checkpoints, and instruction loadingarea:sessionsSession management, resume, history, session picker, and session stateSession management, resume, history, session picker, and session state
Description
Metadata
Metadata
Assignees
Labels
area:configurationConfig files, instruction files, settings, and environment variablesConfig files, instruction files, settings, and environment variablesarea:context-memoryContext window, memory, compaction, checkpoints, and instruction loadingContext window, memory, compaction, checkpoints, and instruction loadingarea:sessionsSession management, resume, history, session picker, and session stateSession management, resume, history, session picker, and session state
Type
Fields
Give feedbackNo fields configured for Bug.
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:
Intending to keep a backup before truncating the 233 MB events log.
Because
lncreates a hardlink (shared inode), truncating one nametruncated 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
lnis not a backup primitive. Usecp(orcp --reflink=autoon btrfs/xfs) to take an independent copy.
/session-archiveor/session-compactcommand 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
copilotfrom a directory that triggers session resumepegs ~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
existing summarization pass.
session.db + the last summary checkpoint.
--no-resume-events/.copilotignorefor thesession log itself.
Issue 3 (related): no
.copilotignoreand no scan-depth flagStarting
copilotfrom~/github(a directory of ~60 siblingrepos, not a single repo) appears to walk every subdir for
CLAUDE.md / AGENTS.md / .github/instructions.
-C <repo>isthe only workaround and defeats cross-repo work.
What would help
.copilotignorehonoured at the cwd.--scan-depth Nor--no-scan-children.Session id
7801c0d9-4a25-47bf-aee7-bb26e20ff3c2
Affected version
No response
Steps to reproduce the behavior
Expected behavior
Not seeing CPU usage over the normal 1-2%.
Additional context
No response