dsh-web-search-pro

What the plugin adds to DeepSeek Harness

dsh-web-search-pro is a bundle plugin for DeepSeek Harness, which the README refers to as DSH. The README describes it as an improved, persistent web search plugin that packages multi engine web search, platform search, persistent caching, controlled per site upgrades, and Playwright rendering into eleven tools a model can call directly. DeepSeek Harness is the host application, and this plugin extends it with search and browsing abilities. The README says the routing control plane borrows ideas from the Agent Reach project for backend probing, ordered selection, and failure cooling, while the core logic is original TypeScript written for this project. The plugin is distributed as a DSH bundle, which means it is meant to be added through the harness plugin command rather than installed as a loose script. Persistent caching is a stated feature, using SQLite with an LRU cache so repeated queries can be served without hitting the network again. That persistence matters for sessions that ask similar questions repeatedly, because it reduces latency and external calls. The README frames the plugin as giving the model real web access through a controlled set of tools, with backend selection and caching handled inside the plugin instead of by the model prompt alone.

Installation and dependency handling

The README gives an install command that adds the plugin to a profile called web: dsh plugin add dsh-web-search-pro. The note says this automatically installs dsh-browser as a dependency and automatically mounts a browser line through a patch, so the user does not have to wire up the browser support by hand. The README also shows a local directory or tarball install path using the same command with a path instead of a name, and it notes that after adding, the web profile must be restarted because it disables hot module reload. For npm based installs, the README says the resolver pulls in the package at anweat/dsh-browser, and for local development it suggests listing both paths in one command: dsh plugin add ../dsh-browser ../dsh-web-search-pro. The README mentions that dependencies under the deepseek namespace are published to npm at version 0.1.0 release candidate 6, matching the community dsh cc tui package. If a user runs a local source checkout at a slightly different version such as 0.1.0 release candidate 5, the README advises aligning versions in the profile's pnpm workspace file and reinstalling. These steps show the plugin expects a pnpm managed DSH setup with a web profile. The automatic browser dependency install and the patch that mounts the browser line reduce the setup steps a user must perform by hand.

Tools exposed to the model

The README includes a table mapping situations to the tool the model should use. For everyday web search the entry point is web_search_pro, which falls back through configured engines in order and accepts a fresh flag to force a refresh. For semantic research and community opinions the same tool is paired with the Exa engine, using a native Exa API when a key is present and falling back through mcporter when only an Exa MCP connection exists. For batch content from known URLs the tool is web_exa_contents, which calls the Exa contents endpoint and requires an EXA_API_KEY. For platform search across GitHub, Bilibili, and Reddit the tool is web_platform_search, with the note that some OpenCLI platforms need a Chrome extension online and that restricted Chinese sites use an AuthProfile. For pages behind login or private forums, browser bindings plus an AuthProfile are used, with cookies stored locally in a storage state and granted per domain, defaulting to read only. For pages that change layout or lazy load, platform rules or a RulePack are recommended, preferring selector changes before waiting, clicking, or scrolling. These tools give the model graduated levels of access from plain search to authenticated browsing. The table in the README makes the intended entry point explicit for each situation so the model picks the right tool without guesswork.

Browser automation and safety controls

Beyond search, the plugin exposes browser automation tools with explicit safety posture. The README lists browser_recipe_run for model generated multi step page actions, where read only steps run directly and interactive steps follow the automation mode set in dsh browser as deny, approve, or passthrough. For externally generated userscripts the flow is browser_script_validate then browser_userscript_run, and the README says the plugin enforces an at match rule, grants none, and disables require, with only an unrestricted mode skipping approval. For OpenCLI site adapters or a browser bridge the tools are browser_opencli_status and browser_opencli_run, which use Chrome explicitly and skip the generic argument approval only in unrestricted mode. A user is told to run web_backend_status first to judge whether a backend is reachable before issuing searches, which ties the routing logic to a quick health check. The combination of per domain AuthProfile grants, read only defaults, and approval modes shows the plugin is built to let a model browse the web while keeping the user in control of what scripts run and what credentials get used. The README consistently frames these as tools the model calls, with the plugin managing backends, caching, and safety. The per domain grant model and the read only default keep the most sensitive actions behind an explicit user decision.

Editorial conclusion

The plugin is written in TypeScript and published under the MIT license. The README installs it with the command dsh plugin add dsh-web-search-pro and depends on the dsh-browser package.