Problem (one or two sentences)
Zoo Code's "Browser Use" opens a separate Puppeteer-controlled Chromium process outside VS Code, controlled only via screenshots, while VS Code now has a native Integrated Browser that opens as a real editor tab.
Context (who is affected and when)
Affects anyone using Zoo Code's browser tool for web development or testing — the separate window breaks the in-editor workflow, and the browser session doesn't share cookies/auth with VS Code's own browser state.
Desired behavior (conceptual, not technical)
When Zoo Code needs to open or interact with a web page, it should use VS Code's built-in Integrated Browser tab instead of launching its own external browser window.
Constraints / preferences (optional)
Should keep working through remote connections (Dev Containers, SSH, WSL, Codespaces) the same way VS Code's native browser already does.
Request checklist
Zoo Code Task Links (optional)
No response
Acceptance criteria (optional)
Given a task that needs to visit a webpage
When Zoo Code opens the browser
Then it opens as a VS Code editor tab using the Integrated Browser
And session data is shared with VS Code's own browser storage
But it should not require a separate application window
Proposed approach (optional)
Drive VS Code's workbench.browser APIs for the browser tool, similar to how GitHub Copilot Chat integrates via workbench.browser.enableChatTools, instead of spinning up a separate Puppeteer/Chromium instance.
Trade-offs / risks (optional)
The Integrated Browser is still an experimental VS Code feature and may not expose everything the current screenshot-based Puppeteer flow can do (e.g. certain automation actions); a fallback or toggle may be needed rather than a full replacement.
Problem (one or two sentences)
Zoo Code's "Browser Use" opens a separate Puppeteer-controlled Chromium process outside VS Code, controlled only via screenshots, while VS Code now has a native Integrated Browser that opens as a real editor tab.
Context (who is affected and when)
Affects anyone using Zoo Code's browser tool for web development or testing — the separate window breaks the in-editor workflow, and the browser session doesn't share cookies/auth with VS Code's own browser state.
Desired behavior (conceptual, not technical)
When Zoo Code needs to open or interact with a web page, it should use VS Code's built-in Integrated Browser tab instead of launching its own external browser window.
Constraints / preferences (optional)
Should keep working through remote connections (Dev Containers, SSH, WSL, Codespaces) the same way VS Code's native browser already does.
Request checklist
Zoo Code Task Links (optional)
No response
Acceptance criteria (optional)
Given a task that needs to visit a webpage
When Zoo Code opens the browser
Then it opens as a VS Code editor tab using the Integrated Browser
And session data is shared with VS Code's own browser storage
But it should not require a separate application window
Proposed approach (optional)
Drive VS Code's workbench.browser APIs for the browser tool, similar to how GitHub Copilot Chat integrates via workbench.browser.enableChatTools, instead of spinning up a separate Puppeteer/Chromium instance.
Trade-offs / risks (optional)
The Integrated Browser is still an experimental VS Code feature and may not expose everything the current screenshot-based Puppeteer flow can do (e.g. certain automation actions); a fallback or toggle may be needed rather than a full replacement.