Guest resource drops do not release host-side WASI handles #560

Problem

When a Wasm guest drops a host-owned resource such as a WASI descriptor, stream, or directory-entry stream, hyperlight-wasm does not notify the host that the resource was released. The generated host resource table therefore retains the entry, and host-side implementations cannot safely distinguish closed resources from resources intentionally retained by a stateful guest.

This becomes visible in long-lived sandboxes that preserve state across executions. In hyperlight-dev/hyperlight-sandbox#250, a regression test opened and closed 600 unique output files in one run and another 600 in the next. Without run-boundary cleanup, the second run failed on file 424 when CapFs reached its 1,024 open-handle limit:

OSError: [Errno 29] I/O error: '/output/second-424.txt'

Clearing all host handles at each execution boundary avoids the leak, but it also means a guest file object retained in interpreter memory cannot remain usable across runs. Keeping all handles preserves live objects but leaks every resource the guest has already closed.

Expected behavior

Dropping a guest-owned host resource should notify the host and release or return the corresponding host resource-table entry. Host implementations could then clean up closed descriptors and streams while preserving genuinely live resources across executions.

References

• Upstream component-binding tracking issue: impl Drop for host resources in the guest hyperlight#810
• Sandbox behavior and concrete reproduction: Preserve output files across sandbox runs hyperlight-sandbox#250