agentHost: expand AHP customization refs into per-type items for chat customizations UI#311131
agentHost: expand AHP customization refs into per-type items for chat customizations UI#311131joshspicer wants to merge 1 commit intomainfrom
Conversation
Screenshot ChangesBase: Changed (4)
|
| Before | After |
|---|---|
 |
 |
editor/inlineCompletions/other/JumpToHint/Dark
| Before | After |
|---|---|
 |
 |
agentSessionsViewer/CompletedUnread/Dark
| Before | After |
|---|---|
 |
 |
agentSessionsViewer/CompletedUnread/Light
| Before | After |
|---|---|
 |
 |
There was a problem hiding this comment.
Pull request overview
Fixes the Sessions window “Chat Customizations” UI for remote Agent Host Protocol (AHP) agents by expanding server-supplied customization plugin refs into per-PromptsType items (skills/agents/prompts/instructions/hooks), making them visible in the corresponding filtered sections.
Changes:
- Reworked
RemoteAgentCustomizationItemProviderto expand each AHP customization ref into per-typeICustomizationItems derived from the matching localIAgentPluginServiceplugin contents. - Added a reactive refresh (
autorun) so the customization list updates when local plugin contents change. - Wired
IAgentPluginServiceinto the remote agent contribution so the provider can resolve/expand plugin refs.
Show a summary per file
| File | Description |
|---|---|
src/vs/sessions/contrib/remoteAgentHost/browser/remoteAgentHostCustomizationHarness.ts |
Expands AHP customization refs into per-type items using local plugin contents; adds change tracking for plugin updates. |
src/vs/sessions/contrib/remoteAgentHost/browser/remoteAgentHost.contribution.ts |
Passes IAgentPluginService into the customization item provider. |
Copilot's findings
- Files reviewed: 2/2 changed files
- Comments generated: 2
| const plugin = localPlugins.find(p => p.uri.toString() === refUri.toString()); | ||
| if (!plugin || !isContributionEnabled(plugin.enablement.get())) { |
There was a problem hiding this comment.
Plugin lookup uses p.uri.toString() === refUri.toString(). This is a strict, case-sensitive string comparison and can fail on platforms with case-insensitive paths (e.g. Windows drive letter/path casing) or if URIs differ only by normalization, causing the plugin to be treated as “not installed” and preventing expansion. Prefer URI-aware comparison (e.g. isEqual(p.uri, refUri) from vs/base/common/resources or an injected IUriIdentityService.extUri.isEqual) so matching is robust.
| return [{ | ||
| uri: refUri, | ||
| type: 'plugin', | ||
| name: refName, | ||
| description: refDescription, | ||
| storage: PromptsStorage.plugin, | ||
| enabled: overlay.enabled, | ||
| status: overlay.status, | ||
| statusMessage: overlay.statusMessage, | ||
| }]; |
There was a problem hiding this comment.
The fallback/placeholder item uses type: 'plugin', but the AI Customizations UI filters provider items with item.type === promptType where promptType is a PromptsType value (instructions/prompt/agent/skill/hook). As a result, this placeholder will never render in any section, so missing/disabled local plugins still appear as “no customizations” and are silently dropped. Consider returning a placeholder per relevant PromptsType (or choosing a single section such as PromptsType.prompt) and using the description/statusMessage to indicate the plugin isn't installed locally, so the user can actually see the entry.
The item source pipeline filters provider items by item.type === promptType, silently dropping items whose type is not a recognised PromptsType. AHP-contributed customizations use type 'plugin' (an Open Plugins reference, not a prompt type), so they were invisible in every per-type section. Fix by including items with unrecognised types alongside the type-matched items in both fetchItemsFromProvider and normalizeItems. This restores visibility for AHP customizations without coupling the display layer to local plugin discovery. Co-authored-by: Copilot <223556219+Copilot@users.noreply.github.com>
joshspicer
force-pushed
the
agents/fix-agent-host-protocol-display
branch
from
2403c6d to
e27782c
Compare
Problem
The item source pipeline in
fetchItemsFromProviderandnormalizeItemsfilters provider items byitem.type === promptType. AHP-contributed customizations usetype: 'plugin'(an Open Plugins reference, not aPromptsTypeenum value), so they were silently dropped in every per-type section (Skills, Agents, Instructions, Hooks, Prompts).This was introduced in
d7c19c5af6ewhen the group-based display path (sectionToCustomizationGroupIds) was replaced with a type-based filter that assumed all items would have a validPromptsType.Fix
Include items whose type is not a recognised
PromptsTypealongside the type-matched items. This is a 3-line change inaiCustomizationItemSource.ts:fetchItemsFromProvider: collect items with unrecognised types (untypedItems) and append them to the filtered set for every section.normalizeItems: relax the filter to also pass items with unrecognised types.AHP customizations now show in every per-type section as flat remote items in the sync layout, with their server-reported status/enabled state preserved. No coupling to local plugin discovery.
Changed files
src/vs/workbench/contrib/chat/browser/aiCustomization/aiCustomizationItemSource.ts— relax type filters to include untyped provider items