microsoft / microsoft/agent-host-protocol
Support portable icons for session configuration options
Nobody has claimed this yet.
- Dominant language
- TypeScript
- Stars
- 344
- Forks
- 122
- Avg merge
- 14h 12m
- Merged PRs (30d)
- 22
Description
Problem
AHP lets hosts describe session configuration choices without requiring clients to know provider-specific property names or values:
ConfigPropertySchema/SessionConfigPropertySchemaprovideenum,enumLabels, andenumDescriptions.SessionConfigValueItemprovidesvalue,label, and an optionaldescriptionfor dynamic completions.
Neither representation currently carries an option icon or a standardized icon hint. AHP already defines an Icon type, but it is not exposed on configuration options.
This leaves generic clients with a choice between text-only options and client-maintained mappings for recognized properties/values. Approval-related settings are one example: a client should not guess an option's meaning from an unfamiliar host-defined string just to choose an icon.
Request
Define an optional, client-independent way to describe per-option icons or semantic presentation hints for session configuration choices.
The convention should:
- Cover both static enum options and dynamic
sessionConfigCompletionsitems consistently. - Avoid requiring VS Code Codicon identifiers or another client's icon library.
- Allow clients to omit unsupported icons while retaining labels, descriptions, and selected-state indicators.
- Preserve backward compatibility when metadata is absent or unrecognized.
- Remain presentation-only: an icon must not grant permissions, bypass policy, or be treated as evidence that an operation is safe.
Design questions
- Should this reuse the existing
Iconrepresentation, introduce a small vocabulary of semantic hints that clients map to native icons, or support both? - How should optional per-option metadata align with static enum values and dynamic completion items?
- If resource-backed icons are used, how should the existing trust, SVG-handling, theme, and size guidance apply to configuration pickers?
Expected outcome
Document the chosen representation, fallback behavior, and accessibility expectations, with schema examples/tests for both static and dynamic options. Labels must remain sufficient to understand and operate a picker without icons.
This is a protocol presentation enhancement, not a request to standardize provider-specific permission models or introduce client-side permission adapters.
References
- Configuration and Icon schemas
- Dynamic configuration option schema
- Client-side motivation: microsoft/vscode#335599
Contributor guide
First steps
- Read the whole issue, then the project's contributing guide.
- Comment on the issue to say you are picking it up — it saves two people doing the same work.
- Fork the repository and make your change on a branch.
- Open a pull request that references the issue number.
Research direction
Start with schema/state.schema.json and schema/commands.schema.json, focusing on Icon, SessionConfigPropertySchema, and SessionConfigValueItem. Review the existing icon guidance and schema tests before deciding how static and dynamic options should align. Done means the representation, fallback and accessibility behavior are documented, with examples and tests covering both option forms.
Written by the indexing model from the issue text.
Assessment
- Tech stack
- typescript
- Domain
- api, documentation, testing
- Issue type
- Feature
- Difficulty
- 5/5
- Estimated time
- Over a week
- Activity status
- Active
- Clarity
- Needs clarification
- Newbie friendliness
- 35/100