@2nd1st/dsh-plugin-open-app

dsh plugin --profile web add @2nd1st/dsh-plugin-open-app

@2nd1st/dsh-plugin-open-app





Makes every open-mcp-apps app a place you go

inside DeepSeek Harness (dsh): an Apps

section in the sidebar, one container per app with its own workspace and conversation, and

inline rendering when the model opens an app mid-chat.

Package · @2nd1st/dsh-plugin-open-app on npm — MIT ([LICENSE](LICENSE))

Install · dsh plugin --profile web add @2nd1st/dsh-plugin-open-app — one step

Requires · dsh with a web profile · pnpm on PATH (dsh plugin manages profile dependencies through it) · a running open-mcp-apps v0.5.1+ · Node 22+

Platform · dsh web (dsh web) — every surface it takes is a web slot

Releases · [CHANGELOG.md](CHANGELOG.md)

Developer preview. dsh is itself a 0.1.0-rc preview, and this plugin tracks it

closely — including six places where it reaches into dsh through no published seam (all

six are listed under [What it reaches into](#what-it-reaches-into-and-what-breaks-if-dsh-moves),

with what each degrades to). Expect breaking changes between releases, and pin a version

if you need one that holds still.

Install

# add it — this is the whole install
dsh plugin --profile web add @2nd1st/dsh-plugin-open-app

# restart; plugin metadata is cached per name for the life of the process
dsh web

The package declares dsh.bundle, so dsh plugin add does not only put it in the

profile's dependencies — it appends it to dsh.profile.bundles, and the patch it ships

becomes a layer of your profile's tree. That layer inserts two rows: open-app (this

plugin) and mcp-oma (dsh's MCP client, pointed at the same engine, so the model can open

and build apps as well as you can). Bundle layers apply below your profile's own

cordis.patch.yml, so both rows stay yours to configure or switch off.

Nothing here changes what an app is allowed to do: the engine is a local process you

started, and the rows only say where it listens.

Upgrading from a hand-written install (before 0.1.1 the second step was pasting an

- insert: block yourself): delete those blocks for open-app and mcp-oma from your

profile's cordis.patch.yml, and remove the old package name —

dsh plugin --profile web remove dsh-plugin-open-app
dsh plugin --profile web add @2nd1st/dsh-plugin-open-app

A patch insert always appends: two layers inserting the same id are two rows, and dsh

refuses to boot such a tree (duplicate loader entry id: open-app) rather than running the

plugin twice. Keep your settings as [id-targeted overrides](#configuration) instead.

Requirements

• dsh with a web profile (dsh web). Every surface this plugin takes is a web slot.
• pnpm on PATH. Not something this plugin depends on: dsh plugin is a thin forwarder

that runs pnpm in the profile directory, so this is how any dsh plugin is installed.

Without it the install command above stops at

dsh: pnpm not found on PATH — install pnpm to manage profile plugins and exits 127.

No minimum version is stated here because none has been measured.

• A running open-mcp-apps engine with its HTTP face up — node src/http.mjs, default

port 8787. The engine is a separate install (its README):

it gives a model persistent, interactive UI apps backed by durable data collections,

shared with every other host talking to the same engine. This plugin is the dsh face of them.

• Engine v0.5.1 or newer. That release carries the three seams the panel leans on:

?chrome=0 (the bare widget instead of the engine's own viewer bar), ?nav=intent

(an app→app link becomes a message to the host instead of a navigation inside the frame),

and the standalone viewer's root overflow-y:auto. Against an older engine the plugin

still works and degrades gracefully — each case is called out under

[Known limitations](#known-limitations).

• Optional, for per-app inline views: start the engine with OMA_DYNAMIC_TOOLS=1, which

is what makes it publish one open_<app> tool per app. The universal open_app tool

is always covered.

Both opt-in query parameters are additive: an engine that has not heard of either ignores

it and keeps its own behaviour. Nothing else is asked of the engine, and no dsh source is

changed — the plugin runs entirely out-of-tree.

Configuration

Every setting is optional; the defaults match a stock local engine and the mcp-oma row

the bundle ships.

Configure it from your profile's own cordis.patch.yml by naming the bundle's row id —

never by inserting the row again. An id-targeted patch replaces the key it names

rather than merging into it, so write the whole config you want:

- id: open-app
  config:
    # Where the engine's HTTP face listens.
    engineBase: 'http://127.0.0.1:8787'
    # The `serverName` of the engine's mcp-client entry. It decides the
    # `mcp__<serverName>__` prefix the inline tool views are keyed on.
    serverName: 'oma'
    # Where the per-app workspace directories are made. One directory per app,
    # named after it. Defaults to $DSH_HOME/storages/open-app/apps.
    appsRoot: '~/.dsh/storages/open-app/apps'
    # The container's rules, carried as a system-prompt section on every
    # reques

…(truncated)