Skip to main content

GitHub Copilot CLI Tips & Tricks — Part 2: Session management

In the first post we covered the different modes in Copilot CLI. This time we're looking at something that becomes essential once you're doing serious work in the CLI: session management. Sessions let you pause, resume, and organize your work — across terminal restarts, across machines, and across multiple concurrent workstreams.

What is a session?

Every time you launch Copilot CLI, you're working inside a session. A session captures your full conversation history, the tool calls Copilot made, the files it touched, and the permissions you granted — all stored locally under ~/.copilot/session-state/. Sessions are identified by a UUID and automatically receive an AI-generated name based on your first message, making them easy to identify later.

Most important is that sessions persist after you close the CLI. That means nothing is lost when you shut down your terminal — you can always pick up right where you left off.

Resuming a session

Pick up where you left off

The most important session management flag. When you launch with --resume, Copilot presents an interactive picker listing your saved sessions — searchable with / — so you can select the one you want to continue.

copilot --resume

All your conversation context, granted permissions, and history are restored exactly as you left them.

Jump straight back in

If you just want to resume your most recent session without going through the picker, use --continue:

copilot --continue

This is the fastest way back into an active workstream after a restart or a break.

Switch sessions without exiting

You don't have to exit the CLI to switch sessions. The /resume slash command lets you jump to a different session mid-conversation — it opens the same picker UI as --resume, without breaking your current terminal process.

/resume

This is particularly useful when you're juggling multiple features or bugs at the same time.

Naming and organizing sessions

By default, sessions are named based on your first message. But for longer-running workstreams, you'll want to give them meaningful names yourself.

Use the /session slash command to rename the current session:

/session rename "Upgrade to .NET 10"

Named sessions are much easier to find in the /resume picker, especially when you have several active workstreams going at once.


Monitoring your session

Check your token and request consumption

At any point during a session you can call /usage to see a summary of how much you've used:

  • Premium requests consumed in the current session
  • Session duration
  • Number of files modified

This is handy for keeping an eye on consumption during long autopilot runs.

Context window management

Copilot CLI automatically compresses your conversation history in the background as it approaches 95% of the token limit, without interrupting your work. If you want to trigger this manually — for example, after completing a big chunk of work and starting a new phase — you can use:

/compact

This keeps things lean for the next part of the task.


Use /session checkpoints #checkpointnumber to view the compaction summary.





Sharing and exporting sessions

Export to Markdown

The /share command exports the current session to a Markdown file, including the full conversation history, tool calls, and outputs. This is useful for documentation, handoffs, or just keeping a record of a complex debugging session.

/share

Copilot will write the session history to disk.




Publish to GitHub gist

For non-interactive use cases — like CI/CD pipelines or automated documentation — you can export a session directly to a GitHub Gist using the /share-gist slash command:

/share-gist

Copilot returns a URL to the created Gist, making it easy to share with teammates or link in a PR.

Wrapping up

Sessions are what make Copilot CLI feel like a persistent coding partner rather than a stateless tool. Once you get into the habit of naming sessions, using --continue to resume quickly, and switching between workstreams with /resume, it becomes a natural part of how you manage work in the terminal.

In the next post, we'll look at running tasks in parallel.

More information

Session State & Lifecycle Management | github/copilot-cli | DeepWiki

Session Management & History | github/copilot-cli | DeepWiki

Tracking GitHub Copilot's sessions - GitHub Docs

Popular posts from this blog

Kubernetes–Limit your environmental impact

Reducing the carbon footprint and CO2 emission of our (cloud) workloads, is a responsibility of all of us. If you are running a Kubernetes cluster, have a look at Kube-Green . kube-green is a simple Kubernetes operator that automatically shuts down (some of) your pods when you don't need them. A single pod produces about 11 Kg CO2eq per year( here the calculation). Reason enough to give it a try! Installing kube-green in your cluster The easiest way to install the operator in your cluster is through kubectl. We first need to install a cert-manager: kubectl apply -f https://github.com/cert-manager/cert-manager/releases/download/v1.14.5/cert-manager.yaml Remark: Wait a minute before you continue as it can take some time before the cert-manager is up & running inside your cluster. Now we can install the kube-green operator: kubectl apply -f https://github.com/kube-green/kube-green/releases/latest/download/kube-green.yaml Now in the namespace where we want t...

Azure DevOps/ GitHub emoji

I’m really bad at remembering emoji’s. So here is cheat sheet with all emoji’s that can be used in tools that support the github emoji markdown markup: All credits go to rcaviers who created this list.

Podman– Command execution failed with exit code 125

After updating WSL on one of the developer machines, Podman failed to work. When we took a look through Podman Desktop, we noticed that Podman had stopped running and returned the following error message: Error: Command execution failed with exit code 125 Here are the steps we tried to fix the issue: We started by running podman info to get some extra details on what could be wrong: >podman info OS: windows/amd64 provider: wsl version: 5.3.1 Cannot connect to Podman. Please verify your connection to the Linux system using `podman system connection list`, or try `podman machine init` and `podman machine start` to manage a new Linux VM Error: unable to connect to Podman socket: failed to connect: dial tcp 127.0.0.1:2655: connectex: No connection could be made because the target machine actively refused it. That makes sense as the podman VM was not running. Let’s check the VM: >podman machine list NAME         ...