provideChatSessionCustomizations emits multiple agent-frontmatter hook items that all share the same uri (agent.uri) and type: PromptsType.hook. In the list widget, the hooks provider path expands hook items and uses item.uri.toString() as the fallback id when parsing fails; this will create duplicate IDs for these agent hooks and can break list rendering/selection (and also triggers repeated file reads of the agent file). Consider either (a) updating the widget’s hook-expansion logic to bypass parsing and generate unique IDs for items with groupKey: 'agents', or (b) changing the provider/widget contract so already-expanded hook items can flow through without being treated as hook files.

This issue also appears on line 308 of the same file.

The comment says “Post-processing: storage source filter”, but _applyFilters only applies workspaceSubpaths / instructionFileFilter checks and does not apply getStorageSourceFilter(...) / applyStorageSourceFilter. Either update the comment or implement the storage source filtering so harness-specific user-root restrictions are still respected through the provider path.

There’s an extra stray /** starting a nested JSDoc comment here, which will render oddly in generated docs and is likely accidental. Remove the duplicate opener so this is a single well-formed doc comment.

The lazily created PromptsServiceCustomizationProvider is never disposed. Since it’s a Disposable that registers listeners, it should be disposed when the harness service is disposed (e.g. keep a MutableDisposable/DisposableStore field and _register it, or override dispose() and dispose the created provider).

Same as core: the lazily created PromptsServiceCustomizationProvider is never disposed, even though it registers listeners. Consider disposing it from the harness service lifecycle (e.g. via _register/DisposableStore on the service) so it can be cleaned up when sessions window shuts down or tests dispose the service.

provideCustomizations() accepts a CancellationToken, but the hook-fetching path ignores it (e.g. listPromptFiles(..., CancellationToken.None), getCustomAgents(CancellationToken.None) and fileService.readFile(...) without passing the token). This can make the list refresh work uncancellable and potentially slower when switching sections/harnesses. Thread the token into fetchPromptServiceHooks and pass it through to promptsService/fileService calls (IFileService.readFile supports a token as the 3rd arg).

This issue also appears on line 253 of the same file.

extensionInfoByUri stores { id, displayName }, but displayName is never used (only id is consulted for built-in grouping). This likely regresses the tooltip/source labeling from a friendly extension display name to a raw inferred id. Either drop displayName from the map to avoid dead data, or preferably plumb the display name through to the list items (e.g. by adding an optional extension label field to the provider item shape and having the normalizer prefer it when present).

In groupMatchedItems, the non-sync grouping relies on a predefined groups list. Right now, hook items with groupKey: 'agents' (agent-frontmatter hooks) and instruction items that normalize to storage/groupKey === PromptsStorage.extension will fall into the dynamically-created fallback group, losing the intended labels/icons/descriptions (and e.g. showing "Extension" instead of "Extensions"). Consider adding explicit groups for agents (Hooks section) and PromptsStorage.extension (Instructions section) so these items render consistently with the previous core grouping.

The doc comment on storage?: PromptsStorage says it is "set by core when items come from promptsService; omitted for external provider items", but with the new normalization pipeline AICustomizationItemNormalizer infers storage for provider items as well (workspace/user/plugin/extension/built-in). Please update this comment to reflect the current behavior (or make storage truly optional for provider-sourced items).