DEV Community: Bob Lee

I made DeepSeek Harness plugins available to any MCP agent (without handing it install rights)

Bob Lee — Thu, 13 Aug 2026 16:23:43 +0000

DeepSeek Harness takes “everything is a plugin” unusually far. Models, tools, sessions, the agent loop, and UI surfaces all live in a Cordis composition.

That freedom creates an interoperability problem: what if your primary agent is not DSH?

An MCP-capable desktop agent should not need to replace its runtime just to inspect or use a useful DSH plugin. It should be able to discover the plugin, review what it is, explicitly choose whether to install it, and—only when allowed—call its live tools.

I contribute to BitFun. We built an early bridge to test that idea: deepseek-harness-plugin-mcp.

This is not an official DeepSeek component. It is source preview. The npm package is not published yet, so do not copy the npx example from the current README and expect it to work.

One bridge, three trust boundaries

The first design mistake would be exposing one magical “install and run this plugin” tool. Discovery, local mutation, and execution do not deserve the same authority.

The server therefore has three planes.

Catalog: useful while read-only

The catalog plane searches repositories carrying the dsh-plugin GitHub topic, caches a compact index, and lets an MCP client inspect a candidate before touching local DSH state.

It can answer questions such as:

Is this repository an installable Cordis bundle, an MCP server, a UI extension, or a directory?
Does package.json declare a DSH bundle?
Is there a cordis.patch.yml?
What GitHub install spec would the DSH CLI accept?

Catalog access is enabled by default. Install and runtime access are not.

That separation matters because a repository description is discovery metadata, not compatibility proof. The bridge also treats Cordis !!js config as opaque inspection data; it does not evaluate arbitrary config while cataloguing a repository.

Relevant source:

src/github/catalog.ts
src/plugin/inspect.ts
src/plugin/classify.ts
src/mcp/resources.ts

Profile: mutation requires an explicit opt-in

dsh_plugin_install and dsh_plugin_uninstall are disabled unless the operator starts the bridge with --allow-install (or the equivalent environment flag).

When enabled, the bridge delegates to the official command:

dsh plugin --profile <name> add|remove ...

It does not quietly edit a profile manifest itself. After the command returns, it reads the observed profile state back and returns the installed bundles and dependencies.

This is better than a boolean success response, but not enough for production. A mutating bridge should return a receipt containing at least:

the immutable source commit;
the profile diff;
installed, skipped, and rejected components;
requested capabilities;
the first health check;
an exact rollback action.

An external reviewer raised exactly this point on X, so it is now public issue #1.

Runtime: project live DSH tools into MCP

Runtime access is a second, independent opt-in: --allow-runtime.

When enabled, the host starts a dedicated DSH profile, reads the live ctx.tools registry, and projects compatible tools into the MCP server under deterministic dsh__* names.

MCP client
  -> dsh__some_tool
  -> bridge lookup and argument forwarding
  -> live DSH ctx.tools.execute(...)
  -> DSH policy and result pipeline
  -> MCP result

The DSH runtime remains the execution owner. The bridge does not import arbitrary plugin executors into the MCP process.

This also means “plugin” does not automatically mean “MCP tool.” UI, TUI, theme, and configuration-only plugins can appear in the catalog without pretending to expose model-callable functions.

Relevant source:

src/runtime/host.ts
src/runtime/bridge.ts
src/dsh-plugin.ts
src/mcp/server.ts

Why we built this from BitFun

BitFun already uses MCP as one extension layer, while keeping workspace execution, permissions, sessions, remote control, and its desktop UI inside typed product boundaries.

DSH is interesting for the opposite reason: its runtime graph is deeply replaceable.

The bridge lets us test a middle path:

BitFun keeps ownership of the workstation and user-facing control plane;
DSH keeps ownership of a plugin composition and its live tool pipeline;
MCP becomes the explicit boundary between them.

The same bridge can be used by any MCP-capable agent. It is not a BitFun-only protocol.

What we cannot say yet is “BitFun supports every DSH plugin.” Compatibility varies, packaging is unfinished, and install receipts and cancellation evidence still need work.

The production checklist

Before calling this mature, I want the project to prove:

source provenance is immutable;
profile mutations produce auditable receipts and tested rollback;
bridged calls preserve DSH and host permission decisions;
MCP cancellation reaches DSH and the underlying capability;
dsh__* names stay stable across reloads and collisions;
compatibility is tested against named DSH revisions;
the npm instructions match an actually published artifact.

