DeepSeek++ is archived, pins Firefox to Manifest V3, and runs tool calls without asking first

Archived, with three releases inside four days

The repository is marked archived. The last push to the default branch is dated 2026-08-13, and the three most recent releases are 1.13.0 on 2026-08-05, 1.13.1 on 2026-08-06 and 1.14.0 on 2026-08-08. So the final week of activity produced a feature release, a patch the next day, and another release two days later, and then the project stopped rather than trailing off. The distribution channel is a Chrome Web Store listing rather than the repository itself, which is the common arrangement for a browser extension and means the code you can read is not the artefact a user installs. The version field in package.json reads 1.14.0, matching the newest tag, and the package is marked private, so nothing is published to npm. Anyone picking this up should treat 1.14.0 as the final state rather than a version to upgrade past.

Firefox is pinned to Manifest V3 and the other two are not

The build scripts show the shape of the whole release process, because there is one command per browser and a script that chains them. `build:chrome`, `build:edge` and `build:firefox` run the same builder three times, and `build:all` runs all three in sequence. The Firefox command adds a manifest flag that the other two do not, pinning that target to Manifest V3 while Chrome and Edge are built without it. The same asymmetry repeats in the packaging scripts, where the Firefox zip carries the flag too. That single flag is the most consequential difference between the three builds, and it also lines up with a functional gap: browser control is documented as available only in Chrome and Edge environments, so the Firefox build is the one without page control. Anyone maintaining a fork would want to know whether that flag was a temporary workaround or a permanent constraint, because the page says nothing about it.

Tool calls run without confirmation, code execution does not

This is the most important line in the documentation and it is easy to skim. When the model emits a tool call, the extension recognises it and executes it, with no copying by the user and no manual confirmation step, and the page deliberately does not expose the technical details of the call, rendering the result as a collapsed block in the shape of a thinking section that reports how many tools were called and lists each result. The permission story changes for one category. High risk code execution, or anything needing explicit authorisation, shows a confirmation card first and continues only after the user approves. Skill drafts take the same shape: the model can draft one, but a person previews, edits and confirms before it is saved. So the trust boundary is drawn around code execution and around saved behaviour, and left open for tool calls, which is a deliberate split rather than an oversight.

Browser tools are injected only after you attach a tab

Browser control has the most careful design in the extension. It is off until it is switched on in the sidebar under the capabilities section, and even after switching it on, a target tab has to be selected before the browser tools are injected into a new session. The model is given page structure and a summary of visible text, not a screenshot, and both the snapshot node count and the text budget can be adjusted, which is the knob that decides how much of a page the model sees. The current attachment state is viewable, the target list can be refreshed, the controlled tab can be switched, and the connection can be dropped, and once it is off no browser tools are injected into new sessions at all. Set against that, the floating chat entry on ordinary pages is stated to never read or send the current page text on its own; content enters the flow only when a person types, sends, or uses the selected text scene.

Large file reads advance by code point and stream by byte

The local file reading path is the part of the documentation that reads like it came from a bug report, and it explains three separate fixes. First, when a file is larger than a single read, the extension side performs the continuation deterministically in a code loop rather than depending on the model to decide to ask for more, which removes the case where a read stops halfway in silence. Second, the resume position advances by Unicode code point rather than by UTF-16 code unit, so files mixing emoji with Chinese text reassemble window by window without dropped characters. Third, the host reads character windows on demand by byte instead of loading the whole file into memory, so a very large file cannot exhaust memory. A separate built in tool pair handles the web side, one for searching and one for fetching a page's visible text, and both feed results back into the same conversation so the model continues rather than stopping.

The feature table is a keyword list with a capability beside it

The quick reference table has two columns, and the left one is not a requirement so much as a search phrase. Rows begin with an English keyword pair, then a Chinese one, or with the product name followed by a feature noun, the way a page optimises for queries. The positioning section does the same thing in prose, opening by naming the phrases a reader might be searching and then equating all of them with one local first workbench. Reading the table that way explains its shape, since a table whose left column repeats product name plus feature phrase is documentation and discoverability work at once. The right hand column is where the substance is, and it is dense: sidebar conversation, a floating chat entry, right click sending, MCP service and permission management, multimodal analysis through a native host, project context, downloadable artifacts, export in four formats, saved snippets, prompt controls, scheduled automation and web fetch. Each of those is a separate subsystem with its own settings page.

Six verify scripts and three different Chrome submission flags

The release side of package.json is disciplined enough to be worth reading even though the project is now closed. Six checks gate what may ship: one lints the GitHub workflows, one enforces a manifest policy, one verifies UTF-8 correctness inside the extension, one enforces a side panel chunk budget, one validates release assets, and one verifies bundled skill packaging. Packaging adds a sources archive built by a custom script alongside the three browser zips, so what is distributed includes the source. Submission to the Chrome store has three separate commands with different flags: a dry run, one that uploads while skipping submit review, and one that publishes to the default target. Running tests is a single vitest call and there is a separate type check that runs tsc with no emit, so nothing is written during verification.

Editorial conclusion

DeepSeek++ is worth reading for its engineering even now that it is frozen, because its permission model and its file handling are described more precisely than most extensions describe anything. Anyone installing it should understand three things first. Tool calls execute as soon as the model asks, with a confirmation card reserved for high risk code execution rather than for tool use in general, so the trust decision happens at configuration time rather than at each call. Browser control is a per session switch that injects tools only after you attach a tab, and it is unavailable on Firefox. And the project is archived: the last push was on 2026-08-13, the newest release 1.14.0 came out on 2026-08-08, and there is no further maintenance coming, so an extension that reads pages, stores memories and runs third party MCP tools needs a plan for when its store listing and its dependencies drift.

Frequently asked questions

Official sources

1. License: Apache-2.0
2. Project website
3. README
4. Releases
5. zhu1090093659/deepseek-pp on GitHub