Feature request: Host-provided background process management for long-running tools

[JMLX42]

Problem

Currently, Wassette components can maintain state across tool calls (like memory-js), but they cannot run code between tool calls. This prevents use cases like:

• Starting an HTTP server that listens while the LLM does other work
• Running background workers that produce output over time
• Any tool that needs to "stay alive" between invocations

Example scenario:

1. LLM calls: spawn("flask_server_code")  → returns process_id=42
2. LLM thinks, makes HTTP requests to localhost:8080
3. LLM calls: read-stdout(42) → expects server logs

This doesn't work today because the component is frozen between calls - the Flask server never actually runs.

Root Cause

Wassette uses wasmtime's async_support(true) for non-blocking host I/O, but doesn't use wasmtime's background task primitives (Accessor::spawn, StoreContextMut::spawn). The component only executes during a tool call, not between them.

Proposed Solution

Add host-provided imports for background process management. Components would call these host functions rather than trying to run code inside WASM:

interface process-manager {
    type process-id = u64;

    enum signal {
        terminate,  // SIGTERM
        kill,       // SIGKILL
    }

    variant process-state {
        running,
        exited(u32),
        signaled(signal),
    }

    variant process-error {
        invalid-code(string),
        not-found,
        not-running,
        resource-exhausted,
    }

    /// Start a background process (host spawns real thread/process)
    spawn: func(runtime: string, code: string) -> result<process-id, process-error>;

    /// Check process state
    state: func(id: process-id) -> result<process-state, process-error>;

    /// Send termination signal
    signal: func(id: process-id, sig: signal) -> result<_, process-error>;

    /// Read buffered stdout
    read-stdout: func(id: process-id) -> result<string, process-error>;

    /// Read buffered stderr
    read-stderr: func(id: process-id) -> result<string, process-error>;

    /// List all process IDs
    list: func() -> list<process-id>;
}

Key design points:

• Host (Wassette) manages real OS processes/threads, not WASM execution
• Components just hold process IDs and call host functions
• Fits Wassette's deny-by-default security model (new capability to grant)
• runtime parameter allows different interpreters (python, node, etc.)

Implementation Approaches

1. Host-side OS processes: Wassette spawns actual subprocesses for each spawn() call
2. Wasmtime Accessor::spawn: Use wasmtime's concurrent task API to run interpreters in background
3. Hybrid: Lightweight tasks via wasmtime, heavy processes via OS

Use Cases

• AI coding agents: Start a dev server, test it, then shut it down
• Data pipelines: Run background ETL jobs while agent monitors progress
• Interactive tools: REPLs, debuggers, or any stateful CLI tool

Questions for Maintainers

1. Does this align with Wassette's goals?
2. Would this be better as a core feature or a separate "process" capability?
3. Any concerns about security model (sandboxing spawned processes)?
4. Interest in a PR, or should this wait for WASI 0.3 async?

Related

• WASI Issue #414: posix_spawn API
• Wasmtime Accessor::spawn
• WASI Preview 3 async roadmap (mid-2025)

[github-actions]

Agentic Issue Triage triggered by this issue.

[Mossaka]

At the core of this issue is that Wassette does not support long-running tools like HTTP servers. My question about your use cases is that do we really need a Wasm component to own a background process, and that ownership must be sandboxed, instead of splitting the comonent to service + tools and the agent can orchestrate it externally?

[JMLX42]

At the core of this issue is that Wassette does not support long-running tools like HTTP servers. My question about your use cases is that do we really need a Wasm component to own a background process, and that ownership must be sandboxed, instead of splitting the comonent to service + tools and the agent can orchestrate it externally?

A good example is what Claude Code is doing with background processes. It has primitives to start/kill/stream stdin/stdout/stderr to background shell jobs (or processes, not sure). That's how it can - for example - run a long running job and react to specific log lines. Or inspect the status of a running process. Etc...

I'm not sure I understand the difference between:

1. a Wasm component to own a background process, and that ownership must be sandboxed
2. splitting the comonent to service + tools and the agent can orchestrate it externally

It seams to me both cases Wassette has to leverage the WASI runtime to have long/background running processes (which are available since WASI preview 3 and implemented in wasmtime AFAIK).

If you could clarify the 2 different architectures it would help me a lot.