Skip to content

Add positron.ai.getAllowedCommands() API for LLM extensions#14913

Draft
samclark2015 wants to merge 3 commits into
mainfrom
samclark2015/llm-get-agent-allowed-commands
Draft

Add positron.ai.getAllowedCommands() API for LLM extensions#14913
samclark2015 wants to merge 3 commits into
mainfrom
samclark2015/llm-get-agent-allowed-commands

Conversation

@samclark2015

Copy link
Copy Markdown
Contributor

Adds a new positron.ai.getAllowedCommands() extension API that returns all registered Positron commands with their IDs, descriptions, argument metadata, and source (builtin vs. extension). This gives LLM extensions a structured way to discover what commands are available to invoke on behalf of users, with a future allowlist in mind.

Descriptions are resolved from four sources in priority order: CommandsRegistry metadata, MenuRegistry.getCommands() titles, MenuId.CommandPalette menu item titles (catches MultiCommand/EditorCommand registrations like undo/redo that use appendMenuItem instead of addCommand), and EditorExtensionsRegistry labels. Also adds a Developer: Show Allowed AI Commands command in core (positronAssistant.contribution.ts) that dumps the full result as formatted JSON in a new editor tab, for manual testing.

Release Notes

New Features

  • Add positron.ai.getAllowedCommands() API for LLM extensions to discover available Positron commands

Bug Fixes

  • N/A

Validation Steps

@:assistant

  1. Open the Command Palette and run Developer: Show Allowed AI Commands
  2. Verify a JSON editor opens with an array of command objects
  3. Confirm entries like undo and redo have a description field (e.g. "Undo", "Redo") and source.type: "builtin"
  4. Confirm extension-contributed commands (e.g. from Python or R) have source.type: "extension" with id and displayName
  5. Confirm no entries have IDs beginning with _

samclark2015 and others added 2 commits July 10, 2026 14:22
Adds a new method to the positron.ai namespace that returns all registered
Positron commands with their IDs, descriptions, parameter metadata, keybindings,
and source (builtin vs. extension). Descriptions are resolved from four sources
in priority order: CommandsRegistry metadata, MenuRegistry.getCommands() titles,
CommandPalette menu item titles (covers undo/redo and similar MultiCommand
registrations), and EditorExtensionsRegistry labels.

Also adds a "Positron Assistant: Show Allowed Commands" command palette entry in
the positron-assistant extension that dumps the result as formatted JSON in a new
editor tab, for manual testing.

Co-Authored-By: Claude Sonnet 4.6 <noreply@anthropic.com>
Moves the "Show Allowed AI Commands" command from the positron-assistant
extension into positronAssistant.contribution.ts in core, where it reads
the command registries directly without going through the extension host.

Also removes keybindings from the positron.ai.getAllowedCommands() return
type and implementation, simplifying the IPC payload.

Co-Authored-By: Claude Sonnet 4.6 <noreply@anthropic.com>
@github-actions

Copy link
Copy Markdown

E2E Tests 🚀
This PR will run tests tagged with: @:critical @:assistant

Why these tags?
Tag Source
@:critical Always runs (required)
@:assistant PR description

More on automatic tags from changed files.

readme  valid tags

*/
export interface AllowedCommandSource {
/** `'builtin'` for core Positron/VS Code commands; `'extension'` for extension-contributed commands. */
type: 'builtin' | 'extension';

@dhruvisompura dhruvisompura Jul 16, 2026

Copy link
Copy Markdown
Contributor

Choose a reason for hiding this comment

The reason will be displayed to describe this comment to others. Learn more.

🎉 ooh, it would be great if we could filter on extension vs builtin commands in the future (I don't think we'll need it for the curated Assistant experience).

* Return all registered commands with their IDs, descriptions, and parameter metadata.
* Internal commands (IDs starting with '_') are excluded.
*/
async $getAllowedCommands(): Promise<ISerializedAllowedCommand[]> {

@dhruvisompura dhruvisompura Jul 16, 2026

Copy link
Copy Markdown
Contributor

Choose a reason for hiding this comment

The reason will be displayed to describe this comment to others. Learn more.

For this, I was thinking we may want to limit the commands we expose from this endpoint to be ones that we also show in the command palette (f1: true). This would ensure that the user can also lookup/validate the commands the Assistant is running from this endpoint. We're more likely to have some documentation of those commands as well.

Or we allow filtering on f1 at the very least!

Sign up for free to join this conversation on GitHub. Already have an account? Sign in to comment

Labels

None yet

Projects

None yet

Development

Successfully merging this pull request may close these issues.

2 participants