Until then, it is an architecture experiment with real code—not a polished package.

Source: https://github.com/bobleer/deepseek-harness-plugin-mcp

BitFun: https://github.com/GCWing/BitFun

If you use another MCP agent and have a specific DSH plugin in mind, open an issue with that exact pair. A concrete compatibility case is much more useful than “support all plugins.” If the direction is useful, a star tells us which side of the bridge to harden first.

DeepSeek V4 Pro is cheap. Your agent harness can still waste the cache

Bob Lee — Thu, 13 Aug 2026 06:54:24 +0000

DeepSeek V4 Pro 0813 has made cost comparisons fun again. The model is capable, the API is cheap, and the first wave of coding demos looks good.

But model price is not the same thing as agent task price. A harness can quietly erase much of the advantage before the model gets to do useful work.

The one-byte problem

A coding agent resends a large prefix on every turn: system instructions, tool schemas, repository context, and conversation history. Prefix caching only helps while that prefix stays identical. Add a timestamp, reorder the tools, or serialize one object differently and the cache can miss from that byte onward.

That matters more on real repository work than on a one-shot demo. Search → patch → test → read the failure → repeat can run for dozens of turns. If every turn rebills the same prefix, a cheap model starts behaving like an expensive workflow.

What we measured in BitFun

We build BitFun, an MIT-licensed desktop agent workbench with a Rust runtime. Prompt assembly is kept byte-stable across turns. In one SWE-Bench-Pro run using DeepSeek V4 Pro, the average KV-cache hit rate was 98.67%. This is a single-run engineering signal, not a universal benchmark claim, but it tells us the optimization is doing its job.

The other half is persistence. Long repository tasks rarely finish in one clean response, so BitFun's Goal mode persists the objective across turns and automatically continues while it remains active. The runtime can schedule up to 100 continuation turns for one objective, with bounded retry backoff when a continuation submission fails. It does not promise that every task magically succeeds; it is designed so the agent does not confuse “I wrote a plausible answer” with “the repository task is actually done.”

Why V4 Pro and the harness should be evaluated together

The same model can look very different in two coding tools because the model only supplies part of the system. Tool selection, error recovery, context packaging, repository search, and stopping policy all live in the harness.

BitFun already includes DeepSeek V4 Pro in its model catalog, but support is the boring part. The interesting question is whether the surrounding runtime preserves DeepSeek's cost advantage through a long search/patch/test loop. That is the problem the 98.67% measurement answers.

BitFun runs on macOS, Windows, and Linux, and the source plus installers are here: github.com/GCWing/BitFun. If this is the kind of open agent workbench you want to see grow, a star helps more builders find it.

A Remote Coding Agent Can Deadlock on a Local Permission Dialog

Bob Lee — Thu, 13 Aug 2026 00:07:48 +0000

The nastiest failure mode in a remote coding agent is not a bad patch.

It is a permission prompt that nobody can see.

You start a long-running job on a workstation, leave the desk, and check it from a phone later. The agent reaches a command that needs approval. If that request only exists as a modal in the desktop UI, the job has not technically failed. It has just stopped forever.

That is worse. A failed job is observable. A hidden wait looks healthy until someone notices no work has moved.

The permission prompt is protocol state

The fix starts with a small change in how you model approval.

A permission request is not UI state. It is durable state owned by the job that is doing the work.

The lifecycle should look more like this:

asked → persisted → surfaced → answered → applied → resolved

The desktop dialog, phone screen, CLI, or web controller is only one view over that state. Closing a window must not erase it. Reconnecting must not create a second request. Two controllers must not be able to resolve different requests because a stale button happened to be on screen.

This also changes what a remote-control protocol needs. A controller should be able to fetch job status with pending approvals, submit an answer for one request ID, and observe the resulting event. It should not become a filesystem or runtime proxy just to click “allow.”

What needs to survive a disconnect

At minimum, the pending request needs a stable request ID, its owning job/session, the requested action and resources, and enough ordering information to render concurrent requests deterministically.

The answer also needs an identity.

If request abc is pending, an answer for xyz must fail. Replaying the same answer for abc should be harmless. Replaying a different answer under the same ID should not quietly overwrite the first decision.

That sounds fussy until a phone reconnects on a flaky network and retries the last command. Then it is the difference between idempotence and “the agent ran it twice.”

