CLI session hangs after task completion (intermittent)

[BonoJovi]

Describe the bug

Tasks sometimes complete successfully but the CLI session hangs without returning control to the user. This makes it difficult to determine whether a task is still in progress or has already finished.

Observed behaviors:

• Sometimes tasks complete and return control normally
• Sometimes tasks complete successfully but the session hangs/freezes
• The user has to manually check if the work was actually completed

Example case: When editing res/tests/TEST_DESIGN.md, the file was fully edited and complete (501 lines, properly structured from beginning to end), but the CLI session did not return control to the user. The task appeared to be "stuck" even though all work was done.

Affected version

0.0.350

Steps to reproduce the behavior

1. Start an interactive Copilot CLI session
2. Request a task that involves file editing or other operations
3. Wait for task completion
4. Observe that sometimes the CLI returns control, sometimes it doesn't despite the task being complete

Expected behavior

The CLI should consistently return control to the user after task completion, regardless of the task type or result.

Additional context

• Operating System: Linux
• The issue is intermittent - same types of tasks sometimes complete normally, sometimes hang
• When hanging occurs, the actual work is completed successfully
• This creates uncertainty about whether to wait longer or check manually

[EvanBoyle]

Definitely want to get this fixed! It would be really helpful if you could share a screenshot of the CLI when this repro'd, or even better steps for a consistent minimal repro along with debug logs (run the cli with --log-level debug and then find the logs in `~/.copilot/logs

[BonoJovi]

Regarding the debug logs and screenshots, understood. Since this issue simply involves a time-consuming process, it's unclear whether waiting will resolve it, and it's not reproducible. I'll report back if I can reproduce it again.

[colin-hallmark]

I've been experiencing this as well on MacOS, most recently today on version 0.0.351. I also noted that cancelling failed and was hung up as well. It's very intermittent, I think we'll have trouble giving regularly reproducible steps.

[BonoJovi]

The freeze occurred again just now. Checking the Copilot CLI debug logs, it appears the processing itself completed normally. However, I should note that the process does not return, and even when canceled, the cancellation process itself does not complete. Incidentally, no error is displayed on the screen; it just keeps showing “Thinking.” When canceled, it similarly keeps showing “Cancelling.”

session-3dbe9501-fa55-486d-be04-88ee52b2803f.log

[BonoJovi]

Regarding task freezes, I believe I've identified one possible cause. In cases where tasks freeze, the logs show multiple tool call counts, like “Tool calls count: 3”. It appears parallel processing is running, but subsequent logs only show “Processing operation” being output twice. Although it eventually outputs “Operation completed”, it seems the remaining tool call is left hanging in the queue without being processed. This might be the cause of the task freeze.

[valeriancure]

Regarding task freezes, I believe I've identified one possible cause. In cases where tasks freeze, the logs show multiple tool call counts, like “Tool calls count: 3”.

I can relate to this, as I also observed frequent freezes last week, but none since using --disable-parallel-tools-execution. I update to the latest version regularly, so I can’t say for sure whether it’s directly related.

Also, I’ve noticed that the parallel tools sometimes execute in an inconsistent order (for example, stage+commit before edit instead of edit before stage+commit), but that should probably be a separate issue.

[vukelich]

I've noticed this issue happens when:

• I've opened a new session with empty permissions for the CLI
• Parallel tool calling is enabled by default
• A prompt loop causes parallel tool calling for editing multiple files (usually more than three) with each parallel file edit bringing up the trio of user-in-the-loop choices of file editing the file (1 - yes, 2 - yes and all file edits this session, 3 - no, tell copilot what to do).
• I select option "2 - yes and all files edits this session" for each file that I'm prompted for

From my experience it seems that the final file edit in this flow doesn't pop its consent, and that causes everything to get stuck. The user using Esc causes "Canceling" to sit there with the cancellation seemingly not flowing to the final parallel file edit operation pending.

I tried reproducing this while running with --log-level debug on Version 0.0.354 Commit 076bd172b, but I haven't been successful to capture it. Just unlucky since I do get it to happen without.

[afk-x]

if anyone still have this issue the solution is: kill all zombie node process and increase the watchers to maximum