Check GitHub Copilot CLI Context Compaction Summaries

To check GitHub Copilot CLI context compaction summaries, enter /session checkpoints inside an interactive Copilot session. The command lists saved checkpoints. Open one by adding its number, such as /session checkpoints 2, to read the full summary.

This is useful when Copilot starts revisiting a settled decision, forgets a restriction, or describes unfinished work as complete. Reading the saved summary gives you a specific record to examine before deciding what needs correcting.

Open the right session before checking its summary

Checkpoint inspection happens at the Copilot prompt. A slash command pasted into Bash, PowerShell, or another ordinary shell will not operate on your Copilot conversation.

If you have closed the CLI, run this in your terminal to choose a previous session:

copilot --resume

If Copilot is already running, use /resume to select the earlier conversation. Match the session to the task you want to investigate; two conversations about the same repository may contain different decisions.

You can also enter /session info to inspect the current session details. Record its identifier when keeping review notes, particularly if you are comparing similar sessions or preparing a reproducible problem report.

List checkpoints, then open the full content

Enter:

/session checkpoints

The list identifies checkpoints by number and title. Each completed compaction, whether automatic or manual, creates a saved summary. A title helps you locate a stage of work, but you need the full content to judge what survived.

For example, if checkpoint 2 appears in your list, open it with:

/session checkpoints 2

Replace 2 with a number shown in your own session. Start with the most recent checkpoint before the behavior you are investigating, then work backward if necessary.

These commands answer different questions:

Use the checkpoint viewer when your question is “What did the summary keep?” A context usage display answers a capacity question. Starting another compaction changes the context before you have finished reviewing the existing record.

Check whether the summary preserves the working agreement

Compaction condenses earlier conversation history so the session can continue. Exact wording and detailed command output may be absent. A checkpoint is therefore a summary to verify, rather than a complete transcript or a backup of repository files.

Ars Technica's explanation of coding agent context provides useful background on why compressed conversations can lose detail. For your own task, the practical question is whether the retained information is specific enough to support the next action.

Review these five areas:

1. Current objective: Does the summary describe the requested outcome? “Improve authentication” could hide a much narrower request to fix one timeout condition.
2. Boundaries: Look for constraints that affect edits, such as preserving a public API, avoiding new dependencies, or leaving unrelated configuration alone.
3. Decisions and rejected options: Check whether a discarded approach has accidentally become the next step. Keep the reason for a rejection when it still matters.
4. Work and verification: Separate files examined, changes made, tests actually run, and tests still pending. These are different states.
5. Next action: Confirm what remains to be done and which unresolved question must be answered first.

You do not need every earlier message reproduced. Concentrate on details whose loss would cause an incorrect edit, repeat an unsuccessful approach, or support an unjustified completion claim.

Look closely at completion claims

Consider this illustrative summary sentence:

The timeout fix is complete and tests passed.

That sentence leaves several questions unanswered. Which tests ran? Did they cover the changed behavior? Was the patch reviewed? Were integration tests skipped because a service was unavailable?

A more useful working note would be:

The retry delay was changed in the HTTP client.
The targeted unit test passed.
Integration tests have not run because the test service is unavailable.
Keep the public request signature unchanged.
Next: review the diff and report the integration-test limitation.

When correcting your own session, substitute facts you can verify from its output and current files. Keep any uncertainty explicit so the next action starts from an accurate account of the work.

Compare checkpoints to locate a missing decision

If the latest summary has an error, open an earlier checkpoint and search for the same fact. Compare one issue at a time: a file restriction, an agreed implementation choice, or the status of a particular test.

For example, an earlier checkpoint might say “keep the existing parser,” while a later one says “replace the parser.” Check the messages between those stages for an authorized change of direction. If there was none, you have a concrete discrepancy to correct.

Use the following distinctions when interpreting what you find:

• The detail appears earlier but disappears later: Investigate that transition and reintroduce the verified detail if it still applies.
• The detail is missing from both summaries: Check the original instruction or task record before attributing its absence to a particular compaction.
• The latest summary contains the correct detail: Inspect the subsequent request and applicable instructions. Later behavior alone does not establish that the summary lost the information.