The mailbox also needs limits. A broken or hostile tool should not be able to fill an unattended host with an unbounded number of serialized approval requests.

Resuming the worker is a separate step

Persisting an “approved” flag is not enough.

The running worker has to consume the answer, apply it to the exact pending request, record where the reply came from, and only then remove the request from the mailbox. If the worker crashes between those steps, recovery should be able to tell whether the answer is queued, applied, or fully resolved.

Reply source matters too. A user approval, an automatic policy, and a system rejection are not the same audit event, even if they all unblock the same future.

When the permission event stream disappears, the safe behavior is not to assume approval. Pending work should fail closed or be cancelled with an explicit reason. Otherwise a transport failure silently turns into broader authority.

The UI is the easy part

Once the protocol exists, the phone UI really can be two buttons: approve and reject.

But those buttons are the last five percent. The hard part is making the request durable, routed to the correct session, replay-safe, auditable, bounded, and fail-closed.

There is also a boundary worth keeping explicit: an application-level tool approval is not an operating-system security grant. A remote controller can approve an agent action that the app is already capable of performing. It cannot legitimately manufacture Accessibility, Screen Recording, or similar host privileges that the operating system has not granted.

I am building BitFun, and this is how we ended up treating detached-job approvals: the target owns a persisted permission mailbox; the controller answers by request ID; the worker applies the reply with its source and marks it resolved. The same permission events can then reach desktop and remote-control surfaces without making the controller the runtime.

The implementation is open source here: https://github.com/GCWing/BitFun

Your Coding Agent Shouldn't Grade Its Own Patch

Bob Lee — Wed, 12 Aug 2026 17:35:53 +0000

A coding agent finishes a patch, runs the tests, reads its own diff, and tells you the change looks good.

That sounds efficient. It is also a subtle conflict of interest.

The problem is not that the model is dishonest. The problem is that the same context which produced the patch also contains the assumptions that justified it. When the agent reviews its own work, it is likely to reuse those assumptions instead of challenging them.

I have seen the failure mode look like this:

the implementation silently narrows the original requirement
the tests only cover the path the agent chose
the review praises consistency with that implementation
nobody asks whether the implementation was the right one

A fresh reviewer helps, but "add another agent" is not a complete design. If both agents receive a vague prompt and unlimited access to the repository, you have mostly doubled the cost and created two confident narratives.

Here is the review loop that has been more reliable for me.

Give the reviewer a bounded target

The reviewer should know exactly what is being reviewed: a prepared diff, a commit range, or a small packet of changed files.

Treat that diff as the source of truth. Repository context can explain a finding, but it should not let the reviewer wander into a broad redesign. A bounded target makes the final report auditable: every claim can point back to a concrete change.

Keep missing evidence visible

A timeout, unavailable file, stale hint, or truncated diff is not a clean review.

This sounds obvious, but review systems often collapse "I did not find a problem" and "I could not inspect the thing" into the same result. They are very different outcomes.

Coverage limitations should survive all the way into the visible report. If part of the target was not inspected, say so. Confidence should go down instead of silently turning green.

Use specialists for questions, not coverage theatre

Launching a security reviewer, performance reviewer, architecture reviewer, and test reviewer on every patch looks thorough. In practice it creates duplicate findings, higher latency, and a new aggregation problem.

A specialist is useful when the primary reviewer has a concrete unresolved question:

Does this authorization check still protect the remote path?

That is much better than:

Review this code for security issues.

The assignment should be narrow, the expected evidence should be explicit, and the primary reviewer should still decide whether the answer is supported.

Make the judge conditional

A third model should not rubber-stamp every clean review. That turns "independent validation" into a mandatory tax.

Call a judge when a potentially serious finding needs validation, two reviewers conflict, or the final recommendation is still low-confidence. Ask it to inspect the disputed claim, not to repeat the entire review.

The judge should be allowed to keep, downgrade, or reject a finding. Otherwise it is not a judge; it is another source of prose.

Separate review from fixing

The review stage should be read-only.

Once an agent starts editing while it is still reviewing, the evidence changes underneath the report. It also becomes harder for a human to approve the actual remediation scope.

Produce the findings first. Let the user approve them. Then hand only the validated findings to a separate fixer that makes the smallest safe changes.

This structure does not remove the need for human judgment. It makes the judgment cheaper because the evidence, uncertainty, and proposed remediation are no longer mixed together.

