Build extensions

Add a view, transformation, detector, or action to the content people copy. ClipsX supplies the clipboard workspace and manages permission consent, provider credentials, and supported result controls. Your package declares what it needs and implements the workflow through the Extension API.

​

Start with a working example

Follow Build a Rewrite extension to build the first-party source, validate a .clipsx archive, import it locally, and try a harmless text transformation. This route starts from an existing package so you can inspect a working contract before creating your own. Rewrite needs a configured generation model. For examples without an LLM, inspect Base64 or Mermaid Viewer. Their build requirements differ; use the repository’s package instructions.

​

Choose one contribution

Use the Extension API for supported contributions, manifest fields, lifecycle rules, and limits. Start with one contribution and only the permissions that behavior needs. The contract and pinned WIT must match your target desktop host. The WebAssembly interface remains v3.2; extensions that request decision capability declare API ^3.3. Existing ^3.2 packages remain compatible.

​

What belongs to the host

• Consent, invocation limits, provider assignment, credentials, and quarantine.
• Rendering boundaries, supported controls, and accessibility of host-owned UI.
• Durable transformation jobs and results attached to their source clip.
• Compatibility checks when importing or installing packages.

Extensions have no ambient clipboard history, filesystem, shell, or network access. Selected input, generation, network destinations, and external navigation use declared capabilities and applicable local consent. A configured model is required only for packages that request it. Credentials and grants do not synchronize between devices. Changed package bytes require renewed permission review. Automatic transformations store results with the source clip; they do not replace the system clipboard.

​

Decision capability and automation

Compatible transformers can declare decision.text separately from generation.text. The host uses the user’s General decisions assignment; the response is a probability, not generated text or permission to perform an external action. Secret and private source clips cannot use this general capability. See the decision contract for the request, response, permission, and input limits. A user’s Only run when… automation condition belongs to the host. It does not require the extension itself to request decision capability. Conditions select which setup runs; generation writes the result. See conditional automation for rule ordering, sample tests, and failures.

​

Validate locally before distributing

The Rewrite guide provides exact commands. Package tooling can pack, validate, inspect, and test the archive. These checks cover manifest compatibility, assets, limits, and component structure; they do not prove the quality of generated output or every runtime behavior. Test the installed package with sample content, cancellation, and failure cases as well. A local import is for development. Registry publishing uses immutable release archives, checksum and permission metadata, and a separate catalog approval and signing process. Signatures establish package provenance, not a guarantee of safety. See the publication boundary before planning distribution.

​

Contribute in the right repository

• Extension source and issues: package behavior, examples, and workflow proposals.
• Desktop source and issues: host capabilities, desktop behavior, and compatibility problems.
• Registry source: catalog metadata and distribution process.

Include the host version, package version, operating system, reproduction steps, and a harmless sample when reporting a problem. Remove private clipboard content and credentials from logs.