Also compare the summary's timeline with your own. A decision made after a checkpoint was created cannot appear in that earlier snapshot. An accurate historical summary can become outdated as the work changes.

Keep a local copy for a closer review

To export the session conversation as Markdown, enter this at the Copilot prompt:

/share file copilot-session-review.md

Choose a filename suitable for the session. The explicit file argument requests a local export; bare /share creates a shareable session link on GitHub.

Use the exported conversation to examine instructions, responses, and the sequence of work. For the exact compaction summary, retain a copy of the checkpoint content you opened. The conversation export should not be treated as a guaranteed backup of every checkpoint file.

In your review notes, record the session ID, checkpoint number, disputed statement, and the evidence supporting your correction. This keeps a report useful even when several sessions involve similarly named files.

Where local checkpoint files live

GitHub documents session workspaces under ~/.copilot/session-state/{session-id}/. The checkpoints/ directory holds compaction history, while events.jsonl contains session history. The ~ represents your home directory, and {session-id} must match the session you are inspecting.

The default configuration root is ~/.copilot. If you configured COPILOT_HOME, check that location instead. Inspect the actual directory contents before selecting a file; do not assume a checkpoint filename from an example found elsewhere.

Use a text editor to inspect a copy when you need a detailed comparison. These are CLI-managed records, so manually rewriting or deleting them is an unnecessary complication for a reading task.

What to do when no checkpoints appear

First confirm that you selected the expected session. Then consider whether a compaction has actually completed there. A short conversation may have no checkpoints yet, and an in-progress operation is different from a saved result.

If the command is unrecognized, open /help in the CLI and check the commands available in your installation. You can record its version from your ordinary terminal with:

copilot --version

This helps distinguish a command-availability problem from an empty history. Follow the update instructions for your installation method if your version lacks the documented feature. Deleting local session data would remove evidence you may still need.

A missing local folder also deserves an environment check: are you using the same computer, user account, and configuration directory where that session ran? Resolve the location question before assuming the summary was lost.

Correct missing details before continuing work

Once you identify an omission, give Copilot a short factual correction. Include the active objective, the missing restriction, and the next action. Avoid pasting an entire large transcript when a few verified statements will resolve the issue.

For example:

Correction for the current task:
- Fix the HTTP client's retry timing only.
- Preserve its public function signature.
- Unit tests passed; integration tests have not run.
- Review the current diff before making further edits.
Summarize these constraints and the next step before continuing.

The distinction between task, constraints, and requested response is also useful in structured prompting techniques. Here, that structure makes the correction easier to inspect. Check the acknowledgment, then verify the resulting actions against the actual files.

For recurring repository rules, Copilot CLI supports .github/copilot-instructions.md. Keep permanent conventions there and temporary progress notes elsewhere. Use /instructions to inspect discovered instruction files and check for conflicts. GitHub notes that edits to instruction files require exiting and resuming, or starting a new session, before they become available to the active CLI session.

A completed compaction cannot be reversed. Supplying a correction repairs the information available for subsequent work; it does not restore the previous context window. Save any useful evidence before deciding to move to a fresh conversation.

Frequently asked questions

Can I inspect an older checkpoint instead of the newest one?

Yes. Choose its number from the checkpoint list. An older summary is useful when you need to understand an earlier decision, but check whether later work superseded it before reusing its instructions.

Does low context usage mean the summary is accurate?

No. Capacity and accuracy are different questions. A short summary can omit an important restriction or describe a test result incorrectly. Compare the relevant statements with evidence from the task.

Should I run another compaction to recover a missing detail?

First recover the detail from a reliable record and supply it explicitly. Asking for another summary without correcting the underlying information gives you no reason to expect the omitted fact to reappear.

Can a checkpoint tell me whether the code is correct?

It can tell you what the session summary says about the code. Evaluate that claim using the current diff, relevant tests, and any remaining verification limits. A written completion claim is not a substitute for those checks.

Before continuing a long session, open the checkpoint closest to the issue and verify one decision that matters to the next action. If it is wrong or incomplete, supply the correction and confirm the next step before more edits accumulate.