Clearing GitHub Copilot CLI context between tasks
On this page2 sections ▾
I found that long Copilot CLI sessions sometimes started bringing assumptions from earlier tasks into later work. When I moved to a different task, clearing the conversation and giving it a fresh brief helped me keep the request focused.
I was using claude-sonnet-4.5 through my copilot_yolo wrapper for Copilot CLI. Inside an interactive session, I used /clear to start a new conversation. This clears conversational context; it doesn't undo the files the agent has changed. GitHub's command reference lists the command.
(copilot) /clearI use that at a task boundary when the earlier conversation is no longer useful. For related work, retaining context can be helpful, and --resume lets me return to an existing session intentionally.
#How earlier tasks can affect a request
The following is an illustrative sequence, rather than a transcript or benchmark. Start an interactive session:
# This starts my sandboxed, interactive session
copilot_yoloAsk for a model and repository:
(copilot) Create a C# 'Person' class. Also, create a 'PersonRepository'
class that can save a List<Person> to a JSON file and read it back.public class Person
{
public string FirstName { get; set; }
public string LastName { get; set; }
public string Email { get; set; }
}using System.Text.Json;
public class PersonRepository
{
private readonly string _filePath = "people.json";
public List<Person> LoadPeople()
{
if (!File.Exists(_filePath))
{
return new List<Person>();
}
string json = File.ReadAllText(_filePath);
return JsonSerializer.Deserialize<List<Person>>(json) ?? new List<Person>();
}
public void SavePeople(List<Person> people)
{
string json = JsonSerializer.Serialize(people, new JsonSerializerOptions { WriteIndented = true });
File.WriteAllText(_filePath, json);
}
}Then keep going in the same conversation: add repository tests, validation, async methods and logging. By the time I ask for an API, the conversation contains those earlier decisions as well as the current files.
(copilot) Now, create a simple ASP.NET Core Minimal API endpoint
that uses this repository to get all people and add a new person.An answer might bring in code or assumptions that don't fit the new request:
// This is the "confused" output
using FluentValidation; // <-- Why is this here?
using Serilog; // <-- I don't need this in my API file
var builder = WebApplication.CreateBuilder(args);
// It might try to inject things I don't need for this task
builder.Host.UseSerilog();
builder.Services.AddScoped<IValidator<Person>, PersonValidator>();
var app = builder.Build();
app.MapGet("/people", (PersonRepository repo) => {
// It might copy-paste the *old* sync file logic
// instead of using the async method we refactored
string json = File.ReadAllText("people.json");
return JsonSerializer.Deserialize<List<Person>>(json);
});
// ...and so on...Logging and validation aren't inherently wrong in an API. The problem in this example is that the answer doesn't follow the requested repository boundary and may use an earlier implementation. A long conversation is one possible contributor, not proof of the cause of every slow or incorrect response.
#Giving the next task a fresh brief
After clearing, include the interfaces, file paths and requirements the next task needs. A fresh context still needs enough information to work with the code that exists.
(copilot) Create a simple ASP.NET Core Minimal API. Assume I have an
'IPersonRepository' registered for DI. Create endpoints to
GET /people (using LoadPeople) and POST /people (using SavePeople).The simplified output looks like this:
var builder = WebApplication.CreateBuilder(args);
// It assumes the DI is set up elsewhere (which is good!)
builder.Services.AddSingleton<IPersonRepository, PersonRepository>(); // Or whatever
var app = builder.Build();
app.MapGet("/people", (IPersonRepository repo) => {
return repo.LoadPeople();
});
app.MapPost("/people", (Person person, IPersonRepository repo) => {
var people = repo.LoadPeople();
people.Add(person);
repo.SavePeople(people);
return Results.Created($"/people/{person.Email}", person); // Good API practice
});
app.Run();This example assumes an IPersonRepository abstraction and omits production concerns. The earlier class doesn't show that interface, so it needs to be implemented before the DI registration can be used. The code demonstrates the intended separation between the API and file storage; it isn't a complete application to paste over the earlier snippets.
I think of starting a context as starting a new workday, but the useful distinction is which decisions the next task needs. I keep related context when it helps, and start fresh when I'd otherwise be carrying obsolete instructions into the next request.