papi-dts
    Preparing search index...
    interface CommandPaletteRequest {
        anchor?: { height?: number; width?: number; x: number; y: number };
        disableFuzzyMatching?: boolean;
        dismissOnClickOutside?: boolean;
        items: CommandPaletteItem[];
        keyForwarding?: PaletteKeyForwarding;
        maxHeight?: number;
        maxWidth?: number;
        passive?: boolean;
        placeholder?: string;
        searchFields?: readonly PaletteSearchField[];
        side?: "left" | "top" | "bottom" | "right";
    }
    Index

    Properties

    anchor?: { height?: number; width?: number; x: number; y: number }

    Anchor position in pixels relative to the requesting WebView's iframe origin. The palette is positioned adjacent to this point. If omitted, centers in the viewport.

    disableFuzzyMatching?: boolean

    When true, the palette matches by plain CONTAINMENT only (whole-phrase, then all-words), never by cmdk's per-character fuzzy scoring. Defaults to false: an ordinary focused palette fuzzy-matches, so gcb finds "Git: Create Branch".

    Set this when an exact, predictable match list matters more than forgiving lookup — marker palettes do, because the rendered list participates in commit semantics (typing a marker and pressing Space must agree byte-for-byte with what is displayed). Palettes with CommandPaletteRequest.keyForwarding and passive palettes always match by containment regardless of this option: their filtered list is resolved by the HOST (commits and forwarded keys are answered from it), and the host's filter must agree exactly with what is on screen — cmdk's scorer is not reimplemented host-side.

    dismissOnClickOutside?: boolean

    Whether clicking outside dismisses the palette. Defaults to true.

    The selectable items to display

    keyForwarding?: PaletteKeyForwarding

    Keys the REQUESTING session claims while this palette is open, and where to send them.

    The palette and the session that opened it live in different documents, so whichever holds focus is the only one that sees a keystroke. A palette that takes focus therefore silently takes the session's keys with it: its commit semantics stop running, and a local default (e.g. cmdk's own navigation) answers instead. Declaring the claimed keys closes that — the palette forwards exactly those to PaletteKeyForwarding.onKey and acts on none of them itself.

    A focus-stealing (non-passive) palette is what makes this necessary; a passive one never takes focus, so its requester already receives every key and forwarding is inert there. Requesters still declare it for both, so one code path covers a palette that unexpectedly receives a key. Omit it entirely and the palette behaves exactly as it did before forwarding existed.

    The handler is called synchronously, in the palette's own document. This is a direct function reference rather than serialized data: the overlay service is renderer-only and a requesting WebView is a same-origin iframe sharing the renderer's papi, so no boundary is crossed. The forwarded value is a plain ForwardedPaletteKeyEvent rather than a live DOM event, which keeps it free of the requester's realm.

    maxHeight?: number

    Maximum height in pixels. Defaults to 400.

    maxWidth?: number

    Maximum width in pixels. Defaults to 500.

    passive?: boolean

    When true, renders without a search input and without stealing focus from the requesting WebView. Filter text and the highlighted selection are driven externally via IOverlayService.updateCommandPalette and committed via IOverlayService.commitCommandPaletteSelection instead of the palette's own search box and keyboard handling. Defaults to false (the palette owns its own search input and focus, as today).

    Passive-palette filtering and commit resolution match the externally supplied filter text case-insensitively against the PREFIX of each item's label: a leading + in the filter is stripped first (so "+w" matches the same items as "w"), and an empty or omitted filter shows every item. LocalizeKey labels are resolved to localized text when the palette is shown, so matching always runs against the same label text the palette displays.

    placeholder?: string

    Placeholder text for the search input

    searchFields?: readonly PaletteSearchField[]

    Which item text fields the filter text matches against. Defaults to ['label', 'description', 'badge'] — every text field the palette displays — which suits general command palettes (a command is often found by a word from its description). Palettes whose label is the whole identity opt into ['label']: for marker palettes the label IS the marker code, and description matching buried exact typed markers under description hits.

    Matching and ranking: label matches come first, ranked exact-first (see PaletteFilterMode); items matching only on the OTHER searched fields follow in their original order. Passive palettes prefix-match the label only regardless of this option (PT9 marker-dropdown semantics — the passive flavor exists for in-document marker typing).

    side?: "left" | "top" | "bottom" | "right"

    Preferred side of the anchor to place the palette. Defaults to 'bottom'.