Windows: WebBridge may fail after reboot due to stale daemon.pid / BOM in Startup VBS

What version of Kimi Code is running?

Kimi WebBridge daemon v1.10.1; Chrome extension v1.10.0. This is a WebBridge issue, so kimi --version is not applicable.

Which open platform/subscription were you using?

N/A - Kimi WebBridge local browser extension/daemon on Windows.

Which model were you using?

N/A - issue occurs before model selection; browser assistant/daemon is not ready.

What platform is your computer?

Microsoft Windows NT 10.0.26200.0 x64

What issue are you seeing?

Kimi WebBridge can show "Browser assistant is not ready" after a Windows reboot even when the installation is correct.

I traced two Windows-specific startup failure modes:

1. A stale %USERPROFILE%\.kimi-webbridge\daemon.pid can remain after reboot/crash. The daemon may fail with:

write pid: open C:\Users\<user>\.kimi-webbridge\daemon.pid: The file exists

2. A Startup-folder KimiWebBridge.vbs saved with a UTF-8 byte order mark can fail in Windows Script Host with:

Line: 1
Char: 1
Error: Invalid character
Code: 800A0408
Source: Microsoft VBScript compilation error

In both cases, the Chrome extension cannot connect to 127.0.0.1:10086, so the browser assistant remains unavailable.

What steps can reproduce the bug?

1. Install Kimi WebBridge on Windows with the Chrome extension.
2. Ensure the local daemon has previously created %USERPROFILE%\.kimi-webbridge\daemon.pid.
3. Reboot Windows, or simulate a stale PID by leaving daemon.pid pointing to a non-running PID.
4. Start Chrome and open the Kimi WebBridge extension popup.
5. Observe that the extension may show "Browser assistant is not ready".
6. Check daemon status/logs. The daemon may not be listening on 127.0.0.1:10086, or startup may fail because daemon.pid already exists.
7. If the Startup VBS contains a UTF-8 BOM, Windows Script Host fails before the daemon can start, with 800A0408 Invalid character at line 1 char 1.

Useful checks:

& "$env:USERPROFILE\.kimi-webbridge\bin\kimi-webbridge.exe" status
curl.exe -s http://127.0.0.1:10086/status
Get-NetTCPConnection -LocalPort 10086 -ErrorAction SilentlyContinue
Format-Hex "$([Environment]::GetFolderPath('Startup'))\KimiWebBridge.vbs" -Count 16

What is the expected behavior?

After Windows login/reboot, WebBridge should recover stale PID state and start the local daemon reliably.

Expected behavior:

• http://127.0.0.1:10086/status reports running: true.
• The Chrome extension reconnects to the daemon.
• The extension popup does not stay on "Browser assistant is not ready" when installation is otherwise valid.
• Generated startup scripts should be ASCII or UTF-8 without BOM so Windows Script Host can parse them.

Additional information

Suggested fixes:

• Detect and remove stale PID files when the PID is not running.
• Ensure generated .vbs startup scripts are ASCII or UTF-8 without BOM.
• After startup, verify http://127.0.0.1:10086/status instead of assuming that process launch means the daemon is ready.

I packaged an unofficial Windows workaround here for reference:
https://github.com/pratikforge/kimi-webbridge-windows-autostart-fix

I am not including personal logs, identity files, or Chrome profile data in this report.

Start by reproducing the Windows startup failure with the daemon.pid path, the Startup-folder KimiWebBridge.vbs script, and the kimi-webbridge.exe status command. Check http://127.0.0.1:10086/status and the provided PowerShell diagnostics while testing stale PID handling, script encoding, and daemon readiness. Done means the daemon starts after reboot, the status endpoint reports running: true, and the extension reconnects.