Server-side plugin execution

Running a plugin on your laptop protects you. It does not protect the repository, because a client gate is only as good as the client — a push from a machine that skipped it arrives just the same. A hosted Forge closes that by running the plugin itself, server-side, and attesting the result.

What the runner guarantees

The contract is deliberately identical to the local sandbox wherever it can be, and stricter where it cannot:

• The same closed surface. Guests run behind exactly the WASI stdio surface the local sandbox exposes — no network, no filesystem, no ambient environment, and a deterministic clock and randomness.
• The same contracts. The unmodified input and result schemas, coerced through the same fail-closed validation. Absent, malformed, schema-invalid, or mismatched on plugin id or event all become error, never a pass.
• Capabilities computed platform-side. The intersection is computed from the validated, integrity-re-verified manifest, and it can only tighten. read_protected_plaintext and network_access are structurally ungrantable server-side — not merely off by default.
• A fresh instance per execution.
• Every failure maps closed. A required plugin's runner fault produces a non-success check, or none, and the default-closed gate blocks.
• Results are metadata-only. Detail, events, and webhook payloads are synthesised from result metadata, never from guest-authored strings.

The runner self-attests under a policy-visible identity — the Forge's own serving identity — so its results satisfy the attester requirement described in Plugin policy on a Forge. Its check identity derives from the server-side registration record for that repository, never from anything the guest emitted.

When it runs

Executing at propose and amend rather than at approval time is the point: there is no window in which the gate reads a result that no longer describes the current revision.

Registering a plugin

A hosted registration is stricter than a local install, because a hosted plugin is a gate authority rather than a personal tool. Registration is refused with TVO-PLUGIN-016 when the package:

• declares local_dev or otherwise unverifiable integrity — valid locally, never as a server-side gate;
• has an artifact whose recomputed hash does not match the manifest;
• exceeds the artifact size cap;
• is not a valid WASM module; or
• is denied by the organisation plugin policy at upload.

Nothing is stored on refusal — the package is validated before any write. The fix is to rebuild with a signed integrity block whose hash matches the artifact bytes, keep it under the cap, and get the id or publisher permitted.

The compute ceiling

The adapter records per-repository invocation and CPU-time counters and reserves against a single plan-agnostic safety ceiling before it dispatches. This is an operational bound, not a commercial meter — there is no billing error, no plan allowance, and no priced overage for plugin execution.

What matters operationally is how a denial presents: a reservation denial becomes a metadata-only failing check, exactly like any other fail-closed outcome. So a required plugin blocks and an advisory one does not, and the symptom looks like a plugin failure rather than a quota message. If a required plugin starts blocking on a busy repository with no change to the plugin itself, the ceiling is worth ruling out.

Server-side secret scanning

The same default scanner can run server-side at land time under this contract, so a secret cannot slip in via a push that bypassed the client gate. That is the natural reason to want a server-side runner even if you never write a plugin of your own.

Status

The runner contract is runner-neutral and is realised first by the hosted adapter. The native reference Forge stays attestation-only — it decides, it does not execute — and a native runner is a follow-on. If you self-host the native Forge, your plugin results have to come from a trusted CI or attestation service that you designate in the policy's attesters list.