fix(logging): isolate Windows process log files

[lihailong00]

Summary

• use kimi.<pid>.log on Windows so concurrent processes do not rotate the same open file
• retain kimi.log on non-Windows platforms
• point fatal-error output at the effective log path

Reproduction and verification

Two real Windows Python processes sharing Loguru's rotating kimi.log deterministically reproduced PermissionError: [WinError 32]. The new multi-process regression test verifies distinct files and successful rotation.

• targeted logging and CLI tests — 10 passed locally (31 passed in the broader diagnostic run)
• targeted Ruff and Pyright — passed

This is an improved revival of closed #2354: it adds an actual Windows multi-process rotation test instead of only mocked path tests.

Closes #2348

---

[devin-ai-integration]

Devin Review found 1 potential issue.

[devin-ai-integration]

🟡 Old Windows log files are never deleted, causing disk usage to grow forever

On Windows each run writes to a new per-process log file (kimi.{os.getpid()}.log at src/kimi_cli/utils/logging.py:25), but Loguru's retention="10 days" only removes rotated files that match the current process's own filename, so log files from previously exited processes are never cleaned up.
Impact: On Windows the logs directory grows without bound across CLI invocations, since the retention policy no longer bounds the total set of log files.

Why retention no longer bounds the log directory on Windows

Loguru's retention derives its cleanup glob from the sink's own filename. For a sink named kimi.<pid>.log, the retention pattern only matches files beginning with kimi.<pid> — it cannot see kimi.<other-pid>.log files created by other/previous processes. Before this change all processes shared kimi.log, so retention="10 days" (configured at src/kimi_cli/app.py:74) cleaned all rotated logs. Now every distinct PID leaves behind its own files that no process will ever purge. The export path (src/kimi_cli/cli/export.py:130-168) only reads logs for bundling; it does not delete them, so there is no other mechanism bounding disk usage.

Prompt for agents

On Windows, get_log_file_path() in src/kimi_cli/utils/logging.py returns a per-PID filename (kimi.<pid>.log). Loguru's retention="10 days" (set in enable_logging in src/kimi_cli/app.py) only cleans files whose names match the current sink's filename stem, so it will never remove kimi.<pid>.log files left behind by other/previous processes. This means the logs directory grows unbounded on Windows. Consider adding an explicit cleanup pass that removes old kimi.*.log files across all PIDs (e.g. deleting files older than the retention window when logging is initialized), or otherwise ensure stale per-process log files are eventually purged.

---

Was this helpful? React with 👍 or 👎 to provide feedback.