Change:
await terminal.assertCommandDecorations({ placeholder: 1, success: 0, error: 1 }); }); }); <del> describe('Custom configuration', function () { it('Should update and show custom icons', async () => { await createShellIntegrationProfile(); await terminal.assertCommandDecorations({ placeholder: 1, success: 0, error: 0 }); await terminal.runCommandInTerminal(`echo "foo"`); await terminal.runCommandInTerminal(`bar`); await settingsEditor.addUserSetting('terminal.integrated.shellIntegration.decorationIcon', '"zap"'); await settingsEditor.addUserSetting('terminal.integrated.shellIntegration.decorationIconSuccess', '"zap"'); await settingsEditor.addUserSetting('terminal.integrated.shellIntegration.decorationIconError', '"zap"'); await terminal.assertCommandDecorations(undefined, { updatedIcon: "zap", count: 3 }); }); }); </del> describe('terminal.integrated.shellIntegration.decorationsEnabled should determine gutter and overview ruler decoration visibility', function () { beforeEach(async () => { await settingsEditor.clearUserSettings();

Discussion:
! The settings to select an codicon for a decoration are not playing well with our product icon theming approach. We want that a product icon theme can style all icons of our UI with a new icons. Each icon that we show should be defined with a component specific name E.g. , , ... That way the theme can come up with a custom icon for each icon location The base icon names (, , ...) should not be used directly, only as defaults, otherwise it gets complicated for a theme to change an icon as it affects many places, unknown to the theme. What might look good with our codicon based product icon theme, might look wrong with a theme that uses a different visual for I suggest to remove the settings as we don't do that at other places. Instead we should refer to product icon themes as the way to change icons.
Requested the aliases in
We do allow switching icons for terminals in this way which I think is fine as they're very temporal: ! I see what you're saying here though, let's remove the setting and leave it up to the icon theme . We have this setting now so it solves that part of what these icon settings allowed:
I was on vacation so I couldn't jump in here. It was not necessary to request new codicons or codicon aliases unless a new icon shape was needed, e.g. for a concept we didn't have yet. There still seems to be a confusion of Codicons vs product icon icons. The Codicon library is a set of default icons that are part of the Codicon font. We use these as default icons in VS Code. See the spec of Codicon: codicon aliases should be component agnostic (no 'terminal', 'debug'). The componnet specific ids go in the product icon registry. These are the ids that wil be used in a product icon theme when styling an icon. Product icon ids are component specific and are defined in the component itself, e.g. as done here: This defines a new product icon , and uses the codicon 'add' icon as the default icon. When using these icons in code, must be used (or in labels by the id ). We never want to reference in components, unless for the default in . Some years ago, all our components directly referenced codicons and their ids.

When adding icon theming support we this indirection and I and migrated most components, including terminal. But given the huge number of icon references that work is still not complete and there are still plenty of references to Codicon. That's why a codicon and a product icon () still have the same API and we don't enforce this with the compiler. Also there are some codicon aliases that have component specific names. We can't clean up the aliases in order to not break existing code in extensions. Eventually no one should use there anymore. please do not reference Codicon directly anymore unless in registerIcon please follow the pattern as seen in terminalIcons please don't add component specific Codicon aliases FYI
FYI I was following what seemed to be the thing to do as demonstrated by the icons. Could we remove those and similar examples and/or add a comment with this guidance?
Good point, we should clean these up. The codicons have been around from old times before we did the product icons. There are product icon registration under the same name , so we can remove the codicons that are just aliases, and give the others a different name, to avoid confusion.