Repository navigation
[FEATURE]: Integrated browser for desktop #26772
Description
Feature hasn't been suggested before.
- I have verified this feature I'm about to request hasn't been suggested before.
Describe the enhancement you want to request
I would like OpenCode Desktop to include an integrated browser workspace.
The goal is to let users inspect and interact with web pages without switching to an external browser. This would be useful for tasks where the agent needs browser context, screenshots, console messages, page annotations, or form interaction.
Proposed behavior:
- Add an embedded browser panel in the desktop app.
- Allow opening pages from prompts like
/browser <task>or@browser. - Let users annotate elements on the page and send those annotations as chat context.
- Let users take screenshots and attach them directly to chat.
- Expose integrated browser tools to the agent for navigation, inspection, clicking, typing, screenshots, and console messages.
- Add a setting to enable or disable automatic integrated browser tools.
Reacted by nickchomey, Luca Olovrap, Leon Cheng, giuseppebonanno, Pedro Monteiro, Kristian Bonnici, Luca Schöneberg, ioetr, David Chalifoux, Clemens Damke and 4 more
Reacted by akashskypatel
Metadata
Metadata
Assignees
Labels
No labels
Activity
github-actions commentedon May 10, 2026
This issue might be a duplicate of existing issues. Please check:
Please review those issues and their discussion before this proceeds, to avoid duplicated effort.
AlexDelgado20 commentedon May 23, 2026
Hey team, I wanted to follow up on the duplicate flag and clarify why this is not a duplicate of either #6992 or #20490.
Why this is different from #6992 ("Browser automation like Claude in Chrome")
#6992 is about agent-driven browser automation — having the AI agent autonomously navigate websites, click buttons, fill forms, and extract data. That's a tool/runtime concern: the agent controls a headless or headed browser programmatically.
This feature is a UI panel — an embedded WebView (Chromium via Electron) that lets the user browse the web inside the desktop app without context-switching to an external browser. It's a workspace surface, not an agent tool. The agent would see what the user is looking at, but the primary interaction model is human-driven browsing alongside the chat.
Why this is different from #20490 ("Computer Use / Desktop Control")
#20490 is about full desktop control — screenshots, mouse clicks, keyboard input across any GUI app. That's a multi-OS, multi-display-server challenge (X11, Wayland, macOS, Windows DPI scaling).
This feature is single-purpose: render web content inside a Chromium-powered panel in the desktop app. No screenshots, no OS-level input simulation, no cross-app automation. It's a contained, well-understood integration using Electron's existing rendering engine.
What this feature actually is
I understand the concern about duplicated effort — both #6992 and #20490 are adjacent. But they address the agent acting on the browser, while this addresses the user having a browser inside the workspace. Different interaction model, different architecture, different scope.
Happy to split the work into smaller, focused PRs or discuss any maintainer concerns.
nickchomey commentedon May 28, 2026
Yes, this would be fantastic. This is the main thing that is making me begrudgingly stick with VSCode Github Copilot Chat (now using OpenCode Zen/Go API key, since copilot got rugpulled)
HDerwyn commentedon May 29, 2026
Hello, is this being worked? I am really interested in this feature
AlexDelgado20 commentedon May 29, 2026
Hello, Yes, this used to work at the time, but with the recent OpenCode interface changes I have to recompile and update the code. But I am not motivated since it was not given follow-up.
m13v commentedon May 30, 2026
the pattern with bolting a browser into a desktop agent is that the hard part isn't rendering, it's session ownership. once you expose navigate/click/type to the agent AND let the user annotate the same page, they fight over one cursor and one DOM, so the agent clicks mid-annotation and the context sent to chat is already stale. the desktop tools that get this right keep a background browser the agent drives separately from the pane the user inspects, and gate each agent action behind an explicit approve step. the enable/disable toggle you mention is really an approval-surface question, not a feature flag.
HDerwyn commentedon May 30, 2026
Another option is to just lock the browser while the agent is doing its thing, suppress clicks, scrolls, and typing from the user so they don't accidentally step on each other. Once the agent finishes and goes idle, release the lock and let the user interact again. It's a lot simpler than running two browsers side by side, but the downside is the user can't watch what the agent is doing in real time; they have to wait until it's done to see the result.
HDerwyn commentedon May 30, 2026
i'm not really sure how this works to be honest, but if you already got some progress maybe you can upload it in a branch and we can continue together if you need help, this feature will increase the value of opencode matching other tool's features like codex which already has this implemented.
leoncheng57 commentedon Jun 28, 2026
FYI — there was a prior attempt at this in PR #26773 ("feat: add integrated browser workspace") by @AlexDelgado20, which implemented an embedded browser panel via Electron's BrowserView with /browser and @browser prompts, page annotations, screenshot-to-chat, and agent-exposed browser tools. It was closed without merging on 2026-05-11.
Also FYI this missing feature is what made me quit using OpenCode last week, so I see it as extremely vital to add asap.
kyjus25 commentedon Jun 28, 2026
@leoncheng57 Yeah, agree here. This and the agent being able to read and write to the integrated terminal (PR 23794) are 2 very important missing features in my opinion. Hope we see movement on them.
311u1 commentedon Jul 11, 2026
I like how Cursor has this, also its cleaner becuase i can check and read PRs without leaving the window - Claude Code lacks this - they have chips but you have to switch between browser and agent workspace - so my 2cents is its more of a UX improvement in terms of where I see value - people testing UIs in localhost might like it too.
Example of how it could be implemented
Hona commentedon Jul 11, 2026
Without promising anything, this is something we want to look at after Desktop v2 launches
kyjus25 commentedon Jul 11, 2026
@Hona
311u1 commentedon Jul 13, 2026
haha anthropic dropped this in Claude code desktop app just then - its like they are reading our mind
Let me know if you want me to ship this for you guys so I have a place to escape to when they take away all my subsidies 😆😂
NateSpencerWx commentedon Jul 18, 2026
@Hona can you look at this now :)
peng9627 commentedon Sep 11, 2026
Hi @AlexDelgado20,
Thank you for the update! It's completely understandable that open-source maintenance is tough, especially after major breaking API changes.
I am a big fan of OpenCode and I really want to see this browser/webview feature come to life. I am planning to leverage an AI coding agent (Codex) to push this feature forward and handle the refactoring needed to adapt to the latest OpenCode APIs.
To keep it lightweight, my implementation will use
puppeteer-coreto dynamically reuse the user's existing local Chrome/Edge installation, ensuring zero bundle-size bloating.If you don't mind, I would love to take over this task and drive the development. I will review the new API structure, implement a clean prototype, and open a Pull Request soon.
Let's make this closed-loop automation happen together! 🚀