kuri v0.4.1 logs listening but closes HTTP listener while attaching to CDP

[yxlyx]

Summary

kuri v0.4.1 logs that it is listening, but its HTTP listener disappears immediately while the process remains alive and connected to Chrome CDP. This blocks browser verification in the coding harness.

Environment

• macOS
• kuri v0.4.1
• Chrome CDP healthy on 127.0.0.1:9222
• Browser reports Chrome 150 / protocol 1.3

Reproduction

CDP_URL=http://127.0.0.1:9222 kuri
# or:
nohup env PORT=8080 CDP_URL=http://127.0.0.1:9222 kuri >kuri.log 2>&1 &

The log says:

info: listening on 127.0.0.1:8080
info: connecting to existing Chrome at http://127.0.0.1:9222
info: CDP endpoint: ws://127.0.0.1:9222/devtools/browser/...
info: CDP port: 9222

But immediately afterward:

curl http://127.0.0.1:8080/health
# curl: (7) Failed to connect: Connection refused

lsof -nP -iTCP:8080 -sTCP:LISTEN
# no output

The kuri process remains alive. lsof -p <pid> shows established connections to 127.0.0.1:9222, but no listening socket. The same behavior occurs on a fresh port (8081), with the /json/version CDP URL, and with the CDP origin URL.

Expected

The authenticated Kuri HTTP API remains listening after CDP attachment, or the process exits with an actionable error instead of logging a stale listening state.