browser start fails on self-hosted: timeout:0 causes immediate daemon shutdown

[rjullien]

Bug

steel browser start --local fails with Connection reset by peer (os error 104) when using a self-hosted steel-browser-api instance.

Daemon log shows: [daemon] Session timeout reached, shutting down

Root cause

The self-hosted API (ghcr.io/steel-dev/steel-browser-api:latest) returns "timeout": 0 in session creation responses. This is hardcoded in sessions.controller.ts.

In the CLI daemon (server.rs), get_session_timeout() returns Some(0). The expiry calculation becomes:

expires_at = created_at + 0 - 30s buffer = already in the past

The expiry_sleep fires immediately on the first select loop iteration, shutting down the daemon before it can accept any commands.

Reproduction

# 1. Deploy steel-browser-api
docker run -p 3000:3000 ghcr.io/steel-dev/steel-browser-api:latest

# 2. Verify the API returns timeout:0
curl -s -X POST http://localhost:3000/v1/sessions \
  -H "Content-Type: application/json" -d "{}" | jq .timeout
# → 0

# 3. Start a browser session
steel browser start --session test --api-url http://localhost:3000/v1
# → Error: Connection reset by peer (os error 104)

Proof

We set up a reverse proxy that rewrites "timeout": 0 to "timeout": 3600000 in session responses. With this patch, the full workflow works: start, navigate, snapshot, click, screenshot, stop.

Suggested fix

In server.rs, treat Some(0) as None (no timeout) instead of 0ms:

let effective_timeout = get_session_timeout(&session)
    .filter(|&t| t > 0)
    .or(params.timeout_ms);

Environment

• CLI: steel 0.3.6
• Server: ghcr.io/steel-dev/steel-browser-api:latest
• OS: Alpine Linux (k8s pod)

[Cruel]

I just independently found this too. Though I made patch to get_session_timeout itself that normalizes 0 as None.