Plugin platform

Plugins

Install plugins, turn them on, inspect what they can access, and run their actions.

↓ on this page

Install
Turn plugins on
Run an action
Inspect what's installed
Trust and permissions
What a package contains

Plugins add data to your listings and new commands to lla. Most users start with the official set of 37.

llahost process

walk

filter

decorate

format

plugin interfacetyped fields, formatting, actions

Native plugin

libplugin.dylib, .so or .dll

Loaded into the host process. Fully trusted, like lla itself.

declared, persisted grants

WebAssembly component

plugin.wasm, sandboxed

readnetworkexecclipboard

lla loads each package through one of two runtimes.

Install

lla install --prebuilt         # the official set
lla install --git <repo-url>   # build from a GitHub repository
lla install --dir ./my-plugin  # build from a local directory
lla update                     # update installed plugins
lla clean                      # remove invalid plugins

The official prebuilt set is available for Linux, macOS and Windows. Static musl builds can't load native plugins, and NetBSD has no prebuilt set. See Platform notes.

Prebuilt packages must include a checksums.toml, and installation fails if any covered file has changed. Source installs build the plugin and create that file for you.

Turn plugins on

Installing a plugin doesn't turn it on. lla use opens a checklist:

The interactive plugin manager, a checklist of installed plugins with their versions. — `lla use`

You can also list plugins in your config, or use the flags. --enable-plugin and --disable-plugin update enabled_plugins in your config, so the change lasts beyond the current run.

enabled_plugins = ["file_hash", "project_context"]

lla --enable-plugin file_hash
lla --disable-plugin file_hash
lla list-plugins

An enabled plugin adds its output to the views it supports:

A long listing in which each file also shows its SHA-1 and SHA-256 hashes. — `lla -l --hide-group sdk` with `file_hash` on.

Its typed fields also appear under plugin in JSON output, and you can show them as field:<name> columns.

Run an action

Actions are commands provided by a plugin. They work whether or not the plugin decorates your listings.

lla plugin run <plugin> <action> -- <arguments>
lla plugin run <plugin> <action> --output json -- <arguments>

--output accepts human, json, ndjson or csv. Interactive actions need a terminal and only support human.

The project_context plugin's inspect action, summarizing a repository's type, toolchain and health. — `lla plugin run project_context inspect -- .`

The older lla plugin <plugin> <action> form is deprecated during the 0.6.x series. To give a frequent action a shorter name, create a shortcut.

Inspect what's installed

lla plugin info project_context
lla plugin permissions file_hash
lla plugin doctor

Details of one plugin, with its version, runtime, capabilities, fields and actions. — `lla plugin info project_context`

lla plugin doctor checks that each package's manifest matches its compiled plugin, validates the checksums and exercises the plugin contract, without touching the plugin's normal data directory. Run it after installing something new.

The plugin doctor report, listing each plugin with its check results. — `lla plugin doctor`

Trust and permissions

The two runtimes offer very different guarantees.

	Native	WebAssembly
Package contains	A shared library (`.so`, `.dylib`, `.dll`)	A `.wasm` component
Runs	Inside the lla process	In a sandbox
Declared permissions	Shown to you, but not enforced	Enforced, and denied by default
Trust it as much as	Any program you install	The access you grant it

Install native plugins only from sources you trust.

WebAssembly plugins can receive scoped filesystem access, HTTP access to specific domains, and gated access to the clipboard and opening URLs. They can't use raw sockets or run subprocesses. Your grants are saved in plugin-grants.toml, and an update that asks for more access prompts you again.

WebAssembly support needs a build with the wasm-plugins feature. Official Linux, macOS and Windows releases have it, and the NetBSD release doesn't.

What a package contains

my-plugin/
├── plugin.toml        # the manifest
├── libmy_plugin.so    # .dylib on macOS, .dll on Windows, or a .wasm component
├── checksums.toml     # SHA-256 of every file
└── README.md          # optional

To write your own, follow the plugin tutorial. The manifest reference lists every field, and migrating to v3 covers plugins written for older versions.