Application manifest

An application manifest is a single YAML file that declares everything Bricoop needs to detect, configure, and connect a desktop application. The manifest is the only contract between the application and Bricoop; it carries no provider-specific logic and no credentials. Every field below is generated from the pinned registry revision, so the canonical reference is the Application schema reference.

Stable ID

The id field is a stable lowercase identifier that names the application across every locale and release. It never changes once published; renaming an id is a removal plus a new entry. The name field is the human-readable display name, and version is the application version the manifest targets. The schema_version field pins the manifest schema itself so Bricoop can reject manifests written for an incompatible schema.

Commands and detection

The configs[] array tells Bricoop how to locate and patch the application’s configuration on each platform. Each entry carries a type (such as file_patch), a format (such as json), a path object with macos, linux, and windows locations, and a writes[] list of operations Bricoop applies. Bricoop reads path to find the config file, applies create_if_missing when the file does not yet exist, and runs each writes[] entry to set the provider endpoint into the slot the manifest declares.

Version range

The version field is the application version the manifest was authored against, while minimal_client_version is the lowest Bricoop Desktop version that can run the manifest and minimal_application_version is the lowest application version that accepts the patched config. Bricoop compares the running client and the detected application against both minimums and rejects an incompatible combination explicitly instead of writing a config the application cannot read.

Model slots

The model_slots[] array declares the model endpoints the application exposes to the user. Each slot carries a label, a description, a kind (such as chat), and a required flag. Bricoop maps each connected provider and model onto a compatible slot; a required slot must be filled before the application can be enabled, while an optional slot is left untouched when no compatible model is selected.

Capabilities

A model slot’s kind and required flag map directly to the capabilities the application declares it needs. A slot with kind: chat declares the Chat capability; a slot that expects tool calls declares Tools. Bricoop intersects the application’s declared needs with each provider’s supported capabilities and only offers compatible models. See the protocol capabilities page for the full negotiation flow.

Example

The example below is a minimal application manifest for Claude Code. It declares one required chat model slot and one file-patch config that writes the provider endpoint into ~/.claude.json.

id: claude-code
name: Claude Code
version: 2.1.158
schema_version: 1
minimal_client_version: 2.0.0
minimal_application_version: 2.1.0
model_slots:
  - label: Default model
    description: Primary model used for chat and tools.
    kind: chat
    required: true
configs:
  - type: file_patch
    format: json
    path:
      macos: ~/.claude.json
      linux: ~/.claude.json
      windows: "%USERPROFILE%\\.claude.json"
    create_if_missing: true
    writes:
      - entry_id: provider
        op: set
        path: providers