Why GitHub Copilot CLI Pauses During Automatic Context Compaction

GitHub Copilot CLI pauses during automatic context compaction when its conversation is filling faster than the background summary can finish. GitHub documents a typical background trigger around 80% of the context window. If usage approaches 95% while that work is unfinished, the CLI waits before continuing. A short pause at that point can be expected behavior.

A session that never recovers needs a different investigation. The delay might involve a failed summary request, the next model response, or an unrelated command still running. My recommendation is to identify which stage stopped before clearing the conversation or restarting anything.

Why background compaction can still interrupt your work

The context window is the model's limited working space, measured in tokens: pieces of text rather than a count of files or minutes. Prompts, replies, instructions, tool definitions, and tool results all compete for that space.

Compaction asks the model to summarize earlier work, then substitutes that summary for older conversation content. It aims to retain the goal, important decisions, relevant files, and next steps. New messages received during background compaction are kept. Detailed logs and the exact wording of earlier exchanges may not survive in the active context.

Background processing gives the current task some room to continue. That room is finite, however. A large search result or a sequence of file reads can consume it before the summary is ready. The pause lets the summary catch up.

The starting threshold is not always exactly 80%. GitHub's current usage guide describes a later trigger, closer to 90%, when static system and tool context already occupies roughly 75% or more of the window. Summarizing conversation messages can reclaim less space in that situation.

The useful question is therefore not simply, “Why did it stop?” Ask, “Was it still summarizing, had it moved to another model request, or was a tool waiting?” Those three situations can look similar in a quiet terminal but require different responses.

Normal pause, stalled summary, or something else?

I would use this table as a diagnostic starting point. None of these observations proves a cause on its own.

There is no documented universal duration that makes every compaction healthy or broken. A fixed rule such as “kill the process after 30 seconds” would be misleading. Look for completion messages, fresh tool output, an explicit error, or a repeatable failure pattern.

Also check the named operation. A package installation waiting for input and a summary request waiting for a model response are different problems. If a command is responsible, investigate that command rather than repeatedly compacting the conversation.

What reported hangs tell us—and what they do not

Real compaction-related failures have been reported in the Copilot CLI issue tracker. One report, issue #4138, describes version 1.0.71-2 becoming unresponsive after resuming a session and receiving empty responses during background compaction. That is a reported failure in a particular environment, not evidence that every pause has the same cause.

A separate report, issue #1614, describes a delay after compaction had already completed. The reporter associated the subsequent model request with a prompt-cache miss. That distinction matters: the last visible compaction message can be near the delay without identifying the stage that is currently slow.

I would use those reports to decide what evidence to collect, rather than copying their proposed workarounds automatically. Note whether your last successful event was a file read, a completed summary, or a model response. Then compare the error and version, not just the word “stuck.”

For broader perspective on how these tools behave during real tasks, this AI terminal comparison discusses Copilot alongside other command-line assistants. Its older observations are useful background, but they do not establish the cause of a failure in your current installation.

How I would recover a Copilot CLI session that keeps pausing

1. Preserve the current work and record the symptom

Before interrupting anything, note the visible status, the last completed operation, and whether there is an unanswered prompt. If possible, copy the exact error rather than paraphrasing it as “Copilot froze.”

Keep editor changes saved. If the project uses Git, inspect its working tree from a separate terminal:

git status --short
git diff --stat

These checks help you understand the state you would return to. They do not capture every kind of work: untracked files, staged changes, and unsaved editor buffers deserve separate attention. Avoid a reset, cleanup, or deletion merely to make the status output look tidy.

I would also avoid starting another editing agent in the same working tree while the first may still be active. A read-only investigation is easier to interpret than two processes making overlapping changes.

2. Inspect the context when the prompt is responsive

Inside Copilot, run:

/context

Look beyond the overall percentage. Is the large component conversation history, custom instructions, or tool definitions? If the history dominates, a summary may help. If the starting configuration dominates, repeatedly summarizing the same small amount of conversation is less promising.

Record the active model and available capacity. Do not assume the CLI exposes the same window as another product using a similarly named model.

3. Check the installed version before chasing old bugs

From your normal shell, use:

copilot --version

There is a concrete reason to check. The September 30, 2026 release notes for version 1.0.90 include a change intended to make compaction return a summary even when instructions ask for tool use. Other releases have addressed failures around compaction boundaries and session recovery.

That does not mean this particular fix explains your pause. It means troubleshooting an older build against today's expected behavior can send you in the wrong direction.

After preserving work and ending the active operation, the current command reference provides:

copilot update

For a centrally managed installation, follow its approved update process. Copilot CLI can also be installed through npm, WinGet, Homebrew, or a standalone installer, so avoid creating a second installation just to troubleshoot the first. Verify the version again in the terminal you actually use.

4. Read the failure evidence

If the session accepts commands, request a focused diagnosis:

/diagnose Investigate the pause around the latest context compaction. Identify the last completed stage and any subsequent errors.

Treat its explanation as a lead to check against the log. A useful diagnosis points to an event, error, or sequence. An unsupported guess about your network or model is not enough.

By default, logs are under ~/.copilot/logs/, while session history and workspace data are under ~/.copilot/session-state/. A configured COPILOT_HOME changes the base location. Preserve these records before attempting cleanup.

For a controlled reproduction, the CLI supports debug logging:

copilot --log-level=debug

This starts a CLI process; it does not automatically diagnose or resume the original session. Use a small, non-destructive task first. Compare whether the failure occurs only with the old conversation or also with a fresh one.

