feat(kilo-vscode): support promoted model deep links

[lambertjosh]

Summary

The VS Code extension URI handler cannot currently select a specific model. This makes links for free-model launches, new-model announcements, and promotions unnecessarily cumbersome because users must open VS Code, open the model picker, and locate the model manually.

This PR adds support for vscode://kilocode.kilo-code/kilocode/model?model=<modelID> links. The extension opens and focuses the Kilo sidebar, refreshes the Kilo Gateway model catalog, and applies the linked model only when it is present in that refreshed catalog.

The linked model uses the same selection path as the model picker: it applies as an override to the active session when one exists, updates model recents, and otherwise becomes the selected model for the active agent's next task. It does not change the user's configured default model setting.

Details

• activate the VS Code extension for vscode://kilocode.kilo-code/kilocode/model?... links and accept model IDs present in the refreshed Kilo Gateway catalog
• queue linked model selection until the sidebar, CLI client, provider catalog, and agent metadata are ready
• reuse the existing model-selection behavior rather than maintaining a separate deep-link persistence path

Validation

• Validated with a valid model, both when VS Code is open and not open
• Validated that an invalid or unavailable model is ignored
• Validated normal model switching after using a deep link
• bun run --cwd packages/kilo-vscode typecheck
• targeted ESLint and Prettier checks for changed VS Code extension files
• bun run --cwd packages/kilo-vscode test:unit (2589 passing tests)
• pre-push bun turbo typecheck

Rollout

• Release this extension support before deploying the companion landing banner so existing users can select the promoted model directly from any new CTA.

[kilo-code-bot]

Code Review Summary

Status: 2 Issues Found | Recommendation: Address before merge

Overview

Severity	Count
CRITICAL	0
WARNING	2
SUGGESTION	0

Changes Since Previous Review

revision field removed from model selection protocol: RequestModelSelectionsMessage.revision, ModelSelectionsLoadedMessage.revision, and the revision mismatch/retry logic in session.tsx are all removed. The requestModelSelections handler no longer awaits the write queue before responding, and modelSelectionsLoaded no longer carries a revision. This simplifies the protocol significantly.

write() callback refactored to accept a plain value: The previous (value: unknown) => unknown updater callback form has been replaced with a direct value: unknown parameter. This means callers now must read() separately before calling write() — see Warning below.

model-state.test.ts deleted: The concurrent-write test that verified serialization is now removed alongside the refactored code.

applyPersistedModel removed from session.tsx: Deep link model selection now goes through selectModel directly instead of a separate persistence path. Cleaner.

Active Issues (not in PR diff — summary only)

WARNING: Race condition reintroduced in model-state.ts

The incremental commit (14d0cc2b) refactors persistModelSelection and clearModelSelection in packages/kilo-vscode/src/kilo-provider/model-state.ts to read outside the write queue:

// NEW (racy)
const data = await read(client)       // outside queue
const model = validateModelSelections(data.model)
model[message.agent as string] = { ... }
await write(client, "model", model)   // chains onto queue

The old code did both read and write inside the same queue.then() callback, making concurrent writes atomic. With the new code, two concurrent persistModelSelection calls can both read the same stale state, independently modify it, and the second write overwrites the first's change — exactly the scenario the now-deleted model-state.test.ts was testing.

The fix is to move the read() back inside the write() queue, or re-introduce the updater callback pattern. Example:

if (type === "persistModelSelection") {
  const op = queue.then(async () => {
    const data = await read(client)
    const model = validateModelSelections(data.model)
    model[message.agent as string] = { providerID: ..., modelID: ... }
    const p = await resolve(client)
    if (!p) return
    await fs.promises.writeFile(p, JSON.stringify({ ...data, model }, null, 2))
  })
  queue = op.catch(() => {})
  await op
  return true
}

The model-state.test.ts concurrent-write test should be restored alongside the fix.

File	Line	Issue
packages/kilo-vscode/src/kilo-provider/model-state.ts	67–82	WARNING: read() called outside write queue — concurrent persistModelSelection/clearModelSelection can lose writes
packages/kilo-vscode/tests/unit/model-state.test.ts	—	WARNING: Concurrent-write regression test deleted; should be restored

Carried Forward: Active Inline Comments

File	Line	Issue
packages/kilo-vscode/src/KiloProvider.ts	3205	WARNING: !this.client guard in flushPendingKiloModel means deep links arriving before the client is ready are queued, but the flush at "connected" state change should recover them. Confirm this is intentional and not silently dropping links if the connection never reaches "connected".

Other Observations (not in diff)

File	Line	Issue
packages/kilo-vscode/webview-ui/src/context/provider-utils.ts	44	The isModelValid function uses a hardcoded "kilo" string instead of KILO_PROVIDER_ID. Low risk (same value) but inconsistent with the rest of the codebase.

Files Reviewed (incremental: 4 changed files + 1 deleted)

• packages/kilo-vscode/src/kilo-provider/model-state.ts — WARNING: race condition (read outside queue)
• packages/kilo-vscode/tests/unit/model-state.test.ts — deleted (concurrent-write test removed)
• packages/kilo-vscode/webview-ui/src/context/session.tsx — revision tracking removed, applyPersistedModel removed; clean
• packages/kilo-vscode/webview-ui/src/types/messages/extension-messages.ts — revision field removed; clean
• packages/kilo-vscode/webview-ui/src/types/messages/webview-messages.ts — revision field removed; clean

Fix these issues in Kilo Cloud

---

_{Reviewed by claude-4.6-sonnet-20260217 · 1,100,418 tokens}

_{Review guidance: REVIEW.md from base branch main}

[lambertjosh]

[lambertjosh]

Also validated:

• That entering an invalid model does nothing
• Running it with VSCode open switches active session to the right model
• Running it with VSCode closed opens VSCode then switches and validates.

It does not affect agent manager sessions but I think that is OK, especially for initial release.

[lambertjosh]

Demo:

demo.mov