@orbisapp/remote-dsh

dsh plugin --profile web add @orbisapp/remote-dsh

Orbis DSH Remote

@orbisapp/remote-dsh is the DeepSeek Harness Web bundle for the Orbis remote

DSH host. It lives entirely in this repository, does not modify the DeepSeek

Harness source tree, and contains the DSH adapter, remote host composition,

plugin lifecycle, and Web settings client as internal modules of one package.

The bundle adds Settings → Plugins → Orbis to DSH Web. It owns pairing, trusted

devices, DSH-registered workspace access, and the dedicated Orbis listener.

It attaches each accepted transport connection to OrbisRemoteDshHost; v2

methods become reachable only after the peer completes the orbis.hello

handshake. The host advertises the canonical v2 protocol rather than legacy

dsh.* methods or raw DSH events:

• orbis.models.list, orbis.sessions.list, orbis.sessions.create,

orbis.sessions.sync, orbis.sessions.entries,

orbis.sessions.prompt, orbis.sessions.update, and orbis.sessions.cancel;

• replayable terminal entry.appended events with host-assigned cursors,

transient deltas, and ordered session-state updates;

• DSH sessionPersistence for catalog identity and sessionQuery.observeSession

for consistent live/cold history and native projection state, with the node state storing only host identity, cursor indexes,

and idempotency claims. There is no host transcript copy, ACK journal, or

retention overlay.

Plan, goal, todos, and inbox state use native DSH projections. The plugin keeps

plan/todo read units registered on the host so a cold read works before a Web

preset opens an Agent. Todo's native plugin runs with private tool and prompt

services; preset tools and policies keep their own ownership. Orbis retains only

its enqueue timestamps, next_run queue, and protocol revisions. Observation

leases are released after each read, and projection-only reads never expand the

transcript.

The initial release supports two automatically discovered connection paths:

• LAN: private IPv4 addresses are discovered automatically on the standalone

WebSocket listener (default port 47000).

• Tailnet: Tailscale-style CGNAT IPv4 addresses are discovered automatically

on that same listener.

Both paths carry the same authenticated encrypted protocol. Pairing uses one

available address. After authenticating the host, the encrypted welcome

publishes the current LAN and Tailnet addresses.

Direct ws:// invitations are restricted to private/LAN, loopback, .local,

or Tailscale-style CGNAT addresses. A public direct endpoint must use WSS; the

bundle does not expose DSH Web as a remote endpoint and does not perform NAT

traversal.

When DSH runs inside WSL, the settings page reports the Windows/WSL host environment and detected

WSL networking mode. Follow the [WSL connection setup](docs/wsl-setup.md) to make the listener

reachable through mirrored networking or Tailscale.

Local installation

cd public
pnpm install
pnpm run serve:dsh

The public workspace uses pnpm for every package. The public DSH SDK is used as

the build-time development dependency, while the generated plugin keeps DSH

imports external and receives the matching peer packages from the selected DSH

profile at runtime. The shared Orbis protocol packages are workspace

dependencies and are bundled into the plugin at build time. No DSH source

checkout is needed for a normal build or local Web run.

For the individual steps, run them from public/:

pnpm --filter @orbisapp/remote-dsh run build
pnpm --filter @orbisapp/remote-dsh exec dsh plugin --profile web add "@orbisapp/remote-dsh@link:$PWD/packages/orbis-remote-dsh"
DSH_TELEMETRY_DISABLED=1 pnpm --filter @orbisapp/remote-dsh exec dsh web

Adapter and host production code use structural ports. Their tests use native

DSH projection definitions so fixtures follow upstream domain behavior:

pnpm --filter @orbisapp/remote-dsh run check:core

For a local smoke check before installing the profile link:

pnpm install
pnpm --filter @orbisapp/remote-dsh run check
pnpm --filter @orbisapp/remote-dsh exec dsh plugin --profile web add "@orbisapp/remote-dsh@link:$PWD/packages/orbis-remote-dsh"
pnpm --filter @orbisapp/remote-dsh exec dsh plugin --profile web why @orbisapp/remote-dsh

The package also provides a one-command local Web launcher. It installs and builds

the bundle, installs it into the persistent DSH web profile, prints the active

profile dependency, and starts DSH Web on 127.0.0.1:3080:

pnpm run serve:dsh

The launcher reuses ~/.dsh/profiles/web and creates the workspace root in a

disposable temporary directory. It uses the package-local public DSH CLI by default.

Use --dsh to select a local Harness checkout, an exact GitHub tag or commit, or an

npm dist-tag/exact version:

pnpm run serve:dsh --dsh local:/path/to/deepseek-harness
pnpm run serve:dsh --dsh github:tag:dsh-v0.2.0-rc.2
pnpm run serve:dsh --dsh github:commit:a66e4702047846cdaa10c66c9d3df3951f5ea70d
pnpm run serve:dsh --dsh npm:latest
pnpm run serve:dsh --dsh-bin /path/to/dsh
pnpm run serve:dsh --port 3090 --keep
pnpm run serve:dsh --home "$DSH_HOME"
pnpm run serve:dsh --workspace-root /path/to/workspace

local: and both github: selectors run the selected checkout's frozen pnpm

install and full build before starting the resulting CLI. GitHub checkouts are

temporary and detached at the requested tag or commit. npm: installs the resolved

@deepseek-ai/dsh release into an isolated temporary directory, so selecting a DSH

does not rewrite this workspace's dependencies. --keep retains generated DSH

checkouts/installations as well as the temporary workspace. ORBIS_DSH accepts the

same selector syntax; ORBIS_DSH_BIN remains the executable override.

Selecting a source does not add cross-release compatibility behavior: the selected

DSH must satisfy the plugin's current peer and runtime contract.

Before refreshing the local plugin link, the launcher runs the active pnpm in

the existing

…(truncated)