[Bug] Kimi Work 3.2.24: synchronous ENOTCONN escapes HostProcessService.spawn and terminates Daimon #4749

What version of Kimi Code is running?

Kimi Work desktop 3.2.24 (Windows packaged runtime):- Electron 43.7.7- Node.js 24.21.0- Chrome 150.0.7871.250- V8 15.0.245.31-electron.0- libuv 1.52.1

Which open platform/subscription were you using?

Kimi Work desktop account. The exact subscription-plan identifier was not determined from the sanitized diagnostic evidence.

Which model were you using?

k3d1-agent, with agent-swarm activity present around several incidents. Parallel activity is a correlation, not an established trigger.

What platform is your computer?

Microsoft Windows 10.0.26300 x64

What issue are you seeing?

Kimi Work repeatedly terminated its managed Daimon runtime and interrupted active turns after read ENOTCONN was thrown synchronously during child-process creation.

Representative sanitized stack:

Error: read ENOTCONN
    at tryReadStart (node:net:1005:20)
    at Socket._read (node:net:1020:5)
    at Readable.read (node:internal/streams/readable:750:12)
    at Socket.read (node:net:1074:39)
    at new Socket (node:net:712:12)
    at Object.Socket (node:net:550:41)
    at createSocket (node:internal/child_process:337:14)
    at ChildProcess.spawn (node:internal/child_process:492:23)
    at spawn (node:child_process:827:9)
    at HostProcessService.spawn (.../kernel-bundle.mjs:165155:17)

The shipped bundle and current main both place the process factory call immediately before the guarded region:

const spawnOptions = buildSpawnOptions(options);
const child = spawn(command, args as string[], spawnOptions);
try {
  await waitForSpawn(child);
} catch (error) {
  // Converts failures from waitForSpawn to HostProcessError(SpawnFailed).
}

A synchronous pipe/setup exception therefore bypasses the intended HostProcessError(HostProcessErrorCode.SpawnFailed) conversion and reaches the process-level fatal handler. Instead of failing only the affected operation, the runtime shuts down and the active turn is interrupted.

The copied logs contain four occurrences on 2026-11-08 at 01:26:23, 07:59:58, 08:06:06, and 08:18:49 local time, plus an earlier occurrence on 2026-11-07 at 00:47:29. Each selected occurrence is associated with an interrupted turn. Sanitized records are included in the attached evidence package.

What steps can reproduce the bug?

The actual Windows pipe disconnect is not yet reproduced. The attached minimal offline harness deterministically reproduces the exception-containment defect by injecting a synchronous ENOTCONN at the process-factory boundary. It does not assert an upstream Node.js/libuv defect or claim to reproduce the real pipe race.

From the attached package, using Node.js 24.21.0:

node reproduction/repro.cjs vulnerable

Expected vulnerable result: exit code 86 and a process_level_fatal_boundary record containing raw Error with code ENOTCONN. The synthetic process boundary is used only to capture the escaped fault safely in a standalone child process.

node reproduction/repro.cjs control

Expected control result: exit code 0 and an operation_level_spawn_failure record with contained: true, HostProcessError, code SpawnFailed, and cause code ENOTCONN.

Captured verification results:

• 20/20 vulnerable runs reached the synthetic process-level boundary with raw ENOTCONN.
• 20/20 control runs contained and normalized the identical injected fault.
• 1/1 static source checks confirmed spawn at copied-bundle line 165155 precedes try at line 165156.
• 12/12 independent capture checks passed, including all 166 capture-file hashes.
• 10/10 final package checks passed, including packaged smoke tests and a privacy rescan.

The full harness uses the same Kimi Electron executable in standalone ELECTRON_RUN_AS_NODE=1 mode. It does not run inside or modify the Daimon process, installed bundle, or user configuration.

What is the expected behavior?

A synchronous process-creation failure should be contained by HostProcessService.spawn, normalized to HostProcessError(SpawnFailed) with the original error preserved as cause, and propagated only to the affected caller/turn. It should not invoke the process-level fatal handler or terminate the managed runtime.

Requested durable correction:

1. Move spawn(command, args, spawnOptions) into the same guarded region as waitForSpawn(child).
2. Normalize synchronous process-creation exceptions and asynchronous spawn failures through the same error contract.
3. Preserve sanitized command/cwd/errno diagnostics without exposing credentials or sensitive argument contents.
4. Clean up partial child/pipe resources on every failure path.
5. Add regression tests for synchronous ENOTCONN, other synchronous setup failures, asynchronous errors, parallel launches, and cleanup. Tests should prove that contained failures do not invoke runtime shutdown and unrelated operations survive.

Additional information

Attached file: kimi_work_3.2.24_enotconn_defect_package.zip

SHA-256:

6a47f926cbb2b9621a8a55da773380206ba9ac57aa06fa418e2fd28494dd9993

The package contains the full report, reproduction scripts, captured command/stdout/stderr/exit-code records, minimal sanitized log and source excerpts, environment metadata, privacy scan, and SHA-256 manifests. Account, installation, conversation, segment, trace, credential, and unrelated private-path data were excluded or redacted. ZIP CRC validation passed with 179 files.

Explicit unknowns:

• The exact child command and reason its Windows pipe became disconnected are unknown.
• The real Windows pipe race/disconnect has not been reproduced.
• Parallel agents are not established as the sole or necessary trigger.
• This report does not assert an upstream Node.js or libuv defect.
• The control path demonstrates containment; it is not an installed fix or workaround.

Duplicate search performed before drafting: no exact read ENOTCONN issue was found in the tracker searches performed. #3236 and PR #4309 concern Windows batch-shim resolution in the same service, not synchronous ENOTCONN containment, so they appear related but not duplicates.

kimi_work_3.2.24_enotconn_defect_package.zip

Contribution

• I am willing to submit a PR for this bug fix myself (please wait for maintainer approval in this issue first)