Plugins
A plugin adds an action. The important part is what it is not allowed to be.
What a plugin actually is
An action plugin runs in Jint — a JavaScript interpreter written in C# — and returns a shell snippet. It does not perform the work; Walis runs the shell it produced.
That single constraint is what makes plugins readable: before installing one, you can see exactly what it will put into your build. Compare with Jenkins, where a plugin runs unsandboxed in the controller's JVM and can do anything the controller can.
Capabilities
A plugin has only the capabilities its manifest declares:
- Network — outbound access is allowed to named domains and nothing else.
- Secrets — a plugin can ask for a secret to be injected into a request header via
withSecret. It cannot read the value.
Capabilities not declared do not exist. There is no ambient permission.
Resource ceilings
| Limit | Value |
|---|---|
| Timeout | 10 seconds |
| Memory | 8 MB |
| Statements | 500,000 |
| Recursion depth | 64 |
These bound the generation of the snippet, not the build the snippet then runs.
AI drafting
The plugin screen can draft a plugin from a description. Anything it produces has permissions cleared, type and version forced, and is never installed automatically — model output is treated exactly like text a stranger pasted in, because that is what it is.
Who can install
/api/plugins is administrator-only. Installing a plugin means adding code that will run on this machine, so it is not delegated to the operator role.
Development
The Development guide tab in the app carries the current host API. The project's Docs/plugin-development.md covers the threat model, and @walisayu/plugin-sdk provides types, a local test harness, an esbuild bundler and a walis-plugin CLI.
Escaping rules, parameter defaults and domain matching must match the host exactly — there are tests on both sides pinning that, because a mismatch is how a sandbox escape starts.