Tool Rename Deprecation

When a tool or tool set reference name is changed, the old name must always be added to the deprecated/legacy array so that existing prompt files, tool configurations, and saved references continue to resolve correctly.

When to Use

Run this skill on any change to built-in tool or tool set registration code to catch regressions:

Renaming a tool's toolReferenceName
Renaming a tool set's referenceName
Moving a tool from one tool set to another (the old toolSet/toolName path becomes a legacy name)
Reviewing a PR that modifies tool registration — verify no legacy names were dropped

Procedure

Step 1 — Identify What Changed

Determine whether you are renaming a tool or a tool set, and where it is registered:

Entity	Registration	Name field to rename	Legacy array	Stable ID (NEVER change)
Tool (`IToolData`)	TypeScript	`toolReferenceName`	`legacyToolReferenceFullNames`	`id`
Tool (extension)	`package.json` `languageModelTools`	`toolReferenceName`	`legacyToolReferenceFullNames`	`name` (becomes `id`)
Tool set (`IToolSet`)	TypeScript	`referenceName`	`legacyFullNames`	`id`
Tool set (extension)	`package.json` `languageModelToolSets`	`name` or `referenceName`	`legacyFullNames`	—

Critical: For extension-contributed tools, the name field in package.json is mapped to id on IToolData (see languageModelToolsContribution.ts line id: rawTool.name). It is also used for activation events (onLanguageModelTool:<name>). Never rename the name field — only rename toolReferenceName.

Step 2 — Add the Old Name to the Legacy Array

Verify the old toolReferenceName value appears in legacyToolReferenceFullNames. Don't assume it's already there — check the actual array contents. If the old name is already listed (e.g., from a previous rename), confirm it wasn't removed. If it's not there, add it.

For internal/built-in tools (TypeScript IToolData):

// Before rename
export const MyToolData: IToolData = {
	id: 'myExtension.myTool',
	toolReferenceName: 'oldName',
	// ...
};

// After rename — old name preserved
export const MyToolData: IToolData = {
	id: 'myExtension.myTool',
	toolReferenceName: 'newName',
	legacyToolReferenceFullNames: ['oldName'],
	// ...
};

If the tool previously lived inside a tool set, use the full toolSet/toolName form:

legacyToolReferenceFullNames: ['oldToolSet/oldToolName'],

If renaming multiple times, accumulate all prior names — never remove existing entries:

legacyToolReferenceFullNames: ['firstOldName', 'secondOldName'],

For tool sets, add the old name to the legacyFullNames option when calling createToolSet:

toolsService.createToolSet(source, id, 'newSetName', {
	legacyFullNames: ['oldSetName'],
});

For extension-contributed tools (package.json), rename only toolReferenceName and add the old value to legacyToolReferenceFullNames. Do NOT rename the name field:

// CORRECT — only toolReferenceName changes, name stays stable
{
	"name": "copilot_myTool",           // ← KEEP this unchanged
	"toolReferenceName": "newName",     // ← renamed
	"legacyToolReferenceFullNames": [
		"oldName"                       // ← old toolReferenceName preserved
	]
}

Step 3 — Check All Consumers of Tool Names

Legacy names must be respected everywhere a tool is looked up by reference name, not just in prompt resolution. Key consumers:

Prompt files — getDeprecatedFullReferenceNames() maps old → current names for .prompt.md validation and code actions
Tool enablement — getToolAliases() / getToolSetAliases() yield legacy names so tool picker and enablement maps resolve them
Auto-approval config — isToolEligibleForAutoApproval() checks legacyToolReferenceFullNames (including the segment after / for namespaced legacy names) against chat.tools.eligibleForAutoApproval settings
RunInTerminalTool — has its own local auto-approval check that also iterates LEGACY_TOOL_REFERENCE_FULL_NAMES

After renaming, confirm:

#oldName in a .prompt.md file still resolves (shows no validation error)
Tool configurations referencing the old name still activate the tool
A user who had "chat.tools.eligibleForAutoApproval": { "oldName": false } still has that restriction honored

Step 4 — Update References (Optional)

