Copilot Agent built-in list_dir returns unbounded output for large directories and freezes/poisons the chat session
- Dominant language
- TypeScript
- Stars
- 193k
- Forks
- 42.4k
- PR merge metrics
- PR metrics pending
Description
- Copilot Chat Extension Version: GitHub Copilot Chat built-in extension version `0.52.0`
- VS Code Version: `1.124.2`
- VS Code Commit: `6928394f91b684055b873eecb8bc281365131f1c`
- VS Code Architecture: `arm64`
- OS Version:
- Local client: macOS / Darwin `24.1.0` arm64
- Remote tunnel host: Rocky Linux 9.6 / Linux
- Remote setup: VS Code connected to a remote machine through a VS Code Tunnel
- Feature: Agent mode, built-in filesystem tool `list_dir`
- Selected model: GPT-5.5, BYOK
- Logs: attached below
## Summary
Copilot Agent's built-in `list_dir` tool appears to return an unbounded directory listing for very large directories. If the directory contains tens of thousands of files, the full list is inserted into the chat/tool history. After that, the chat session becomes extremely slow or frozen. Reloading the window temporarily recovers the UI, but continuing the same contaminated chat can reproduce the slowdown, which continues even after tools are later disabled, suggesting the oversized `list_dir` result has already poisoned the chat context.
This is problematic in workspaces where dataset directories may contain tens or hundreds of thousands of files, and Agent mode may choose `list_dir`.
## Concrete case
The directory that triggered this contains 87,348 entries. Agent debug view showed a built-in tool call like:
```
list_dir {
"path": "path/..."
}
```
The response contained a very large list of filenames like:
```
HR00001-0.jpg
HR00001-0.png
HR00001.dat
HR00001.hea
HR00002-0.jpg
HR00002-0.png
HR00002.dat
HR00002.hea
...
```
After this, the chat and the window became extremely slow. UI animations still ran, but actions requiring server or extension-host communication stalled and then occasionally flushed all at once.
Steps to Reproduce:
1. Open a VS Code workspace through a Remote Tunnel
2. Have a dataset directory visible/readable to Agent with ~100k files
3. Ask Agent to start work involving the dataset
4. Agent autonomously calls the built-in list_dir tool on the large dataset folder
5. The list_dir response injects the large directory listing into chat context
6. The chat session becomes extremely slow and/or freezes. The bad performance persists even after stopping the chat. Reloading window fixes the freeze.
The issue also persisted in the old chat even when I later disabled all tools, suggesting the oversized context contaminating the session.
## Relevant log excerpts
Before identifying the exact list_dir problem, the affected chat showed large Agent rendering/tool/context setup:
```
[debug] [Agent] rendering with budget=228333 (baseBudget: 272000, toolTokens: 18296, totalTools: 85, toolSearchEnabled: false), summarizationEnabled=true
[trace] Re-rendering historical user message without frozen content; using minimal body
```
After disabling tools, the old contaminated chat was still slow and still involved history rendering:
```
[debug] [Agent] rendering with budget=244159 (baseBudget: 272000, toolTokens: 712, totalTools: 2, toolSearchEnabled: false), summarizationEnabled=true
[trace] Re-rendering historical user message without frozen content; using minimal body
[debug] request.response: [{"type":"ChatCompletions"}], took 9706 ms
[info] ccreq:4f77ef2c.copilotmd | success | gpt-4o-mini-2024-07-18 | 9721ms | [progressMessages]
[info] ccreq:766b959c.copilotmd | success | gpt-4o-mini-2024-07-18 | 9725ms | [progressMessages]
```
In contrast, a new chat without the contaminated tool history responded normally.
Contributor guide
Assessment
This issue has not been assessed yet.