fix(vscode): fix hanging sessions for permissions bug

[alex-alecu]

Why

Fixes #9283

Sometimes a permission pop-up stayed on screen after it was already answered somewhere else. That left broken buttons behind and could also make settings save fail for no good reason.

What changed

Permission replies now go back to the workspace that asked for them, even if the session came from another panel or worktree. If the app learns that a prompt was already handled, it clears the old prompt instead of leaving a dead button on screen. The server now says when a permission is gone, and the client uses that to refresh cleanly. This also keeps the same stale case from breaking settings saves and makes the behavior match in both permission paths.

How to test

1. Open the same repo in two VS Code windows or worktrees and trigger a permission prompt.
2. Answer it in one place, then try the old copy in the other place.
3. Confirm the old prompt disappears instead of hanging or leaving dead buttons.
4. Change a setting after that and confirm the save still works.

[kilo-code-bot]

Code Review Summary

Status: No Issues Found | Recommendation: Merge

Files Reviewed (14 files)

• packages/kilo-vscode/src/KiloProvider.ts
• packages/kilo-vscode/src/kilo-provider-utils.ts
• packages/kilo-vscode/src/kilo-provider/handlers/permission-handler.ts
• packages/kilo-vscode/src/services/cli-backend/connection-service.ts
• packages/kilo-vscode/tests/unit/permission-recovery.test.ts
• packages/kilo-vscode/webview-ui/src/context/session.tsx
• packages/kilo-vscode/webview-ui/src/types/messages/extension-messages.ts
• packages/opencode/src/permission/index.ts
• packages/opencode/src/server/routes/instance/httpapi/permission.ts
• packages/opencode/src/server/routes/instance/permission.ts
• packages/opencode/test/kilocode/permission/next.always-rules.test.ts
• packages/opencode/test/kilocode/permission/next.reply-http.test.ts
• packages/opencode/test/kilocode/permission/next.reply-routing.test.ts
• packages/opencode/test/permission/next.test.ts

---

_{Reviewed by gpt-5.5-2026-04-23 · 4,642,416 tokens}

[alex-alecu]

Additional manual test passed with gpt-4o-mini.

Tested:

• Ran the local worktree backend with openrouter/openai/gpt-4o-mini and a real OpenRouter request.
• Prompted the model to use the bash tool so the backend produced a real permission prompt.
• Sent a permission reply to the wrong workspace directory, then replied through the owning workspace directory.
• Replied to the already-answered permission and saved always-rules for the already-answered permission.
• Updated global config after the stale permission paths.

Verified:

• Misrouted permission reply returned 404 and the owning workspace permission stayed pending.
• Correct permission reply returned 200, cleared the pending prompt, and the real-model tool call completed.
• Stale reply and always-rules requests returned 404.
• SSE permission.asked and permission.replied events included the source workspace directory.
• SQLite persisted the session and completed tool part, and the config file persisted the later settings update.

[alex-alecu]

Manual test passed.

Tested:

• Started the local branch backend with bun dev serve and drove it over HTTP/SSE using a real OpenRouter model to trigger bash permission prompts.
• Verified a wrong-directory permission reply returns 404 and leaves the original directory's pending permission intact.
• Verified the correct-directory reply succeeds, clears the pending permission, and a second/stale reply returns 404.
• Verified always-rules succeeds for a live prompt, persists an allow rule, and returns 404 after the permission is already answered.
• Verified a settings-drain-style reject clears a live prompt, and a stale follow-up reject returns 404.

Verified:

• Global SSE permission events include the owning directory envelope for both permission.asked and permission.replied.
• Pending permission state is isolated per directory and clears after accepted replies/rejects.
• Persisted config contains the saved bash allow rule from always-rules.