-
Notifications
You must be signed in to change notification settings - Fork 3
Session Internals
Author: GitHub Copilot, in collaboration with Niclas Olofsson Date: August 15, 2025
This paper presents an in-depth analysis of the session log files generated by the GitHub Copilot Chat extension in Visual Studio Code. Through a series of methodical experiments and direct observation, we have decoded the structure of the primary session log (<session-id>.json) and mapped the flow of information between the user, the editor, and the backend AI models. Our findings reveal a transparent and highly structured logging mechanism that provides profound insights into the agent's reasoning, tool usage, and context management. The toolCallRounds array, in particular, has been identified as the definitive record of all backend Large Language Model (LLM) invocations, serving as a precise "backend request counter" for any given user prompt.
The GitHub Copilot Chat extension provides a powerful conversational interface for software development. To understand its inner workings beyond a surface level, one must look to the artifacts it produces. This investigation focuses on the primary session log file, a JSON document that serves as the ground truth for a single conversation. By dissecting this file, we can move from being a user of the AI to an analyst of its behavior, uncovering the precise logic that governs its responses.
The foundation of Copilot's conversational memory resides in a dedicated workspace storage folder. For each unique workspace, a directory is created containing a chatSessions folder.
-
Session Identification: Each new conversation initiates a new session, identified by a Globally Unique Identifier (GUID). This GUID becomes the filename for the session log (e.g.,
46b62e86-d859-4cfe-a781-a5cf7d852ab2.json). -
Chronological Record: The session file contains a top-level
requestsarray. This array is the master timeline of the conversation, where each object within it represents one full turn—a user prompt and the agent's final response.
The richness of the log is found within the objects of the requests array. Each object is a detailed record of a single conversational turn, containing several key fields that, when analyzed together, tell a complete story.
This field identifies which specialized agent, or "chat participant," was responsible for handling the request. It is the primary indicator of the capabilities and tools that were brought to bear.
-
github.copilot.default: The general-purpose conversational agent. -
github.copilot.workspace: A specialist agent with tools to analyze the entire workspace. -
github.copilot.terminal: A specialist for generating and explaining shell commands. - Third-Party Agents: This field can also identify custom agents provided by other VS Code extensions.
-
message.text: Contains the literal string of the user's prompt. -
slashCommand: This field is populated when the UI recognizes the user's input as an implicit command (e.g., typing*.ts). It acts as a structured "intent hint" to the LLM, informing it of the type of action the user wishes to perform, rather than leaving it to pure conversational inference.
This is the most critical discovery of our analysis. The toolCallRounds array is the definitive, step-by-step log of the agent's reasoning process. Every object in this array represents a distinct, sequential call to the backend LLM.
-
Counting Backend Requests: The number of backend calls for a turn is always equal to
toolCallRounds.length. -
The Plan-Act-Synthesize Loop:
- A
toolCallRoundsentry with a non-emptytoolCallsarray represents a "planning" step. The LLM's goal was to think and decide which tools to use. Its output was a command to run a tool, not text for the user. - A
toolCallRoundsentry with an emptytoolCallsarray represents a "synthesizing" step. The LLM received the results from a previous tool call and its goal was to generate the final, human-readable response.
- A
-
response: An array of objects that are streamed to the UI to construct the final message. This reveals how the UI is built, including plain text, UI state indicators (prepareToolInvocation), and even actionable components.-
Actionable Components: Specially formatted blocks (
[ARGS START]...[ARGS END]) within the response value can be rendered as clickable buttons by the UI, but only when the conversational context implies a command was issued.
-
Actionable Components: Specially formatted blocks (
-
followups: This array is populated only when the AI generates "suggestion chips"—clickable follow-up questions to guide the user's exploration of a broad topic.
Our investigation revealed that the model's behavior is profoundly influenced by persistent instructions provided in .github/instructions/memory.instructions.md. This file acts as a high-priority system prompt, prepended to every request. It establishes a baseline persona and interaction style for the user that can override the context of a single prompt. This explains why attempts to adopt a "newbie" persona failed; the system instructions consistently identified the user as a technical expert, causing the model to tailor its responses accordingly and suppress beginner-oriented features like follow-up suggestions.
The Copilot Chat session log is not merely a transcript; it is a transparent and detailed schematic of the AI's cognitive process. By understanding the roles of agent.id, slashCommand, and particularly the toolCallRounds array, an analyst can determine who handled a request, what the user's implied intent was, and the precise sequence of LLM calls and tool executions used to generate a response. This structured log transforms the "black box" of AI into a glass box, providing an invaluable resource for debugging, analysis, and a deeper appreciation of the sophisticated architecture at play.