DeepSeek Harness Browser

⚠️ Unofficial community project

Not affiliated with, endorsed by, or maintained by DeepSeek AI. This is a third-party plugin for their open-source harness. For the official project see deepseek-ai/deepseek-harness. Please do not report issues with this repo to DeepSeek.

A browser pane inside the harness, beside the chat. A real Chrome the human can watch and type into, plus rendered previews of local files — and three tools that let the model drive it and read what is on screen.

The pane is a real layout column: the conversation gives up space rather than being covered. Measured 907px → 447px when it opens, and back on close.

---

What it does

Web pages open in a real Chrome, driven over the Chrome DevTools Protocol with its own persistent profile. You can log in. You can type. Sites that refuse to be framed work, because nothing is being framed.

Local files are rendered, not linked:

kind	shown as
.md	formatted document — headings, tables, code, task lists, quotes
.html	the real page, with its relative images and styles resolving
images	framed on the app background
PDF	page images, rendered server-side — no browser PDF viewer needed
code / text / config	syntax-framed with language and line count

Clicking a link or a file path in the chat opens it in the pane.

Saving a file to your own machine. A ↓ button appears in the toolbar whenever the pane is showing a file. It serves the real bytes with Content-Disposition: attachment rather than the rendered page you are looking at. This matters most when the harness is on another machine — the file lives over there, and until now the pane only ever showed you a picture of it.

The button is deliberately absent for web pages: "download" is not a meaningful action on a live page, and a button that does nothing is worse than no button.

---

The three model-facing tools

• open_preview(url, label?) — a web page or a local file. Accepts bare domains (cnn.com), http(s) URLs, localhost:PORT, and file paths (C:\path\file.md, /abs/path, file: URLs).
• read_preview(start?, count?) — what is on screen, as text. Pages through with start=end when end < total_chars.
• close_preview(url?) — one tab, or the whole pane.

read_preview answers from the right source for each kind:

showing	read from
web page	the live DOM over CDP — document.body.innerText
PDF	the document's text layer (PyMuPDF), not the page images
local file	the rendered page

---

Why a real browser, and not an iframe

This is the central design decision, and it was reached by measurement rather than preference. An iframe cannot do this job, for three independent reasons:

1. Sites refuse to be framed. x.com sends X-Frame-Options: SAMEORIGIN plus a CSP frame-ancestors 'self'; reddit.com sends SAMEORIGIN. The browser obeys, and the pane renders blank.
2. Cookies default to SameSite=Lax, which the browser withholds inside a cross-site iframe. Even a framable site renders signed out, with a valid session sitting right there unused.
3. A server-side proxy fetches anonymously, so it cannot hold a session at all.

Only (3) is fixable in userland, and fixing it would not have helped.

…