microsoft / microsoft/vscode

Feature Request: Expose settings.json configuration for integrated browser proxy

Open
#332,493 2 comments 0 reactions 2 assignees Claimed by @kycutler View on GitHub
browser-integration feature-request
Dominant language
TypeScript
Stars
193k
Forks
42.4k
PR merge metrics
PR metrics pending

Description

### Problem
VS Code integrated browser does not respect VS Code proxy settings.

The `http.proxy` / `http.noProxy` in settings.json only applies to VS Code itself, extensions and marketplace traffic. They have zero effect for the built‑in integrated browser.
Currently the integrated browser can only use OS‑level system proxy, with no dedicated proxy configuration inside VS Code.

This creates painful workflow gaps for frontend developers.

#### Real‑world critical use‑case 1: Local development with Whistle
Many frontend developers rely on whistle, a local HTTP debugging proxy, for daily work:
‑ Intercept requests
‑ Mock or rewrite API responses
‑ Map production hostnames to local backend services
‑ Modify request headers and capture HTTPS traffic.

When previewing application inside VS Code integrated browser, none of these whistle rules take effect. There is no way to configure the browser to use whistle from within VS Code settings.

Turning on global system‑wide proxy is not acceptable: it routes all other system applications through the proxy and disrupts normal daily usage.

#### Real‑world critical use‑case 2: AI‑assisted web debugging
We cannot simply open the page in an external browser.

The integrated browser is required for VS Code Agent / Copilot AI web debugging workflows:
‑ Only the built‑in browser can share live DOM, console logs, screenshots and page context directly into Copilot chat and agent sessions.
‑ External browsers cannot feed live page context to VS Code AI agents.

If integrated browser cannot use whistle proxy, AI agents observe raw unmocked backend responses instead of our actual local debugging environment. Developers have to manually copy and paste logs back‑and‑forth, which completely breaks the end‑to‑end AI‑driven debugging workflow.

### Proposed solution
Add dedicated user/workspace settings for integrated browser proxy inside settings.json, for example:
‑ `workbench.browser.proxy`
‑ `workbench.browser.proxyBypassList`

These settings should control the proxy used by the integrated browser. It is acceptable if changing these settings requires restarting VS Code to take effect due to underlying Chromium/Electron technical constraints.

### Alternatives considered
‑ System‑wide OS proxy: pollutes network for all other applications, not viable for day‑to‑day development.
‑ Open page in external browser: loses AI agent context‑sharing capability, defeats the purpose of using the integrated browser.

### Additional context
Local window scenario, not remote SSH/WSL.
Typical whistle proxy address: `http://127.0.0.1:8899`.

Contributor guide

Open the contributing guide

Assessment

This issue has not been assessed yet.

Get new issues in your inbox

A short digest of beginner-friendly GitHub issues.