[Proposed API] chat.agent.onPermissionRequest - enable programmatic resolution of agent mode permission requests

[ravisha22]

Problem

VS Code's Copilot Agent Mode requires interactive permission approval for tool calls (file edits, terminal commands, MCP tools). These approvals can only be resolved through the VS Code UI — clicking "Allow" / "Deny" in the editor window.

This creates a productivity gap: when the agent is working on a multi-step task, the developer must remain at the keyboard watching for permission dialogs. There is no way to:

1. Observe agent activity from outside the VS Code window
2. Approve/deny permission requests programmatically (e.g., from another device)
3. Build extension-based workflows around agent mode events (audit logging, custom approval policies, remote supervision)

Proposed API

A new proposed extension API surface that exposes agent mode permission events to extensions:

// vscode.proposed.chatAgentPermissions.d.ts

declare module 'vscode' {
  export namespace chat {
    /**
     * Fired when the agent requests permission to use a tool.
     * Extensions can observe this for logging, or resolve it
     * to provide programmatic approval/denial.
     */
    export const onDidRequestToolPermission: Event<ChatToolPermissionRequest>;

    /**
     * Read-only list of currently pending permission requests.
     */
    export const pendingToolPermissions: readonly ChatToolPermissionRequest[];
  }

  export interface ChatToolPermissionRequest {
    /** Unique request ID */
    readonly id: string;
    /** The tool being requested */
    readonly toolName: string;
    /** Permission kind */
    readonly kind: 'file-edit' | 'file-create' | 'file-delete' | 'terminal' | 'mcp-tool';
    /** Human-readable description of what the tool will do */
    readonly description: string;
    /** Detailed context (file path, command, diff preview) */
    readonly details: Record<string, unknown>;
    /** Timestamp when the request was created */
    readonly timestamp: number;
    /** Resolve the permission request programmatically */
    resolve(approved: boolean): void;
  }
}

Use Cases

1. Remote supervision: An extension bridges permission requests to a mobile device (phone/tablet) via WebSocket, letting developers approve agent operations while away from the keyboard
2. Custom approval policies: Extensions implement org-specific rules (e.g., auto-approve test file edits, always deny production config changes)
3. Audit logging: Extensions log all tool calls and permission decisions for compliance
4. Team workflows: Permission requests routed to a senior developer for review

Why This Belongs in VS Code Core

• chat.tools.autoApprove already allows bypassing the UI entirely — programmatic resolution is philosophically consistent
• The Chat Participants API (vscode.chat.createChatParticipant) already exposes chat events to extensions — permission events are a natural extension of this pattern
• Without this API, extensions must resort to fragile workarounds (accessibility tree manipulation, UI automation) that break across versions

Relationship to Existing APIs

Existing API	Relationship
chat.tools.autoApprove setting	This API is the programmatic equivalent — extensions make the approve/deny decision instead of a static setting
ChatParticipant API	Same pattern — exposing chat subsystem events to extensions
window.showInformationMessage with actions	Permissions are currently UI-only dialogs; this adds a programmatic channel

Backward Compatibility

• No breaking changes — the existing UI permission flow continues to work as-is
• Extensions that register a listener get a parallel notification; the UI dialog can still be used
• If an extension resolves a permission before the user clicks the dialog, the dialog is dismissed
• If the user clicks the dialog before any extension resolves it, the extension's resolve becomes a no-op

Motivation: Agentic Coding is Async, Permission Approval Shouldn't Require Presence

As Agent Mode becomes the primary Copilot workflow, developers increasingly kick off multi-step tasks and step away. The current model forces synchronous human presence for every permission gate. This API would let the ecosystem build remote supervision tools (mobile apps, push notifications, Teams bots) that keep the human in the loop without requiring them at the keyboard.

[timteh]

While this API would be the clean long-term solution, there is an extension that already solves the immediate pain point today using the approach you called out as "fragile" -- except it does it in a way that isn't fragile.

Antigravity Autopilot -- OS Level auto-clicks Accept/Run/Continue/Allow buttons using Windows UI Automation (InvokePattern.Invoke()), not CDP. It reads button names from the OS accessibility tree -- the same API screen readers use -- so it works even when Electron disables remote debugging ports, which is exactly what makes CDP-based approaches break.

Disclosure: I built it.

The key difference from the "fragile workarounds" mentioned in the issue: UI Automation at the OS layer doesn't touch the DOM or rely on DevTools Protocol. It survives IDE updates, corporate port blocks, and Electron build flag changes. Delete/Cancel/Discard are never auto-clicked by default, and accept/reject patterns are fully configurable via regex.

Works across VS Code, Cursor, Windsurf, and Antigravity. Windows only for now (macOS/Linux planned).

GitHub: https://github.com/timteh/antigravity-autopilot

This doesn't replace the proposed API -- programmatic resolution with custom policies would be much more powerful -- but it fills the gap today.

[ravisha22]

Given how elaborate agentic coding has become and the number of devs in just my cohort carrying laptop around just to allow/decline actions, acknowledge something etc., needs builtin solution from VSC. I did look a bunch of options, but they are either paid solutions or felt hacky.

[m13v]

hit this exact pain supervising Cursor and VS Code agent loops from a macOS automation layer. the "fragile workaround" framing undersells what AX actually gives you. AXUIElement + AXPress on Electron buttons survives version bumps because the accessibility tree is a stable contract, the DOM underneath is not. what actually breaks things: focus stealing on AXRaise, stale AXChildren snapshots after React re-renders, and dialogs that mount in a detached AXWindow so a plain descendant walk misses them. fix is to subscribe to AXCreated notifications on the app PID and match on AXTitle+AXDescription rather than index paths. zero DOM, zero CDP, no disabled remote-debug flag can kill it. a real API would still be nicer for audit trails but this is not the flaky layer people think it is.