I am building this loop into BitFun: the Deep Review orchestrator is read-only, missing evidence stays visible as a coverage limitation, specialist calls are bounded, the quality judge is conditional, and remediation is a separate stage.

The useful mental model is not "one agent writes and another agent reviews." It is:

one process proposes a change; a separate process tests the proposal against bounded evidence.

That separation is where most of the value comes from.

Your AI Task Should Not End as a Chat Transcript

Bob Lee — Thu, 06 Aug 2026 11:59:47 +0000

Chat is an excellent way to begin a task. It is a surprisingly poor place for many tasks to end.

Ask an assistant to investigate a repository, compare options, or manage a review queue, and useful state soon disappears into a vertical transcript: what is selected, what changed, which result is current, and what remains blocked. Returning later means reconstructing an application-shaped problem from messages written for an earlier moment.

This is not only a model problem. It is an interface problem.

A calendar wants a calendar. A dependency graph wants a graph. A review queue wants rows, filters, and explicit status. Conversation can remain the command surface, but structured work needs a task surface that owns its state and exposes the right actions.

Disclosure: I maintain BitFun, the implementation used as the source-linked case study below. I also used AI assistance to organize and edit this article, then checked every product-specific claim against pinned source code. The design pattern is the point; this is not an independent security audit or performance evaluation.

The missing object between chat and automation

Traditional chat has messages and attachments. Traditional automation has fixed inputs and outputs. Stateful agent work needs a third object between them: an interface that represents the task as it exists now.

That interface should own:

domain objects and their current status;
selections, filters, view mode, and revision;
the relationship between an agent action and the object it affects;
a place to inspect, accept, reject, or revise the result.

The key design decision is that the model does not magically “see the UI.” The application chooses a small, explicit snapshot of relevant state when the user submits a request. That snapshot becomes part of a versionable protocol.

This distinction matters. “What happens if I remove this node?” is ambiguous in a transcript. A dependency explorer can make it precise by sending the selected node ID, visible dependency set, active filters, and graph revision. It does not need to send the entire DOM, a screenshot, or every object in memory.

A reference architecture

BitFun's current Mini App implementation separates four responsibilities:

The Mini App owns presentation and domain state. Its source model has an HTML/CSS/ESM browser layer and can support worker logic in non-marketplace profiles.
The desktop host owns privileged capabilities. The iframe calls an injected window.app bridge; filesystem, network, shell, AI, Agent, notifications, and host UI are represented as explicit capability groups.
An owned agent session supplies continuity. A Mini App can create or restore a dedicated session, reuse it for later turns, and receive progress only for sessions associated with that app instance.
The normal scheduler owns execution. A Mini App agent turn is submitted through the same dialog scheduler used by the desktop runtime; it may start immediately or be queued.

The data flow is compact:

shared composer
      │  token-scoped user message
      ▼
sandboxed task UI ── relevant state snapshot ──► host bridge
      ▲                                             │
      │  session-filtered progress                  │ permission + ownership checks
      └──────────── owned agent session ◄───────────┘
                                  │
                                  ▼
                           dialog scheduler

There are two boundaries worth noticing.

First, the bridge is an API boundary, not an invitation to expose the whole desktop object graph. The public contract offers named operations such as agent.ensureSession, agent.run, chat.claimComposer, and chat.focusSession.

Second, session identity is part of authorization. Reusing a session is accepted only when its recorded owner matches the Mini App and its workspace matches the expected path. The web host separately tracks which sessions the current iframe started before allowing one to appear in the shared conversation surface.

Binding conversation to the task surface

The current API makes the binding explicit rather than implicit.

1. Claim the shared composer

An agent-backed Mini App can call app.chat.claimComposer(). While its tab is active, messages from the shared input are routed to that exact iframe as chat:userMessage events.

The claim is scoped by a per-runner token, not only an app ID. That matters because an installed app and a draft preview can share an ID while both are alive. The token prevents one submission from reaching both runners.

The Mini App may contribute bounded text such as a title, placeholder, and example prompts. The host still renders and owns the input component; the iframe cannot replace it with arbitrary host markup.

2. Create or restore an owned session

app.agent.ensureSession() creates a dedicated session or validates a requested existing session. app.chat.focusSession() then associates that known session with the Mini App's composer claim.

