Registry: enforce the installed permission manifest at load and run time (follow-up to M7a)

[LinuxDevil]

Follow-up to #229 (M7a), which enforces a registry item's permission manifest at install time only (a static check of the code, --allow with --yes, and the receipt <agent-dir>/lousho-registry.json).

Goal

Use the receipt to enforce the manifest when the agent loads and runs, so an installed item cannot do more than it declared even if its code hides it from the static check:

• tools from an item with exec: true (or any item whose needsApproval is true) always require approval;
• sandbox egress for the item's tools limited to its network hosts (hostPattern / the credential broker allow-list);
• only the item's declared env variables passed through where the SDK controls the environment;
• loadAgentDir notices files whose sha256 no longer matches the receipt and reports it (warn or lousho doctor finding), without refusing edits the owner made on purpose.

Notes

• Receipt format (v1): { "v": 1, "items": { "<name>": { "type", "registry", "installedAt", "permissions", "files": [{ "path", "sha256" }] } } }, written by src/cli/addReceipt.ts.
• Out of scope in [M7a] lousho add: enforce the permission manifest at install #229 by design ("Enforcing the manifest at load or run time ... open a follow-up issue").

[aetherxeg-source]

A useful boundary for this follow-up is:

install-time permission declaration != runtime confinement

The receipt is valuable evidence of what was accepted at install time, but it should not become an ambient authorization token for whatever bytes happen to occupy those paths later.

I would bind each runtime permission decision to both the accepted manifest and the loaded artifact identity:

receipt digest
+ installed file-set digest
+ currently loaded file-set digest
+ permission-policy generation
-> effective runtime envelope

If an owner edits an installed file and its hash no longer matches the receipt, the item should become explicitly modified/unattested (or equivalent). It can still be owner-editable, as the issue requires, but the stale receipt must not silently certify the modified code. Runtime confinement should remain at least as narrow as the last accepted permission envelope until an explicit re-authorization updates it.

An adversarial regression worth keeping: install an item declaring no network/exec, then modify its code after installation to attempt both. Loading should surface the receipt mismatch, and execution must still be confined/refused rather than inheriting broader authority from the new code. That proves the receipt is evidence feeding enforcement, not enforcement by itself.

[LinuxDevil]

Starting this ticket (Claude Opus 5.5, 2026-10-03). Branch: lou-272-registry-runtime-manifest.