Skip to content

Runaway copilot-file-search thread consumes CPU and unbounded disk while session is idle #4710

Closed
Bug
Closed
Runaway copilot-file-search thread consumes CPU and unbounded disk while session is idle#4710
Bug
Labels
area:sessionsSession management, resume, history, session picker, and session statearea:toolsBuilt-in tools: file editing, shell, search, LSP, git, and tool call behavior

Description

@mmazur
mmazur
opened on Sep 3, 2026

Version: GitHub Copilot CLI 1.0.83-3 on Ubuntu 24.04

Summary

While a copilot --yolo session reports its status as idle, an internal copilot-file-search thread can continue running indefinitely, pinning a CPU core and writing an unbounded per-process diagnostic log under ~/.copilot/logs/ until the disk fills to 100%.

Observed behavior

  • The session's foreground process stays alive and its reported status is idle, but the process is not actually idle at the OS level.
  • The internal copilot-file-search thread crawls/indexes the working directory at ~50% CPU and does not stop on its own.
  • The per-process diagnostic log in ~/.copilot/logs/ grows continuously — observed rates around 8 MiB per 10 seconds — with no apparent size cap or rotation. Individual logs reached 6–22 GB before intervention.
  • On large or deeply nested directory trees, the crawler appears to get stuck (repeated traversal, symlink-loop-like behavior) rather than completing and going quiet.

Impact

  • Root filesystem exhaustion (reached 100% used in the worst case), which affects the whole machine, not just the session.
  • Sustained CPU consumption for an ostensibly idle session.

Reproduced

Seen multiple times in a 24h span, all with the identical signature: idle status + active copilot-file-search thread + a continuously growing diagnostic log under ~/.copilot/logs/. Killing the process is the only thing that stops it; the log then has to be deleted manually to reclaim space.

Expected behavior

  • File-search/indexing should terminate (or throttle) when the session is idle.
  • The crawler should detect and break traversal loops instead of looping indefinitely.
  • Diagnostic logs should be size-capped or rotated so a single session cannot exhaust the disk.

Activity

  1. github-actions
    added
    triage
    on Sep 3, 2026
  2. copilot-cli-bot
    added
    area:sessionsSession management, resume, history, session picker, and session state
    area:toolsBuilt-in tools: file editing, shell, search, LSP, git, and tool call behavior
    and removed
    triage
    on Sep 4, 2026
  3. copilot-cli-bot
    added the
    Bug
    issue type on Sep 4, 2026

  4. mmazur commented on Sep 4, 2026

    @mmazur
    mmazur
    on Sep 4, 2026
    Author

    This is happening multiple times a day. I need to be on the lookout all the time.

  5. godlytalias commented on Sep 25, 2026

    @godlytalias
    godlytalias
    on Sep 25, 2026

    I can reproduce this signature on native Windows 11 with Copilot CLI 1.0.88, in an Agency-launched interactive session that appeared idle.

    Environment

    • Copilot CLI: 1.0.88
    • OS: Windows 11 x64
    • CPU: Intel Core i7-13800H, 20 logical processors
    • Launch context: Agency, with -C <home-directory>
    • Session uptime at capture: about 6 hours

    Process measurements

    • Sustained Copilot CPU over a 15-second sample: 31.7% of the whole 20-logical-processor system (roughly 6 logical cores)
    • Working set/private memory: ~1.2 GiB
    • Threads: 99
    • Cumulative CPU time: 108,092 seconds
    • Hot-thread sample included a continuously runnable thread at ~49% of one core plus additional active runtime workers
    • Session state JSONL and SQLite WAL did not grow during an idle observation window

    File-search/log evidence

    The per-process debug logs continued rotating while the session was otherwise idle:

    process-...-59916.4.log  10,162,040 bytes  20:56:53
process-...-59916.3.log  10,349,395 bytes  20:57:27
process-...-59916.2.log  10,460,379 bytes  20:57:58
process-...-59916.1.log  10,443,052 bytes  20:58:31
process-...-59916.log     5,482,736 bytes  20:58:48 (still growing)

    Relevant sanitized excerpts repeatedly show the workspace crawler walking a large repository and generated build trees below the home directory:

    [DEBUG] [rust:workspace_file_search::crawl] workspace file search crawl skipped entries
first_error="<home>\\Application Data: Access is denied. (os error 5)"

[DEBUG] [rust:log] whitelisting <home>\\.github\\<large-repository>\\...\\obj\\x86\\Debug\\<generated-file>
log.target="ignore::walk"

    The CLI was launched at the home-directory level, so the crawler traversed multiple repositories, OneDrive content, generated obj trees, and Windows compatibility junctions. Changing to a narrow repository workspace is an effective workaround, but an idle crawler should still terminate/throttle and should not produce approximately 10 MiB of debug logs every 30 seconds.

    This appears to confirm that #4710 also affects current native-Windows builds, not only Linux/Ubuntu. I have not attached the raw logs because they are large and contain local paths, but can provide a scrubbed diagnostic bundle if maintainers need one.

  6. mmazur commented on Oct 29, 2026

    @mmazur
    mmazur
    on Oct 29, 2026
    Author

    Stopped reoccurring the past few weeks, must've fixed it in recent releases.

  7. mmazur
    closed this as completedon Oct 29, 2026
Sign up for free to join this conversation on GitHub. Already have an account? Sign in to comment

Metadata

Metadata

Assignees

No one assigned

    Labels

    area:sessionsSession management, resume, history, session picker, and session statearea:toolsBuilt-in tools: file editing, shell, search, LSP, git, and tool call behavior

    Type

    Bug

    Projects

    No projects

      Milestone

      No milestone

      Relationships

      None yet

      Development

      No branches or pull requests

      Issue actions