[Bug]: Invalid keepalive interval can crash envd and lose running-process tracking

Start with packages/envd/internal/permissions/keepalive.go, especially GetKeepAliveTicker, then trace its use from packages/envd/internal/services/process/start.go. Run the relevant envd process tests and add a regression case for Keepalive-Ping-Interval: 0. Done means the request returns an error or uses the default interval without restarting envd or losing process tracking.

Sandbox ID or Build ID

Reproduced in disposable, self-hosted local sandboxes, which have been deleted. No E2B Cloud sandbox was involved.

Environment

We discovered this while developing our own Java SDK, which calls the envd API directly rather than using the official Python or JavaScript/TypeScript SDKs. We subsequently reproduced it with direct RPC requests in a local test environment.

• Ubuntu 24.04.5 LTS host, Firecracker sandbox, base template.
• Running envd: 0.9.0 (binary reports commit 51f1726).
• Also inspected runtime main at 112a36052721b254ec09ebcb6c97244d4be35893; the unchecked interval conversion is present there. The VM observations below are from the installed 0.9.0 binary, not a rebuilt main.

Timestamp of the issue

2026-09-20, 01:45:06–01:45:07 PDT (UTC−07:00). The guest journal excerpt below uses UTC.

Frequency

Happens every time with Keepalive-Ping-Interval: 0 in our local reproductions. The control request with 50 succeeds.

Expected behavior

An invalid keepalive interval should be handled at the request boundary, either by returning an argument error or by falling back to the default interval. It should not terminate envd or disrupt other commands in the same sandbox.

Actual behavior

The triggering command's stream fails, and an already-running command's stream also disconnects. Systemd restarts envd, but the original command is no longer tracked by the process API:

• Envd's PID changed from 316 to 1452; NRestarts increased from 0 to 1.
• The pre-existing sleep 60 process, PID 1400, remained alive at OS level with PPID 1.
• The process API returned an empty list; reconnecting to PID 1400 returned process with pid 1400 not found.
• The VM itself stayed running: its boot ID was unchanged, uptime increased, and a file written beforehand remained readable. The control-plane API still reported running.

The sandbox was deleted explicitly only after these observations. This was an envd restart and loss of process tracking, not a VM shutdown.

Issue reproduction

1. Create a disposable sandbox with enough lifetime for the observation (we used 120 seconds).
2. Start sleep 60 normally, retain its PID and stream, and confirm that the process API lists it.
3. Using a direct envd RPC client with the sandbox's usual routing/authentication headers, call process.Start (/process.Process/Start) to run /bin/echo ok, explicitly setting Keepalive-Ping-Interval: 0.
4. Observe both streams disconnect. Allow envd to restart before deleting the sandbox.
5. Check the original PID through the OS and through process.List / process.Connect: the process survives, but envd no longer recognizes it.
6. As a control, repeat with Keepalive-Ping-Interval: 50; the echo command completes normally.

Additional context

This is a lower-priority robustness report from a custom-client integration. The SDK paths we checked send a fixed interval of 50; we have not found a normal official-SDK option that produces the invalid value. 0 is malformed input from our direct API path, not a claimed valid SDK argument. We think this is still worth addressing because one malformed request interrupts unrelated command streams and loses their management state, but we do not consider it an urgent normal-SDK regression.

The likely cause is GetKeepAliveTicker: it falls back for parsing errors, but accepts 0 and passes it to time.NewTicker, which panics for a non-positive duration. process.Start invokes this in a sender goroutine without recovery.

Guest journal from the observed run:

Sep 20 08:45:06.979291 systemd[1]: envd.service: Failed with result 'exit-code'.
Sep 20 08:45:07.140979 systemd[1]: envd.service: Scheduled restart job, restart counter is at 1.
Sep 20 08:45:07.173295 systemd[1]: Started envd.service - Env Daemon Service.

Would a small validation fix with an integration regression test be welcome? We are happy to follow your preference on rejecting invalid intervals versus falling back to the default.