While legacy names ensure backward compatibility, update first-party references to use the new name:

System prompts and built-in .prompt.md files
Documentation and model descriptions that mention the tool by reference name
Test files that reference the old name directly

Key Files

File	What it contains
`src/vs/workbench/contrib/chat/common/tools/languageModelToolsService.ts`	`IToolData` and `IToolSet` interfaces with legacy name fields
`src/vs/workbench/contrib/chat/browser/tools/languageModelToolsService.ts`	Resolution logic: `getToolAliases`, `getToolSetAliases`, `getDeprecatedFullReferenceNames`, `isToolEligibleForAutoApproval`
`src/vs/workbench/contrib/chat/common/tools/languageModelToolsContribution.ts`	Extension point schema, validation, and the critical `id: rawTool.name` mapping (line ~274)
`src/vs/workbench/contrib/terminalContrib/chatAgentTools/browser/tools/runInTerminalTool.ts`	Example of a tool with its own local auto-approval check against legacy names

Real Examples

runInTerminal tool: renamed from runCommands/runInTerminal → legacyToolReferenceFullNames: ['runCommands/runInTerminal']
todo tool: renamed from todos → legacyToolReferenceFullNames: ['todos']
getTaskOutput tool: renamed from runTasks/getTaskOutput → legacyToolReferenceFullNames: ['runTasks/getTaskOutput']

Reference PRs

#277047 — Design PR: Introduced legacyToolReferenceFullNames and legacyFullNames, built the resolution infrastructure, and performed the first batch of tool renames. Use as a template for how to properly rename with legacy names.
#278506 — Consumer-side fix: After the renames in #277047, the eligibleForAutoApproval setting wasn't checking legacy names — users who had restricted the old name lost that restriction. Shows why all consumers of tool reference names must account for legacy names.
vscode-copilot-chat#3810 — Example of a miss: Renamed openSimpleBrowser → openIntegratedBrowser but also changed the name field (stable id) from copilot_openSimpleBrowser → copilot_openIntegratedBrowser. The toolReferenceName backward compat only worked by coincidence (the old name happened to already be in the legacy array from a prior change — it was not intentionally added as part of this rename).

Regression Check

Run this check on any PR that touches tool registration (TypeScript IToolData, createToolSet, or package.json languageModelTools/languageModelToolSets):

Search the diff for changed toolReferenceName or referenceName values. For each change, confirm the previous value now appears in legacyToolReferenceFullNames or legacyFullNames. Don't assume it was already there — read the actual array.
Search the diff for changed name fields on extension-contributed tools. The name field is the tool's stable id — it must never change. If it changed, flag it as a bug. (This breaks activation events, tool invocations by id, and any code referencing the tool by its name.)
Verify no entries were removed from existing legacy arrays.
If a tool moved between tool sets, confirm the old toolSet/toolName full path is in the legacy array.
Check tool set membership lists (the tools array in languageModelToolSets contributions). If a tool's toolReferenceName changed, any tool set tools array referencing the old name should be updated — but the legacy resolution system handles this, so the old name still works.

Anti-patterns

Changing the name field on extension-contributed tools — the name in package.json becomes the id on IToolData (via id: rawTool.name in languageModelToolsContribution.ts). Changing it breaks activation events (onLanguageModelTool:<name>), any code referencing the tool by id, and tool invocations. Only rename toolReferenceName, never name. (See vscode-copilot-chat#3810 where both name and toolReferenceName were changed.)
Changing the id field on TypeScript-registered tools — same principle as above. The id is a stable internal identifier and must never change.
Assuming the old name is already in the legacy array — always verify by reading the actual legacyToolReferenceFullNames contents, not just checking that the field exists. A legacy array might list names from an even older rename but not the current one being changed.
Removing an old name from the legacy array — breaks existing saved prompts and user configurations.
Forgetting to add the legacy name entirely — prompt files and tool configs silently stop resolving.
Only updating prompt resolution but not other consumers — auto-approval settings, tool enablement maps, and individual tool checks (like RunInTerminalTool) all need to respect legacy names (see #278506).

tool-rename-deprecation