Bug: listInfo() reports detached boxes as "stopped" while VM is still running
Summary
When a box is created with detach: true, the VM continues running after the parent process exits (confirmed via active port forwarding), but listInfo() incorrectly reports "status": "stopped" and "running": false.
Environment
@boxlite-ai/boxlite: latest
- Runtime: Bun v1.3.6 (also reproducible with Node.js)
- OS: Linux x86_64 (WSL2 6.6.87.2-microsoft-standard-WSL2)
Steps to Reproduce
1. Create a detached box with an HTTP server
Save as start-detached.ts:
import { SimpleBox } from "@boxlite-ai/boxlite";
function sleep(ms: number) {
return new Promise((resolve) => setTimeout(resolve, ms));
}
async function main() {
const box = new SimpleBox({
image: "python:slim",
name: "detach-bug-repro",
ports: [{ hostPort: 8080, guestPort: 8080, protocol: "tcp" }],
detach: true,
autoRemove: false,
});
await box.exec(
"sh", "-c",
"python -m http.server 8080 --directory /tmp > /dev/null 2>&1 &"
);
await sleep(2000);
const response = await fetch("http://localhost:8080");
console.log(`Server responding inside process: ${response.status}`);
console.log(`Box ID: ${box.id}`);
console.log("Exiting without calling box.stop()...");
}
main();
bun run start-detached.ts
2. Verify the VM is still running after process exit
curl http://localhost:8080
# Returns directory listing — the VM is alive and serving requests
3. Check what listInfo() reports
bun -e "import { JsBoxlite } from '@boxlite-ai/boxlite'; const r = JsBoxlite.withDefaultConfig(); console.log(JSON.stringify(await r.listInfo(), null, 2))"
Expected Result
{
"id": "...",
"state": {
"status": "running",
"running": true
},
"name": "detach-bug-repro"
}
Actual Result
{
"id": "...",
"state": {
"status": "stopped",
"running": false
},
"name": "detach-bug-repro"
}
The box reports "stopped" even though the VM is actively serving HTTP requests on port 8080.
One additional note it looks like even the CLI reports stopped even though the vm is running and responding to curl requests.
2026-04-08T04:50:37.198197Z INFO boxlite::runtime::rt_impl: Recovering 1 boxes from database
2026-04-08T04:50:37.198284Z INFO boxlite::rootfs::guest: guest_binary_hash: using compile-time hash hash_prefix="6d62325392a9"
2026-04-08T04:50:37.198409Z INFO boxlite::rootfs::guest: gc_inner: scanned boxes for references referenced_count=1 total_records=1
2026-04-08T04:50:37.198436Z INFO boxlite::rootfs::guest: gc_inner: summary total_entries=1 preserved_current=0 preserved_referenced=1 removed=0
2026-04-08T04:50:37.198443Z INFO boxlite::rootfs::guest: GC completed elapsed_ms=0 suffix=-6d62325392a9
2026-04-08T04:50:37.198473Z INFO boxlite::runtime::rt_impl: Box recovery complete
┌──────────────┬─────────────┬─────────┬─────────────────────────┬──────────────────┐
│ ID │ IMAGE │ STATUS │ CREATED │ NAMES │
├──────────────┼─────────────┼─────────┼─────────────────────────┼──────────────────┤
│ CG4TEgntpzAp │ python:slim │ Stopped │ 2026-04-08 04:49:46 UTC │ detach-bug-repro │
└──────────────┴─────────────┴─────────┴─────────────────────────┴──────────────────┘
Bug:
listInfo()reports detached boxes as "stopped" while VM is still runningSummary
When a box is created with
detach: true, the VM continues running after the parent process exits (confirmed via active port forwarding), butlistInfo()incorrectly reports"status": "stopped"and"running": false.Environment
@boxlite-ai/boxlite: latestSteps to Reproduce
1. Create a detached box with an HTTP server
Save as
start-detached.ts:2. Verify the VM is still running after process exit
curl http://localhost:8080 # Returns directory listing — the VM is alive and serving requests3. Check what listInfo() reports
bun -e "import { JsBoxlite } from '@boxlite-ai/boxlite'; const r = JsBoxlite.withDefaultConfig(); console.log(JSON.stringify(await r.listInfo(), null, 2))"Expected Result
{ "id": "...", "state": { "status": "running", "running": true }, "name": "detach-bug-repro" }Actual Result
{ "id": "...", "state": { "status": "stopped", "running": false }, "name": "detach-bug-repro" }The box reports
"stopped"even though the VM is actively serving HTTP requests on port 8080.One additional note it looks like even the CLI reports stopped even though the vm is running and responding to curl requests.