mirror of
https://github.com/Kilo-Org/kilocode.git
synced 2026-08-29 03:32:08 +08:00
kirillk
0ff7a3be3e
On Windows the spawned `kilo serve` process could outlive the IDE and then block the next IDE launch (a surviving child inherits IDE handles). The app-close teardown also deadlocked: closeForShutdown() closed the CLI's streams before killing it, and on Windows closing a process stream while a reader thread is mid-read hangs until the process dies — so IDE shutdown blocked, the JVM stayed alive, the kill-on-close job never fired, and the CLI lingered until killed by hand (which is what unblocked restart). - Bind the CLI tree to the IDE via a Windows Job Object with JOB_OBJECT_LIMIT_KILL_ON_JOB_CLOSE, so the OS terminates the tree when the IDE exits for any reason (clean exit, halt(), crash, force-kill). - Reorder app-close teardown to kill first, then close streams (shutdownTree), removing the deadlock. Order is regression-tested. - Map the Job Object kernel32 functions directly (the IDE's bundled JNA omits them) using only the platform's core JNA; JNA is not bundled to avoid a jnidispatch collision. Guard on JnaLoader.isLoaded() before any Native access and release handles via try/finally ownership. - Best-effort / Windows-only: assign() returns null off-Windows, without JNA, on non-64-bit, or on any native failure, so callers keep the existing process-tree kill. No CLI changes. Adds diagnostics on the setup/app-close paths, a Windows-gated integration test, and ordering regression tests. Known limitation: kill-on-close also terminates `persistent=true` background processes on Windows; full support needs a coordinated CLI breakaway change (CREATE_BREAKAWAY_FROM_JOB + JOB_OBJECT_LIMIT_BREAKAWAY_OK).