GitHub Copilot history: reviewing an incident

Which change caused this, and why did it look correct at the time?

Why this is hard

Git answers the first half of an incident question. The second half — what the author was trying to do, what constraint they gave the model, what the model quietly worked around — is in the conversation, and it is the half that stops the same failure recurring.

What GitHub Copilot specifically does to you here

Recent VS Code writes sessions as a JSONL journal — a snapshot line followed by patches — so anything reading the old single-object format finds an empty request list and concludes there is no history. During an incident that reads as 'nothing was captured' when the file is right there.

find "$HOME/Library/Application Support/Code/User/workspaceStorage" -name '*.jsonl' -path '*chatSessions*' | wc -l

Where GitHub Copilot keeps this in the first place: ~/Library/Application Support/Code/User/workspaceStorage/<hash>/chatSessions/. History is keyed to the workspace path. Rename or move the project and the chat panel comes up empty.

What a working answer looks like

A working answer means going from a line of code to the prompt that produced it, months later, without depending on anyone's memory.

Start by measuring what you have. npx promptwake doctor reports what every AI tool on the machine is holding and how much of it sits inside a deletion window — no account, writes nothing, sends nothing anywhere. If the conclusion is that the record should not depend on one laptop, that is what PromptWake captures: prompt, response and the resulting diff, local by default and synced into a shared timeline on the paid tiers.