The separation is useful: “which interface receives this input?” and “which agent history should be visible?” are related questions, but they are not the same question.

3. Snapshot state at submission time

The host accepts a user-facing displayText separately from the Mini App's internal prompt. The transcript can therefore preserve what the user actually wrote while the agent receives a structured task protocol.

Here is the pattern in simplified form:

await app.chat.claimComposer({
  title: "Dependency Explorer",
  composer: { placeholder: "Ask about the current graph…" }
});

const topic = await app.agent.ensureSession({
  sessionName: "Dependency Explorer",
  appDataWorkspace: "topics/current"
});

await app.chat.focusSession(topic.sessionId);

app.chat.onUserMessage(async ({ text, displayText }) => {
  const state = collectRelevantState(); // app-owned model, not DOM scraping

  const prompt = JSON.stringify({
    protocol: "dependency-explorer/v1",
    request: text,
    state
  });

  await app.agent.run(prompt, {
    sessionId: topic.sessionId,
    displayText: displayText ?? text
  });
});

collectRelevantState() is deliberately application-specific. A production Mini App also needs an output contract: parse the result, reject malformed or stale revisions, and apply only validated changes. Starting an agent turn is asynchronous; progress and completion arrive as session-filtered events rather than as a magical synchronous answer from agent.run().

Why explicit state beats a giant prompt

The goal is not to serialize the entire application on every turn. A useful task surface creates a narrow boundary:

Keep durable domain state in the application.
Send only the state relevant to the current action.
Preserve the user's words separately from the internal protocol.
Reuse a session only when conversational continuity is useful.
Include a revision or other freshness signal when stale output would be harmful.
Validate agent output before changing application state or external resources.

This makes context inspectable. Developers can unit-test the snapshot, users can see the selected object, and maintainers can version the protocol. It also gives you a clear place to redact secrets and cap payload size.

Capability should follow the task, not the iframe

A stateful interface is useful only if its authority is equally specific.

BitFun's manifest model separates filesystem, shell, network, Node, direct AI, full Agent, notifications, and host-UI permissions. Shell access is expressed as a command allowlist, network access as a domain allowlist, and Agent access has its own enabled flag and optional per-minute limit. Host-side handlers check these gates before servicing bridge calls.

The current public-market profile is intentionally stricter than the general source model:

marketplace packages must explicitly disable Node;
remote imports and dynamic code evaluation are rejected during package validation;
broad home-directory and absolute filesystem scopes are rejected;
marketplace iframes run with sandbox="allow-scripts", without same-origin access;
hidden Agent turns from marketplace Mini Apps use a small allowlist centered on read-only web research rather than filesystem, shell, or host control.

These are concrete controls, not a claim of perfect isolation. Human review, manifests, iframe sandboxing, and allowlists reduce different risks; none of them makes untrusted code inherently safe.

The implementation also retains a compatibility profile for built-in or local Mini Apps with a broader iframe sandbox and optional worker support. Therefore, statements about the marketplace strict profile should not be generalized to every Mini App. That split is visible in the runner code and is an important part of the threat model.

What this pattern does—and does not—solve

It solves a real interface problem:

the user can point at an object instead of redescribing it;
follow-up turns can continue in the task's own agent session;
progress can appear beside the state it affects;
permissions and ownership checks have explicit enforcement points.

It does not give the model automatic access to arbitrary UI state. It does not remove the need to design state and output schemas. It does not guarantee correct model output. It does not turn an iframe sandbox into a complete security boundary, and it does not make every task better as an app.

A one-off explanation probably belongs in chat. A task becomes a strong Mini App candidate when it has several of these properties:

state changes over multiple turns;
the user repeatedly selects or compares objects;
the output needs review before it is applied;
the same workflow will be reopened;
a domain-specific visualization reveals more than prose.

From answer-shaped output to software-shaped work

Chat should not disappear. It is flexible, forgiving, and often the fastest way to express intent. But a transcript should be one view of the work, not its only container.

The reusable idea is simple:

conversation supplies intent;
the task surface supplies structure and controls;
an owned session supplies continuity;
explicit state and host-mediated capabilities connect them.

BitFun is one current implementation of that pattern, not proof that the pattern is finished. Its public gallery is still early, which makes the source more useful than adoption claims for evaluating the architecture.

For verification rather than endorsement:

Source notes

The product-specific statements above were checked against these source locations, pinned so future changes do not silently move the evidence: