[Feat]: Research spike — subprocess worker isolation for skill execute() (sub-issue of #17)

[rosspeili]

Feature Description

Sub-issue of #17. Research spike (not necessarily merge-ready): evaluate a medium-weight isolation option between trust flags (17b) and Docker/WASM.

Questions to answer in a short design note (docs/security/subprocess-isolation-spike.md or comment on #17):

1. Can skill.execute(params) run in a subprocess with:

   • Timeout
   • Restricted env (ties to 17c)
   • JSON-serializable params/results only
   • No shared filesystem except explicit temp paths?

2. What breaks for current registry skills?

   • pdf_form_filler (pymupdf, file paths)
   • mica_module (in-memory corpus)
   • wallet_screening (local JSON datasets)
   • Skills relying on import side effects at module load

3. Performance impact on agent loops (latency per tool call)

4. Recommendation: adopt / defer / hybrid (subprocess only for marked execution_mode: isolated in manifest)

Deliverable: design note + optional prototype behind feature flag (can be throwaway branch)

Out of scope: Production default for all skills in this spike

Rationale

#17 lists WASM and Docker as heavy options. A subprocess worker may cover many skills that use pure Python + HTTP without container ops overhead. Need evidence before committing framework-wide.

Implementation Idea

• Spike: SkillLoader.execute_isolated(skill, params, timeout=30) using multiprocessing or subprocess + pickle/json round-trip
• Prototype manifest flag: execution: in_process | subprocess (RFC only — do not standardize without parent [RFC]: Security Sandboxing Strategies for Untrusted Skills #17 decision)
• Document failure modes (non-serializable returns, Windows spawn quirks)
• Post findings as PR or doc; link from [RFC]: Security Sandboxing Strategies for Untrusted Skills #17