`vscode/memory` tool never provisioned for GPT-5.4 — deterministic absence in both main chat and agent contexts

[dpearson2699]

Does this issue occur when all extensions are disabled?: No — requires GitHub Copilot Chat extension

• VS Code Version: 1.112.0-insider (Insiders)
• OS Version: macOS 15.4

Summary

The memory tool (vscode/memory) is never provisioned when the selected model is GPT-5.4 (OpenAI). It is consistently absent from both the main chat tool manifest and custom agent tool manifests. In contrast, when the selected model is Claude Opus 4.6, the memory tool is provisioned correctly.

This is a separate issue from #308132 (intermittent subagent-only materialization failure with Claude). That bug is about non-deterministic absence. This bug is about deterministic, total absence for all GPT models.

Steps to Reproduce

1. Open VS Code Insiders with GitHub Copilot Chat
2. Select GPT-5.4 as the chat model
3. Start a new conversation
4. Invoke a custom agent that declares tools: [vscode/memory] in its frontmatter
5. The agent attempts to use the memory tool

Expected: The memory tool is available in the tool manifest, matching the agent's tools: declaration and the <memoryInstructions> present in the system prompt.

Actual: The memory tool is absent from the tool manifest. Only resolve_memory_file_uri (the path resolver) is present. The model cannot read or write memory files.

Evidence from debug logs

I compared tool manifests across two sessions in the same VS Code workspace:

GPT-5.4 session (92e423d6-8879-495d-8f6d-e00a30250455)

Main chat (tools_0.json): 61 tools. Has resolve_memory_file_uri. Does NOT have memory.

Custom agent context (tools_1.json): 36 tools. Has resolve_memory_file_uri. Does NOT have memory.

The system prompt (system_prompt_0.json) includes full <memoryInstructions> telling the model to use memory for reading/writing notes — but the tool to do so is never exposed.

The agent context system prompt (system_prompt_1.json) also says:

"You don't currently have any tools available for editing files."
"You don't currently have any tools available for running terminal commands."

...despite the agent declaring tools: [vscode/memory] in its frontmatter.

Claude Opus 4.6 session (f0ed9ef6-927c-4852-8311-4f0ce01c665e)

Same workspace, same agent definition. tools_0.json contains memory tool. The agent can read and write /memories/session/, /memories/repo/, and /memories/ as expected.

Broader tool provisioning differences

Beyond memory, GPT-5.4 is also missing several tools from the main chat context that Claude receives. Not all of these are relevant to this bug, but the pattern suggests GPT models receive a structurally different tool set:

Missing from GPT-5.4 main chat (present for Claude):

• No memory (the read/write tool — only resolve_memory_file_uri)
• No vscode_askQuestions
• No get_errors
• No multi_replace_string_in_file
• No replace_string_in_file

(GPT-5.4 gets apply_patch and create_file instead of the replace/edit tools, which appears intentional. The absence of memory does not.)

Impact

• Any custom agent workflow that depends on vscode/memory for persisting plans, session context, or cross-agent handoff data is broken when the user selects a GPT model.
• The system prompt instructs the model to use memory files, creating a contradictory experience where the model is told to consult and update memory but has no tool to do so.
• resolve_memory_file_uri is present but useless without the corresponding read/write tool — the model can resolve URIs but cannot read or write the files.

Suggested fix

The memory tool should be provisioned regardless of the selected model when:

1. The system prompt includes <memoryInstructions>, OR
2. A custom agent declares vscode/memory in its tools: frontmatter

Related

• Custom agent tools: [vscode/memory] intermittently not materialized in subagent runtime tool manifest #308132 — Intermittent vscode/memory absence in subagent contexts (Claude model). Different root cause: that bug is non-deterministic; this one is deterministic per-model.

[dpearson2699]

@bhavyaus Can you review the PR I opened for this? This has been a very annoying issue impacting multiple workflows for my org and this simple change fixes it. #312652. I confirmed the change works in my local dev build of vscode