Copilot Memory in VS Code: Inspect Tools, Files, and Scope

To inspect Copilot memory in VS Code, identify the active agent, open the Command Palette, and run Chat: Show Memory Files where that command is available. Review the scope and contents before assuming a note will survive a new conversation or reach another developer. fenbs can hold the approved project decisions and progress that need to stay available beyond one editor’s local notes.

How do you inspect the memory your agent uses?

1. Note the current workspace and selected agent. Different agent environments can supply different tools, so test the one you actually use.
2. Open the Command Palette and run Chat: Show Memory Files. Select a listed file and read its contents.
3. Check whether each note describes a personal preference, a workspace fact, or temporary work for this conversation.
4. Ask the agent to explain a relevant note before editing code. Compare its explanation with the file and the current repository.

VS Code’s memory documentation↗ (opens in a new tab) describes a built-in memory tool with local user, repository, and session scopes. User memory can span workspaces; repository memory is workspace-scoped; session memory belongs to the current conversation. The documented paths are /memories/, /memories/repo/, and /memories/session/. These describe the tool’s scopes, not a promise that a folder exists at your repository root.

If the command is missing, check your installed version and the agent environment against that documentation. Do not create an arbitrary .memory folder and assume it will be loaded. First establish which mechanism is available. Our GitHub Copilot in VS Code guide covers the broader editor setup.

Which saved files are instructions rather than memory?

Instruction files are guidance you deliberately maintain with the project. VS Code documents repository-wide .github/copilot-instructions.md, scoped .instructions.md files, and AGENTS.md in its custom instructions guide↗ (opens in a new tab). Check which files apply to your environment and request rather than assuming every file with instructions in its name is automatically read.

Keep a simple distinction: instructions say how the team intends work to happen; a local memory can capture something an agent learned while working. A local note saying that a command worked yesterday is useful evidence to investigate. A reviewed instruction saying which command contributors must run is the maintained team guidance.

• Keep standing development rules in the project’s maintained instruction files.
• Treat newly learned local notes as information to verify before sharing.
• Keep temporary plans with the current task instead of making them universal rules.
• Remove or correct a duplicate local note when the maintained instruction changes.

For practical wording, see Copilot instruction examples. Approved work choices that extend beyond code can live in fenbs Decisions and rules, with the person’s decision and project scope attached.

Does a saved plan mean the next session knows the task?

Not by itself. A plan describes intended work, while a useful handoff explains what actually happened. Before continuing, compare the plan with current files and recorded checks. An unchecked step should stay unchecked even if an assistant previously wrote a confident summary of its intention.

VS Code’s planning guide↗ (opens in a new tab) explains that a local Plan agent can store its plan at /memories/session/plan.md, accessible through Chat: Show Memory Files. That session plan is not a project file. If teammates need an agreed plan, put the reviewed version in a location your workflow shares.

Say the plan calls for updating a form and testing email delivery. The code change may be complete while delivery remains unchecked. Preserve those two states separately. Otherwise, the next conversation can turn “planned” into “finished” merely because both statements were close together in a summary.

How can you test whether the right note carries forward?

Use one harmless, verifiable example. A preference for a short explanation is safer than a sensitive customer detail. A workspace fact such as the documented test command is useful because you can compare it with the repository. Keep the test focused on retrieval rather than code changes.

1. Ask the agent to remember the chosen fact, then inspect the saved file and scope.
2. Start a fresh conversation in the intended workspace and ask a narrow question about that fact.
3. Ask the agent which record it read. Compare that record with the answer before trusting the result.
4. If you are testing workspace boundaries, repeat in an unrelated workspace without supplying the old fact.

Do not treat a fluent explanation as proof of a particular storage mechanism. The agent might find the same answer in code or instructions. That can be an acceptable workflow, but it does not demonstrate that a personal memory moved between workspaces. Keep a note of what you tested and what remains uncertain.

How do you correct a misleading local note?

Open the note, compare it with a reliable source, and decide what should replace it before removing it. For an individual memory file, VS Code documents asking the agent to update or delete it. Chat: Clear All Memory Files removes memory across scopes; use the narrower change when one entry is the problem.

For example, a note might say a package uses a command that no longer exists. Verify the current command in the package’s configuration. Correct the note and check the standing instructions too. Otherwise, the assistant can relearn the obsolete answer from another source immediately after you remove it.

Local memory management is separate from GitHub’s hosted memory controls. The GitHub Copilot memory guide owns that wider product question; Copilot automatic memory explains learned coding knowledge without turning this inspection task into a general feature tour.

How to share coding context with fenbs

1. Create a free account and add the project plus the task you are working on.
2. Record the approved choices in Decisions and rules. Add source references that help someone verify a project fact.
3. Connect GitHub Copilot through Integrations. MCP is a standard way for an AI app to use an outside tool, with browser sign-in for fenbs.
4. Ask the connected assistant to read the project context before working, then save task progress and Where we left off before the conversation ends.

fenbs is not the right fit for inspecting or clearing VS Code’s local memory files, and it does not import them. Its role is the deliberately maintained project record. A small solo repository may need only clear instructions and a short handoff document.

Check the result by starting a new supported session and asking for the next task action. It should identify the unfinished check from your record rather than infer completion from the plan. Browse the AI memory hub for related approaches when your needs extend beyond the editor.