Summary
Every kane-cli install skill invocation on Windows terminates with a libuv assertion:
Assertion failed: !(handle->flags & UV_HANDLE_CLOSING), file src\win\async.c, line 94
Exit code is 0 and the install result is correct, so nothing functionally breaks — but a clean no-op prints what reads as a crash, which is corrosive in CI logs and in front of an audience during a demo.
The important detail
It reproduces on the already-installed short-circuit path, where nothing is downloaded, nothing is extracted and nothing is written:
$ kane-cli install skill
{"type":"skill_install_result","status":"already-installed","version":"0.0.15","installed_targets":0}
Assertion failed: !(handle->flags & UV_HANDLE_CLOSING), file src\win\async.c, line 94
So this is not the tar/extraction path from #117 — it is process teardown. Something closes a libuv handle that is already closing.
Not a regression — and the line number is informative
Bisected across installs with the skill pinned at 0.0.15 throughout:
| kane-cli |
Runtime |
Assertion |
| 0.6.4 |
system Node v24.14.1 |
src\win\async.c, line 76 |
| 0.6.6 |
bundled kane-cli-node-win32 |
src\win\async.c, line 94 |
| 0.6.7 |
bundled kane-cli-node-win32 |
src\win\async.c, line 94 |
The line number tracks the runtime, not the CLI version — 0.6.4 predates the bundled Node runtime introduced in 0.6.6. That it reproduces identically under two different Node builds points at a genuine shutdown-ordering fault in the CLI rather than a quirk of one Node version.
Scope
Not observed on kane-cli whoami or kane-cli --version, so it is specific to install skill's shutdown sequence rather than a general CLI teardown problem.
Ask
Close (or unref) whatever async handle install skill leaves open before exit — most likely an update-check timer, an HTTP agent socket, or a progress/spinner handle that is torn down twice on the early-return path when the skill is already installed.
Environment
kane-cli 0.6.4 / 0.6.6 / 0.6.7 · skill 0.0.15 · Node v24.14.1 · Windows 11 Pro 26200 · Git Bash · account toddl
Summary
Every
kane-cli install skillinvocation on Windows terminates with a libuv assertion:Exit code is
0and the install result is correct, so nothing functionally breaks — but a clean no-op prints what reads as a crash, which is corrosive in CI logs and in front of an audience during a demo.The important detail
It reproduces on the
already-installedshort-circuit path, where nothing is downloaded, nothing is extracted and nothing is written:So this is not the tar/extraction path from #117 — it is process teardown. Something closes a libuv handle that is already closing.
Not a regression — and the line number is informative
Bisected across installs with the skill pinned at
0.0.15throughout:src\win\async.c, line 76kane-cli-node-win32src\win\async.c, line 94kane-cli-node-win32src\win\async.c, line 94The line number tracks the runtime, not the CLI version — 0.6.4 predates the bundled Node runtime introduced in 0.6.6. That it reproduces identically under two different Node builds points at a genuine shutdown-ordering fault in the CLI rather than a quirk of one Node version.
Scope
Not observed on
kane-cli whoamiorkane-cli --version, so it is specific toinstall skill's shutdown sequence rather than a general CLI teardown problem.Ask
Close (or
unref) whatever async handleinstall skillleaves open before exit — most likely an update-check timer, an HTTP agent socket, or a progress/spinner handle that is torn down twice on the early-return path when the skill is already installed.Environment
kane-cli
0.6.4/0.6.6/0.6.7· skill0.0.15· Nodev24.14.1· Windows 11 Pro 26200 · Git Bash · accounttoddl