fix(vscode): route permission replies through request directories

[kirillk]

Issue

Fixes #11132.

Symptoms

• Continuing or resuming a VS Code extension session can get stuck when a command permission prompt is answered.
• Logs show repeated failures like KiloProvider: Failed to respond to permission: Error: Permission request not found: per_....
• The failure is most visible around continued, forked, or auto-adopted Agent Manager worktree sessions, including when auto-approve is enabled.

Why This Happens

Permission requests are stored by the CLI backend in directory-scoped InstanceState. The permission reply endpoint routes only by requestID and directory, not by session ID. If the extension replies with the correct permission ID but falls back to the workspace root or another stale directory, the backend looks in the wrong pending-permission map and returns Permission request not found.

The backend already includes the authoritative instance directory on permission.asked SSE events. The bug was that VS Code stored that request-directory mapping inside individual KiloProvider instances. Provider filtering, webview recreation, Agent Manager registration races, or global auto-approve handling could miss that provider-local state and reply from the wrong directory.

Fix

• Store permission request directories centrally in KiloConnectionService before SSE events are filtered to individual providers.
• Route manual permission replies through that shared request-directory map.
• Make auto-approve use the SSE directory first, then the shared request-directory map, then the existing session/root fallback.
• Include Agent Manager worktree directories when recovering pending permission prompts so missed permission.asked events are found in the correct backend instance.

Why This Approach

KiloConnectionService owns the single shared CLI backend connection used by the sidebar, editor tabs, and Agent Manager, so it is the one place that sees all SSE events before provider-specific filtering. Keeping the request-directory map there makes permission replies independent of which provider saw the original event or which provider later handles the response. It also keeps the fix entirely in the VS Code extension without changing the CLI, SDK, or backend permission API.

Validation

• bun test tests/unit/permission-recovery.test.ts tests/unit/auto-approve.test.ts
• bun run typecheck
• bun run lint (passes with existing eqeqeq warning in src/kilo-provider-utils.ts:721)
• Push hook ran bun turbo typecheck successfully.

[kilo-code-bot]

Code Review Summary

Status: No Issues Found | Recommendation: Merge

Files Reviewed (9 files)

• .changeset/route-shared-permissions.md — changeset added (previously flagged missing; now resolved ✅)
• packages/kilo-vscode/src/KiloProvider.ts — no issues
• packages/kilo-vscode/src/commands/toggle-auto-approve.ts — no issues
• packages/kilo-vscode/src/kilo-provider/handlers/permission-handler.ts — no issues
• packages/kilo-vscode/src/services/cli-backend/connection-service.ts — no issues
• packages/kilo-vscode/tests/unit/auto-approve.test.ts — no issues
• packages/kilo-vscode/tests/unit/permission-recovery.test.ts — no issues

Incremental review notes

New commits since last review (78c06b4):

• Changeset added (.changeset/route-shared-permissions.md) — resolves the previous suggestion. Description is user-facing and accurate.
• Error handling in fetchAndSendPendingPermissions — the valid set correctly records only directories whose permission.list call succeeded. Passing valid (not new Set(dirs)) to prunePermissionDirectories means cached routes for directories that fail the list call are preserved rather than evicted, preventing broken in-flight permission replies under transient errors. The logic in prunePermissionDirectories (skip entries whose directory is not in the queried set) confirms this is semantically correct.
• Regression test — the new test in permission-recovery.test.ts correctly seeds stale and in-use entries, induces a list error for one directory, and asserts that the stale workspace entry is pruned while the failing-directory entry is preserved.

---

_{Reviewed by claude-4.6-sonnet-20260217 · 247,001 tokens}

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

[marius-kilocode]

This also follows up #9283 and fixes #11132. #9450 addressed the stale prompt case from #9283, but kept the permission request-to-directory mapping inside each provider. #10787 captured the directory earlier, but retained that provider-local lifecycle gap. Centralizing the mapping in the shared connection service here covers both the original multi-panel hang and the current continued/Agent Manager session failure.

[marius-kilocode]

Follow-up pushed in b0d643c. Pending-permission recovery now distinguishes a successful empty list from a failed directory query. If one worktree temporarily fails to list permissions, we keep its cached request-to-directory routes instead of pruning them and risking the same wrong-instance reply failure. Successfully queried directories are still pruned normally. The commit also adds regression coverage for that partial-failure case and the missing patch changeset.

[marius-kilocode]

Tested this, fixes now all cases. Thanks @kirillk I will merge it