Browser control plugins: browser, Chrome, desktop

Browser control is not one plugin but three capabilities: a shared browser, a Chrome takeover, and full-desktop operation. Permissions widen from narrow to broad, and the wrong pick turns a simple task into a risky one.

Three capabilities

Start with scope and permission surface.

A shared browser means working together. The agent drives pages and you can take over at any moment, which suits flows that need human confirmation (source).

A Chrome takeover means reusing login state. It connects to a browser you are already signed into, removing repeat logins; the price is that permissions follow that session (source).

Desktop control can click anything. It covers scenarios a browser cannot, at the highest risk. If browser control suffices, do not escalate.

dsh-browser: shared and takeover

The point is that it stays visible and interruptible.

1. It launches a real browser instance where the agent operates.
2. You can take over mouse and keyboard for CAPTCHAs or confirmations.
3. It suits login, form filling and flows that need human judgment.
4. Installation differs by platform, so read the notes first.
5. With parallel tasks, watch isolation between browser instances and tabs.

Sharing means a human can rescue the run and also that state affects both sides. CAPTCHAs, second confirmations and broken pages can be handled by hand instead of forced. If you change the page manually, the agent's next step may rely on stale state, so have it re-read.

dsh-chrome-control: taking over a session

It reuses your Chrome instead of opening another browser.

1. Install the companion extension and connect the local daemon.
2. Configure the daemon port so the plugin can reach it.
3. Drive pages through mcp__chrome__* style tools (source).
4. Reuse login state, which suits sites that require an account.
5. Close the connection after the task to avoid long-lived exposure.

Login state is convenience and risk. Reusing a login means access to that account's content; use a separate browser profile for sensitive accounts.

Extension and port are the main failure points. A missing extension, a version mismatch or a closed port all surface as "cannot connect to the browser."

The limits of computer use

It can click a browser, but it is not the first choice for web work.

1. Its scope is the whole desktop, wider than browser control.
2. It suits local apps, cross-application flows and cases a browser cannot handle.
3. Screenshots, clicks and typing depend on system permissions and display scaling.
4. Diagnosis is harder because permissions, coordinates and tool gates all matter.
5. When browser control works, do not use computer use.

Wider permissions demand restraint, and computer use is not a universal tool. For web-only tasks, browser control is more predictable and easier to roll back. Since cost and risk are higher, ask first whether browser control can do the job.

Choosing

Decide by web-only scope, login reuse and cross-application needs.

Least privilege comes first. If web capability is enough, do not open desktop control.

Run a minimal flow first. Open a page, click a button, read a paragraph; only then attempt a complex flow.

Install and permissions

Installation follows the normal plugin flow; permissions are the real issue.

1. Search the Hub for the plugin name and check owner and source.
2. Restart after install and confirm the plugin loaded.
3. Chrome control also needs the extension and a running daemon.
4. Grant screen, accessibility and network permissions only as needed.
5. Close the instance or connection when the task ends.

Grant per task. For one site, do not hand over desktop-wide permissions; for one run, close it afterward.

Record the connection details. Port, extension version and browser version are the first three things to check when something breaks.

Troubleshooting

Four failure classes cover most browser control problems.

1. Cannot connect: extension missing, port closed, or browser version mismatch.
2. Clicks do nothing: selectors changed, the page has not loaded, or the wrong tab is active.
3. Login state expired: session timeout, second-factor challenge, or a different browser profile.
4. Blocked by policy: host permissions, site anti-automation, or network policy.

The entry order is connection, page, login, policy. Confirm the link, then page state, then permissions and policy.

Read logs in segments. Connection failure and action failure are different layers; mixing them leads to the wrong fix.

Next steps

Choose scope before capability. For background on browser automation, read What dsh-browser is. For computer use failures, read Computer use not working. For permission boundaries, read What DSH plugins can and cannot do.

Sources: dsh-browser plugin page, dsh-chrome-control plugin page, DeepSeek Harness documentation