When reviewing logs, separate a failed compaction request from a failed tool connection, authentication problem, or explicit rate-limit response. Follow the actual error. Increasing context capacity will not repair an authentication failure, and changing a prompt will not answer a pending permission request.

5. Interrupt carefully, then resume or hand off

If progress has stopped and you need control back, use the interface's cancel action. The current CLI documents Esc for cancellation and a second press for interrupting a running turn. Cancelling work does not guarantee that earlier file edits or external effects have been undone.

Once responsive, inspect the project state before asking the agent to continue. Resume an existing conversation with /resume inside the CLI or copilot --resume from the shell.

If reopening the same history repeatedly reproduces the failure, I would stop retrying that path and create a small handoff. Include the intended result, relevant files, verified progress, unresolved error, and next action. Preserve the old session for investigation.

For example, a handoff for an unfinished settings change could say:

Continue investigating the settings save failure. First inspect the current diff and the existing settings tests. Preserve the public save API and all pre-existing edits. The previous session stopped during context management; do not assume its last test completed. Identify the remaining failure before changing more files.

Adapt that wording to the actual task. The valuable part is the separation between confirmed progress and work that may have been interrupted.

How to reduce repeated compaction interruptions

Ask for the evidence needed for the next decision

A debugging task rarely needs every log line in the main conversation. Ask for the failing command, relevant error section, and surrounding code first. Expand the investigation when those details are insufficient.

For example, replace “read every file and explain the whole project” with “locate the settings save handler, inspect its callers, and identify the failing path.” This is my preferred approach because it gives the investigation a testable direction without preventing necessary follow-up reads.

For noisy commands, save complete output in a file and ask the agent to extract the relevant failure. Keep the original evidence available so a short summary can be checked.

Keep permanent guidance concise and active

Put durable project conventions in a supported instruction file such as .github/copilot-instructions.md. Use /instructions to inspect what the session discovered. Applicable instruction files are combined, so resolve contradictions instead of adding the same rule more emphatically.

GitHub also documents that instruction-file edits do not immediately update active sessions. Apply them through the documented restart/resume or new-session workflow before judging whether a change helped.

If rules appear to disappear after long conversations, this guide to forgotten project instructions helps separate loading problems from failures to follow a rule. I would check that distinction before assuming compaction erased everything.

Use manual compaction at a useful task boundary

When the same task is continuing, manual compaction can move the interruption to a more convenient moment. Current versions accept focus instructions:

/compact Preserve the current objective, API constraints, changed files, verified test results, and next unresolved step.

This is an organizational choice, not a guaranteed speed improvement. It still requires a summary, and it will not cure a failing summarization request. I would use it after a completed investigation phase, when the next step is clear, rather than repeatedly running it during a stall.

Start a fresh conversation when the task changes

Use /new for a genuinely separate job. Keep a short handoff when unfinished work must carry over. Bringing yesterday's unrelated debugging history into a new task gives the assistant more material to sort through without necessarily helping it decide what to do.

If you also use Claude Code, the compact versus restart guide explores that decision in its own interface. Apply product-specific commands and thresholds separately; similar terminology does not make every tool's behavior identical.

Check continuity after the pause ends

A responding terminal is only the first sign of recovery. Check whether the assistant is continuing the correct task with the correct constraints.

Copilot's session tools let you inspect compaction checkpoints:

/session checkpoints

To inspect an entry, supply its displayed number, for example:

/session checkpoints 2

Use a number that actually appears in your session. A checkpoint exposes the saved summary; it is not a restore point for every repository change. You can also inspect an existing plan with /session plan.

Before permitting another broad edit, ask for a brief restatement of the goal, important restrictions, and next action. Compare that answer with the real files and your intended outcome. If a detail is missing, supply the specific correction and relevant file instead of pasting the entire earlier transcript.

Finally, verify the work itself. If a test was interrupted, rerun the relevant test when appropriate. If an operation may have changed an external system, inspect that system before repeating the operation. A confident summary cannot establish that an unfinished action succeeded.

Frequently asked questions

Does a compaction pause mean my Copilot usage allowance is exhausted?

Not by itself. Context capacity and account usage are separate things. Check /usage and any explicit allowance or rate-limit message before diagnosing a billing-related interruption.

Will a larger context window stop compaction?

It may leave more room for a given workload, but it does not remove the need to manage a growing conversation. Check the capacity shown by your actual session and whether unnecessary material is filling it.

Should I keep sending “continue” while it is compacting?

I would avoid repeated prompts until the status changes or an error identifies the problem. Repeating the request provides little diagnostic information and can make your intended next action less clear.

Should I delete the Copilot configuration folder to fix a hang?

No, that is a poor first step. The folder contains configuration and session data as well as logs. Preserve the evidence, identify the failing stage, and test a fresh session before considering any targeted cleanup.

What should I include in a useful bug report?

Include the CLI version, operating system, selected model, whether the session was new or resumed, the last successful operation, exact error, and minimal reproduction steps. Add a relevant log excerpt after reviewing it for credentials, private code, and other sensitive data.

Choose the next step from the observed failure

If compaction finishes and the task continues correctly, keep working. If it repeatedly fails, record the version and error, inspect the logs, and recover through a preserved session or a concise handoff. If it keeps returning without a clear error, inspect what the task is loading.

On your next occurrence, capture the last completed stage before changing anything. That one detail is more useful than repeatedly restarting and hoping the pause disappears.