Expand description
M5: effect runtime + sandbox. See spec §7.4 and §8.5.
What’s here:
policy::Policyandpolicy::check_program— the static capability gate that walks declared effects and rejects programs whose effects are out of bounds before any code runs.handler::DefaultHandler— the host-side effect handler that the VM dispatchesEFFECT_CALLthrough.
What’s not here yet (deferred):
- WASM-level isolation (
wasmtimeintegration). The--unsafe-no-sandboxflag in the spec is operationally implicit for now: native execution only. We ship the policy/dispatch layer, which is the user-visible half of §7.4 and what the §7.6 acceptance tests exercise.
Re-exports§
pub use builtins::is_pure_module;pub use builtins::try_pure_builtin;pub use handler::CapturedSink;pub use handler::DefaultHandler;pub use handler::IoSink;pub use handler::StdoutSink;pub use policy::check_program;pub use policy::Policy;pub use policy::PolicyReport;pub use policy::PolicyViolation;
Modules§
- builtins
- Pure stdlib builtins — string, numeric, list, option, result, json
ops dispatched via the same
EffectHandlerinterface as effects, but without policy gates (they have no observable side effects). - handler
- Native effect handlers, dispatched at runtime through the VM’s
EffectHandlertrait. The handler also re-checks the runtime policy per spec §7.4 (the static check is necessary but not sufficient: a fn declared[fs_read("/data")]that’s allowed at startup still has to pass the path check at the point of dispatch). - llm
- HTTP-backed LLM completions for the
[llm_local]and[llm_cloud]effects (#196). - mcp_
client - Minimal stdio MCP (Model Context Protocol) client for the
agent.call_mcpbuiltin (#185). Spawns the named MCP server as a subprocess, completes theinitializehandshake, then forwards atools/callrequest and returns the result. - policy
- Capability/policy layer per spec §7.4.
- ws
- WebSocket server + chat-broadcast registry.