Loguru rotation fails with PermissionError on Windows when multiple kimi processes run

[SunYunP]

Bug Report: Loguru rotation fails with PermissionError on Windows when multiple kimi processes run

What version of Kimi Code CLI is running?

(latest via uv tool install)

What platform is your computer?

Windows (WinError 32)

What issue are you seeing?

When multiple kimi-cli processes are running concurrently on Windows, log rotation triggers a PermissionError: [WinError 32] 另一个程序正在使用此文件.

Error stack:
--- Logging error in Loguru Handler #1 --- PermissionError: [WinError 32] 另一个程序正在使用此文件，进程无法访问。: C:\Users.kimi\logs\kimi.log -> C:\Users.kimi\logs\kimi.2026-05-19_11-22-27_792377.log Traceback (mos
t recent call last): File ...\loguru_handler.py, line 206, in emit self._sink.write(str_record) File ...\loguru_file_sink.py, line 204, in write self._terminate_file(is_rotating=True) File ...\loguru_file_sink.py, line 276, in _
terminate_file os.rename(old_path, renamed_path)

Root Cause Analysis

In kimi_cli/app.py, enable_logging() hardcodes a single shared log file:

logger.add(
    get_share_dir() / "logs" / "kimi.log",
    rotation="06:00",
    retention="10 days",
)

Multiple kimi processes (main CLI, kimi bg-worker, kimi web workers) all write to the same file. When rotation="06:00" triggers, Loguru calls os.rename() to archive the old file. On Windows, os.rename fails if any other process
holds the file handle — unlike Linux/macOS which allow renaming open files.

This is a well-known Loguru limitation on Windows (see Delgan/loguru#1170, Delgan/loguru#491).

Steps to Reproduce
──────────────────

1. On Windows, run kimi web in one terminal (or leave a background worker running)
2. Open another terminal and run kimi to start a CLI session
3. Wait for 06:00 rotation (or trigger high log volume), or simply have both processes running when the daily rotation hits
4. The second process logging after rotation will throw PermissionError
What is the expected behavior?
──────────────────────────────

Multiple kimi processes should coexist on Windows without log rotation crashing the logger. Options:

• Per-process log files: Include PID in the filename (e.g., kimi.<pid>.log)
• Per-subcommand log files: Separate files for CLI / web / worker
• Disable rotation for non-primary processes: Only the main CLI rotates; workers write without rotation or to stderr only
• User-configurable log path: Allow overriding the hardcoded ~/.kimi/logs/kimi.log via config or env var
Additional information
──────────────────────

• Current workaround: Avoid running multiple kimi processes simultaneously on Windows
• Logs directory state at time of error: existing rotated files present alongside locked kimi.log
• This issue is Windows-specific; does not occur on Linux/macOS due to different file locking semantics

---