Bug: optional browser MCP status failure aborts prompt submission #15086

Component

VS Code extension

Description

When kilo-code.new.browserAutomation.enabled is enabled, a transient failure of the local MCP-status endpoint can prevent an otherwise ordinary prompt from being sent. The optional readiness check fails hard on HTTP errors even though it already allows prompt submission after a timeout.

Observed error, with the workspace path replaced by a neutral example:

Failed to send prompt
kilo server GET http://127.0.0.1:4096/mcp?directory=%2Fworkspace%2Fproject
  -> 503 Service Unavailable: (empty response body)

Expected: retry the idempotent local status read within the existing readiness deadline, then continue without waiting for optional browser automation if a recoverable transport failure persists. Explicit user cancellation must still stop preparation without sending a later prompt. Genuine MCP startup failures and programming errors should remain visible.

Actual: BrowserAutomationService.ready() rejects when mcp.status(..., { throwOnError: true }) receives the HTTP failure. It escapes KiloConnectionService.prepareTools() into the send handler, which reports sendMessageFailed before session.promptAsync(). A hung request instead reaches the existing graceful timeout path.

Confirmed failure path:

Send handler
  -> prepareTools()
  -> BrowserAutomationService.ready()/bounded()
  -> local GET /mcp rejects
  -> sendMessageFailed; promptAsync is never called

The original intermittent empty-503 producer is not identified. Later authenticated reads of /global/health and /mcp returned 200. The error is from Kilo's local controller, and MCP.status() reads in-memory state; this does not establish an outage of a configured remote MCP gateway.

Plugins

A managed MCP/LLM-routing plugin was configured in the affected environment. The controlled reproduction below uses no routing plugin, external MCP gateway, real vendor credentials, or inference call.

Kilo version

7.8.8 (v7.8.8); failure path also present on the main revision used by PR #15079.

Steps to reproduce

1. Use the VS Code extension in a trusted workspace with browser automation enabled and a connected local CLI backend.
2. Return an empty HTTP 503 from the local status GET while submitting a prompt. This can be simulated with a loopback HTTP fixture behind the real createKiloClient SDK.
3. Observe readiness rejecting and prompt preparation failing. No prompt API call is reached.
4. Compare with a status GET that hangs until the readiness timeout: prompt preparation is allowed to continue.

PR #15079 includes an executable real-HTTP regression fixture. From packages/kilo-vscode on that branch:

bun test tests/unit/browser-automation-readiness-http.test.ts tests/unit/browser-automation-lifecycle.test.ts

The fixture covers persistent empty 503, recovery, network errors, deadlines, cancellation, and late rejections without requiring the historical server-side trigger to recur.

Screenshot and/or share link

Sanitized error text and failure path are included above. No session transcript or screenshot containing unrelated workspace details is attached.

Proposed fix: #15079

Operating System

Ubuntu 24.04.5 LTS, Linux x64; remote VS Code extension host. Native Windows and macOS were not reproduced.

Terminal

Not applicable: prompt submission from the editor UI.