microsoft / microsoft/vscode

Copilot agent hangs mid-task with no progress and no user-visible output (worked around by killing the VS Code application)

Open
#327,886 0 comments 1 reaction 1 assignee Claimed by @roblourens View on GitHub
Dominant language
TypeScript
Stars
193k
Forks
42.4k
PR merge metrics
PR metrics pending

Description

Does this issue occur when all extensions are disabled?: No as Github copilot Extension is being used

- VS Code Version: Version: 1.130.0 (user setup)
Commit: 1b6a188127eeaf9194f945eb6eb89a657e93c54c
Date: 2026-07-22T14:55:04Z
Electron: 42.6.0
ElectronBuildId: 14623276
Chromium: 148.0.7778.280
Node.js: 24.18.0
V8: 14.8.178.38-electron.0
OS: Windows_NT x64 10.0.26200
- OS Version: 25H2 (OS Build 26200.8894)

**Describe the bug**
The Copilot agent (workspace chat, agent mode) accepts a long, well-scoped refactor task, emits a short acknowledgement, then goes silent for 10–15 minutes at a time. During the silent periods:

No tool calls are visible in the conversation.
The user cannot tell whether the agent is computing, waiting on a tool result, or simply stalled.
The agent is unresponsive: typing a follow-up does not interrupt it; the only way to recover is to close the VS Code window by hand.
Closing and reopening the window does not produce any error or "I died" message from the agent.
This was reproduced four times in a single session on 2026-07-28 while doing performance work on a Python file (~1,100 LOC). The agent had previously produced three good commits in the same session, then started hanging on the next batch of edits.

**To Reproduce**

1. Open a workspace with a non-trivial Python file (≥1,000 LOC).
2. Open Copilot Chat, switch to Agent mode.
3. Give the agent a multi-step refactor task with at least 5–10 distinct edits across one file, e.g. "implement the P2.5 polish items from this plan: replace every tree.insert(parent, tk.END, text=…, tags=("fstag",), image=…) call with self._insert(parent, …, …)."
4. Watch the agent emit one short status update, then go silent.
5. Wait 10–15 minutes. The agent emits no further output.
6. Try typing a follow-up message in the chat box. Nothing happens.
7. The only way out is File → Exit (or kill the window). On reopen, the chat history shows the agent died mid-turn with no error.

**Expected behaviour**
A heartbeat. A user-visible status line at least every 30–60 seconds while the agent is working, saying either "reading X", "running Y", or "thinking about Z". If the agent is doing pure reasoning with no tool call, it should say so explicitly.
Interruptible. Typing in the chat box during a long agent turn should cancel or at least acknowledge the user. Currently typing is silently swallowed.
Visible tool calls. Every tool invocation should appear in the conversation transcript immediately, not after a long delay.
A clear failure mode. If the agent genuinely cannot make progress (e.g. tool returned an error and the agent is stuck in a retry loop), it should emit a single "I cannot make progress because X" and stop, rather than silently spinning.
Actual behaviour
The agent emits a multi-paragraph "status update" that reads as scratchpad reasoning, then either:

Stops calling tools entirely. The chat sits there, the agent is unresponsive, and the user has to kill the window.
Begins a long sequence of read_file calls on sections of a file it has already read in the same session. Each read returns hundreds of lines, which the agent then re-parses before deciding what to do next. From the user's point of view, the conversation is silent for the duration of these reads.
Emits "let me think" / "let me check" paragraphs with no subsequent tool call. The chat sits there, again silently.
In all three cases, the only feedback the user gets is the multi-paragraph status update. There is no progress bar, no spinner, and no indication of which tool is currently running.

Four hangs in a single session.

**Workaround**
The only reliable workaround is to write the bulk edit as a one-shot Python script and ask the agent to run it in the terminal. This collapses N tool calls into one, sidesteps the replace_string_in_file round-trips that trigger the hangs, and finishes in well under a second. The agent can do this in a single tool call and see the diff in the next.

The user ended up running the script by hand because they could no longer trust the agent to finish anything. This is the right outcome but the wrong reason: the user should not have to do the agent's work.

**Suggested fix areas**

1. Per-turn watchdog. The agent loop should emit a "still working" status to the user at least every 30 seconds, even if there is no new content. If the agent is doing pure reasoning with no tool call, it should say so.
2. Re-reading detection. If the agent issues a read_file for a path it has already read in the same session, that should be either blocked or surfaced in the UI as a "re-reading X (already in context)" warning, not silently executed.
3. Tool-call batching. The agent should be strongly encouraged (or forced) to batch independent reads into a single parallel call. The current behaviour produces a long sequence of round-trips that the user sees as a hang.
4. Interruptible agent turns. Typing in the chat box during a long turn should at minimum be acknowledged, ideally cancel the current turn and inject the user's message.
5. A spinner / progress bar in the chat panel while the agent is working. Currently the chat panel looks identical when the agent is working and when it is stuck.

Contributor guide

Open the contributing guide

Assessment

This issue has not been assessed yet.

Get new issues in your inbox

A short digest of beginner-friendly GitHub issues.