fix: queue concurrent permission requests to prevent silent cancellations

[robertpyke]

I threw together a quick PR after hitting issues with multiple concurrent tool calls breaking the permission prompting. No issue if you throw this out, and do your own thing, but this seems to have fixed the bug for me locally, so I turned it into a PR. More detail below.

Problem

When multiple permission requests arrive simultaneously (e.g. parallel file reads + terminal command), each showQuickPick call dismisses the previous one, causing it to silently return undefined (treated as cancelled). The agent sees the tool call as rejected and re-asks on the next prompt, creating a loop where the user keeps approving but nothing executes.

Fix

Added a serial promise queue to PermissionHandler so concurrent requestPermission calls are processed one at a time. Each QuickPick waits for the previous one to resolve before showing.

Changes

• src/handlers/PermissionHandler.ts — Added queue field, extracted logic into private handlePermission
• CHANGELOG.md — Added 0.1.3 entry
• package.json — Version bump to 0.1.3

[Copilot]

Pull request overview

This PR addresses a VS Code UI race where concurrent permission prompts can dismiss each other, causing silent cancellations and repeated permission loops. It does so by serializing permission requests so only one QuickPick is shown at a time.

Changes:

• Queue concurrent requestPermission calls in PermissionHandler and move the prompt logic into a private helper.
• Bump extension version to 0.1.3.
• Add a 0.1.3 changelog entry documenting the fix.

Reviewed changes

Copilot reviewed 3 out of 3 changed files in this pull request and generated 3 comments.

File	Description
src/handlers/PermissionHandler.ts	Serializes permission prompts to prevent overlapping QuickPick dialogs.
package.json	Bumps extension version to 0.1.3.
CHANGELOG.md	Documents the 0.1.3 fix for concurrent permission prompt clobbering.

---

💡 Add Copilot custom instructions for smarter, more guided reviews. Learn how to get started.

[Copilot]

The extension version was bumped here, but package-lock.json still has the root version set to 0.1.2. If this repo commits the lockfile, it should be updated to keep the metadata consistent (otherwise tooling that inspects the lockfile can report the old version).

[robertpyke]

@copilot open a new pull request to apply changes based on this feedback

[robertpyke]

@copilot open a new pull request to apply changes based on the comments in this thread

[Copilot]

Pull request overview

Copilot reviewed 3 out of 3 changed files in this pull request and generated 1 comment.

---

💡 Add Copilot custom instructions for smarter, more guided reviews. Learn how to get started.

[Copilot]

requestPermission converts any thrown error from handlePermission into a { outcome: 'cancelled' } response without logging or emitting a corresponding permission/responded telemetry event. This can mask real failures (e.g., showQuickPick/telemetry errors) as user cancellations and makes troubleshooting/metrics inaccurate. Consider logging the error (e.g., via logError) and reporting it via sendError/sendException, and decide whether to rethrow or return a distinct failure outcome rather than treating it as a user cancel.

Suggested change

	const result = this.queue.then(() => this.handlePermission(params));
	this.queue = result.then(
	() => undefined,
	() => undefined,
	);
	return result.catch(() => ({ outcome: { outcome: 'cancelled' as const } }));
	const title = params.toolCall?.title || 'Permission Request';
	const result = this.queue.then(() => this.handlePermission(params));
	this.queue = result.then(
	() => undefined,
	() => undefined,
	);
	return result.catch(error => {
	const message =
	error instanceof Error
	? `${error.name}: ${error.message}`
	: `Unknown error: ${String(error)}`;
	log(`requestPermission failed for "${title}": ${message}`);
	sendEvent('permission/responded', {
	permissionType: title,
	outcome: 'error',
	});
	throw error;
	});