fix(cli): hide Windows console windows from kimi web and file opens#1913
fix(cli): hide Windows console windows from kimi web and file opens#1913liujunGH wants to merge 2 commits into
kimi web and file opens#1913Conversation
`openUrl` (used by `kimi web`, `kimi vis`, the login flow) and kap-server's `launchDetached` / win32 `where` probe spawned processes without `windowsHide`, so Windows allocated a visible console window — flashing a cmd.exe window when opening the browser and pinning one for detached children. Same class as MoonshotAI#957 / MoonshotAI#1336 / MoonshotAI#1466; same one-option fix, kept unconditional (ignored off Windows, matching kaos).
🦋 Changeset detectedLatest commit: 2220852 The changes in this PR will be included in the next version bump. This PR includes changesets to release 1 package
Not sure what this means? Click here to learn what changesets are. Click here if you're a maintainer who wants to add another changeset to this PR |
![chatgpt-codex-connector[bot]](https://avatars.githubusercontent.com/in/1144995?s=60&v=4){kind=small}
There was a problem hiding this comment.
💡 Codex Review
Here are some automated review suggestions for this pull request.
Reviewed commit: ebdbc92eda
ℹ️ About Codex in GitHub
Your team has set up Codex to review pull requests in this repo. Reviews are triggered when you
- Open a pull request for review
- Mark a draft as ready
- Comment "@codex review".
If Codex has suggestions, it will comment; otherwise it will react with 👍.
Codex can also answer questions or update the PR. Try commenting "@codex address that feedback".
| // On Windows a detached child gets its own console window; hide it so | ||
| // "open file" from the web UI does not flash a console (see also the | ||
| // background updater's identical guard in cli/update/preflight.ts). | ||
| windowsHide: true, |
There was a problem hiding this comment.
For Windows users invoking the web UI's Reveal action, handleReveal routes through revealFileCommandFor, which launches explorer.exe /select,... directly rather than through cmd; applying this option to every detached launch can hide the Explorer window itself. I checked Node v24/libuv's Windows spawn path (source), where UV_PROCESS_WINDOWS_HIDE uses SW_HIDE to avoid any process window, so please restrict windowsHide to console/shell commands instead of GUI openers.
Useful? React with 👍 / 👎.
Codex review: `windowsHide` maps to SW_HIDE, which would also hide the FIRST window of GUI children — e.g. explorer.exe launched by the web UI's reveal action. Apply it only when the direct child is console-subsystem (a shell shim or cmd.exe itself); GUI targets stay visible.
|
Codex P2 addressed in 2220852: |
1 participant
Problem
On Windows,
kimi webmakes Windows allocate a visible console window when it opens the browser:openUrlshells out tocmd /c startviaexecFilewith no options, and Node'swindowsHidedefaults tofalse. From a console-less parent the transientcmd.exegets its own console window; users see a shell window flash every time the Web UI opens.Two more sites in the same flow have the same issue:
kap-server'slaunchDetached(web UI "open file / reveal / open in editor" actions) spawns withdetached: trueand nowindowsHide— a detached child gets its own console window on Windows (see the identical comment incli/update/preflight.ts).commandExists's win32whereprobe (spawnSync('cmd', ...)) flashes a console when the open-in-app menu is built.Fix
Pass
windowsHide: trueat all three sites, unconditional (ignored off Windows — same convention askaos). Same class of bug and same one-option fix as the already-merged #957 (spawned commands), #1336 (background updater), and #1466 (hooks).Tests
apps/kimi-code/test/utils/open-url.test.ts: assertsexecFilereceiveswindowsHide: trueand the per-platform opener command.packages/kap-server/test/fileLaunch.test.ts: assertslaunchDetachedand the win32whereprobe passwindowsHide: true.kap-server/test/files.test.ts(7),test/tui/commands/web.test.ts(14);tsc --noEmitclean in both packages.Note: verified on macOS only (no Windows machine at hand); the option is a no-op elsewhere, and the behavior matches the three merged precedent fixes.