[Bug] Desktop Kimi Work python-run spawned thousands of runner.py processes on Windows

What version of Kimi Code is running?

This happened in the Desktop Kimi Work / Daimon bundled runtime, not in the standalone console kimi command.

• Desktop Daimon releaseVersion: 0.5.27
• Bundled kimi-code runtime upstreamVersion: 0.12.3
• Bundled kimi-code upstreamCommit: 18f299fd0b266545a1f7cebae9f58b83b9d9776e
• Runtime packages listed in the bundle: @moonshot-ai/agent-core, @moonshot-ai/kimi-code-sdk, @moonshot-ai/kimi-code-oauth, @moonshot-ai/kimi-telemetry
• Standalone console kimi --version on the same machine: kimi, version 1.41.0 (included for clarity; this was not the process tree that exploded)

Which open platform/subscription were you using?

Desktop Kimi Work / managed Daimon runtime, using daimon-kimi-code.

Which model were you using?

daimon-kimi-code

What platform is your computer?

Microsoft Windows NT 10.0.26200.0 x64

What issue are you seeing?

Desktop Kimi Work / Daimon python-run spawned a runaway process tree on Windows:

• About 11,500 python.exe processes were present.
• Most of them came from the bundled Desktop Kimi Work runtime:

<user-profile>\AppData\Roaming\kimi-desktop\daimon-share\daimon\runtime\python\.venv\Scripts\python.exe
<user-profile>\AppData\Roaming\kimi-desktop\daimon-share\daimon\runtime\python\runner.py --module <user-profile>\AppData\Roaming\kimi-desktop\daimon-share\daimon\agents\main\code\python-run\<runId>\script.py --fn main --context <temp>\kimi-daimon-python-...\context.json

• The process tree looked like repeated python.exe -> python.exe -> python.exe parent/child chaining with the same runner command line.
• CPU was saturated at 100%; % Idle Time was 0.
• Windows Processor Queue Length was observed in the high double digits to thousands during the incident.
• The Python process storm accounted for roughly 47.6 GB of RAM.
• Many processes were tiny, around 4 MB working set each, which made it look like a runaway spawn/respawn loop rather than one normal heavy Python job.
• vmmem, WSL, Docker, and Hyper-V were checked separately and ruled out as the culprit. WSL distros were stopped, Docker was not active, and the Hyper-V vmmem processes corresponded to legitimate VMs.

The specific task context found locally:

scope: interactive
runId/taskId: 7c77a250-cd24-4a3c-9710-0fe66de8951a
triggeredAt: 2026-06-25T19:40:15.648Z
runtimeRoot: <user-profile>\AppData\Roaming\kimi-desktop\daimon-share\daimon\runtime\python

The user script for that task was inspected locally. It was a normal JSON/text-processing script and did not contain direct process-spawning calls such as subprocess, multiprocessing, Popen, os.system, fork, or spawn.

What steps can reproduce the bug?

I do not have a deterministic minimal reproduction yet. This was observed from the live Windows process table after a Desktop Kimi Work interactive python-run task.

The observed trigger was:

1. Use Desktop Kimi Work on Windows.
2. Let it run an interactive Python tool task using the bundled Daimon runtime.
3. The task command line matched:

<daimon>\runtime\python\.venv\Scripts\python.exe <daimon>\runtime\python\runner.py --module <daimon>\agents\main\code\python-run\<runId>\script.py --fn main --context <temp>\kimi-daimon-python-...\context.json

4. Instead of one bounded Python execution, the machine accumulated thousands of identical/similar python.exe runner processes until the OS was effectively saturated.

What is the expected behavior?

python-run should execute as a bounded task:

• one primary runner process, or a small bounded process tree;
• no self-replicating runner.py chain;
• per-task process limits on Windows;
• robust cleanup of the whole task process tree on completion, failure, cancellation, or agent/runtime restart;
• timeout and respawn-loop protection;
• diagnostic logging when a tool task attempts to spawn an abnormal number of child processes.

Additional information

Recovery required killing the storm and temporarily disabling the bundled task/runtime entry points to stop respawning:

<daimon>\agents\main\code\python-run\<runId>\script.py
<daimon>\runtime\python\runner.py
<daimon>\runtime\python\.venv\Scripts\python.exe

After cleanup:

ExactKimiRuntimePython: 0
PythonTotal: 13
SmallUnder10MB: 0
ProcessTotal: 265
ProcessorQueueLength: 0

I am intentionally not attaching config.json, raw context files, full local logs, or screenshots because they may contain tokens, credentials, private paths, or local workspace data. I can provide redacted diagnostics if needed.

Duplicate search performed before filing

I searched open and closed issues/PRs in this repository before opening this:

• Issues: python-run, runner.py, daimon, python.exe, thousands python, many python, process storm, fork bomb, CPU 100, memory leak, runaway, Desktop Kimi Work, Kimi Work, vmmem, python runner
• PRs: python-run, runner.py, daimon, python.exe, process storm, fork bomb, spawn, runaway, Desktop Kimi Work, Kimi Work

Closest non-duplicates I found:

• #234: Windows dev script spawn EINVAL / thinking refresh flicker, but not a Python runner process storm.
• #705: provider API/tool call mismatch, unrelated to local process spawning.
• #886 / #899 / #909: Windows Python MCP stdio encoding fixes, unrelated to runaway python-run.
• #1038 / #641: process-tree/background cleanup work, possibly adjacent, but not this specific python-run Windows process storm.

Start by inspecting the bundled runtime/python/runner.py and the agents/main/code/python-run//script.py entry point, then review the process-tree cleanup work referenced in issues #1038 and #641. Use the reported Windows command line and redacted diagnostics to investigate how repeated runner processes arise. Done means bounded task execution, cleanup on termination, and protection against runaway respawning.