fix: detect npm kimi process

[akbash-bot]

Issue

Starting Kimi with the plain kimi command in Windows PowerShell leaves its pane undetected. Kimi only appears when it is launched through kimi.cmd.

Problem

The PowerShell npm shim starts Kimi as node.exe with Kimi's package entry point. Herdr did not recognize that entry point, so it never associated the installed lifecycle reports with Kimi.

How did we fix it?

Herdr now recognizes the exact @moonshot-ai/kimi-code/dist/main.mjs package entry point as Kimi. The match is case-insensitive but rejects package lookalikes, helper scripts, and trailing path components. Existing process selection and lifecycle behavior are unchanged.

Verification

The exact reported Node command returned no agent before the change and returns Kimi afterward. Focused tests cover the reported path and near misses, and all 58 detector tests plus formatting and clippy pass. All PR checks pass on Linux, macOS, and Windows. Local CI passed 3,535 tests; one live-handoff test could not inspect the issue-isolated target path even though its replacement server started successfully.

refs #3317

[coderabbitai]

No actionable comments were generated in the recent review. 🎉

ℹ️ Recent review info

⚙️ Run configuration

Configuration used: Organization UI

Review profile: CHILL

Plan: Pro Plus

Run ID: a6709989-8ae4-4f33-b493-fcb7afcfcc38

📥 Commits

Reviewing files that changed from the base of the PR and between 7b675f4 and 408987e.

📒 Files selected for processing (1)

• src/detect/mod.rs

Included review availability: Your plan provides up to 10 included reviews per hour; 9 remain after this review.

---

📝 Walkthrough

Walkthrough

The detector now identifies node-wrapped Kimi processes by matching the trailing node_modules/@moonshot-ai/kimi-code/dist/main.mjs path. Tests cover Windows paths and near-miss scripts.

Changes

Kimi detection

Layer / File(s)	Summary
Kimi entrypoint matching and validation src/detect/mod.rs	agent_name_from_known_package_path matches the Kimi entrypoint case-insensitively before existing package checks. Tests cover node-wrapped Windows detection and rejected near-miss paths.

Estimated code review effort: 2 (Simple) | ~10 minutes

Merge Risk: ⚪ Minimal · up to 40898

The change narrowly improves Kimi detection for the Windows PowerShell npm entry point without altering process selection or lifecycle behavior. No actionable merge-blocking risk remains beyond normal checks and review.

🚥 Pre-merge checks | ✅ 4 | ❌ 1

❌ Failed checks (1 warning)

Check name	Status	Explanation	Resolution
Docstring Coverage	⚠️ Warning	Docstring coverage is 66.67% which is insufficient. The required threshold is 80.00%. Docstring coverage is scoped to functions touched by this diff. Analyzed 6 functions across 1 files.	Write docstrings for the functions missing them to satisfy the coverage threshold.

✅ Passed checks (4 passed)

Check name	Status	Explanation
Linked Issues check	✅ Passed	Check skipped because no linked issues were found for this pull request.
Out of Scope Changes check	✅ Passed	Check skipped because no linked issues were found for this pull request.
Title check	✅ Passed	The title clearly and concisely describes the main change: fixing detection of Kimi processes launched through npm.
Description check	✅ Passed	The description directly explains the Kimi detection issue, the exact entry-point matching fix, and the verification performed.

• Fix all pre-merge checks with AI

✨ Finishing Touches

🧪 Generate unit tests (beta)

• Create PR with unit tests

---

Thanks for using CodeRabbit! It's free for OSS, and your support helps us grow. If you like it, consider giving us a shout-out.

❤️ Share

• X
• Mastodon
• Reddit
• LinkedIn

_{Comment @coderabbitai help to get the list of available commands.}

[ogulcancelik]

@akbash-bot why do we need to add exact kimi paths? how do we solve this for other agents? this feels weird

[akbash-bot]

PowerShell exposes this launch as generic node.exe, so the argv script is the only process-identity signal Herdr receives. The exact match avoids treating unrelated Node programs as Kimi. This follows existing special cases for Pi, Qwen, MastraCode, and Cursor; it is not a scalable Kimi-specific design.

I agree the current shape is awkward. The general fix is a table-driven process-signature registry per canonical agent: executable aliases plus exact generic-runtime argv/package signatures. Platform code would only collect name/argv, and the shared detector would evaluate that registry for every agent. I would not put process identity in remotely updated screen manifests because identity gates lifecycle authority. Hooks also cannot bootstrap this today because known-agent reports require existing process ownership. This PR is the smallest restoration; replacing the existing special cases with a registry would be a broader refactor.