omdsh-remctrl

omdsh-remctrl

English | 中文

Remote control for the DeepSeek Harness:
turn it on and this machine's own dsh window appears at a public address, behind
a passcode. Not a companion app and not a subset — the same sessions, the same
buttons, the same everything, because it is dsh, forwarded.

What it adds

Surface	Where it comes from
A second listener, in front of the harness's own	A node:http server this plugin binds; the harness's webServer never moves
The whole interface, at a public address	An HTTP and WebSocket reverse proxy to 127.0.0.1:<webServer.port>
A passcode form at any path	The gate's own page, served in place of the app until a browser signs in
A session cookie	HttpOnly; SameSite=Lax, Secure under the tunnel; the only credential a foreign web app carries by itself
An https:// address with no setup	A supervised cloudflared quick tunnel, spawned as a child process
One card in the Plugin hub	An entry in omdsh.plugin.card, @omdsh-plugins/omdsh-plughub's slot
The switch, the passcode, the browser list, the door's log	ctx.connection.rpc at authority: 'loopback'

One way in

There is a single door and it is a reverse proxy. Requests arrive on a port this
plugin binds, the passcode decides whether they go any further, and the ones that
do are handed to the harness's own loopback port — HTTP and both WebSocket
downlinks, verbatim.

How that port becomes reachable is the only choice you have, and it has a
default:

• Leave publicHost empty. cloudflared opens an outbound quick tunnel and
  hands back an https://….trycloudflare.com name. Nothing to forward, no
  firewall to open, no certificate to arrange. This is the case for every laptop,
  and it is what happens if you change nothing but the switch.
• Set publicHost when this machine already has a public address —
  121.43.252.12, harness.example.com. The door binds every interface and
  people reach it directly. That is plain HTTP, so it stays shut until you set
  allowInsecure by hand.

Nothing else is configurable, because nothing else needs to be.

What the passcode is holding

Everything.

An earlier version of this plugin served a small purpose-built app through a
method allowlist, at a tier the desktop chose, and could honestly say a phone was
less powerful than the desktop. Forwarding the real interface ends that promise,
and ends it deliberately: the proxy rewrites the Host header to loopback, which
is what makes the harness's own trust fence pass, and which means a signed-in
browser reaches every loopback-fenced method the desktop can — settings,
credentials, tool approvals, a shell.

So the controls around the passcode are not features. They are the design:

1. Off by default. enabled is false. Installing this plugin changes
   nothing about the machine until somebody opens its card and turns it on.
2. Nothing is forwarded before the cookie resolves. Not the index, not an
   asset, not a WebSocket handshake. A signed-out browser reaches the passcode
   form and two files, and that is the whole of the public surface.
3. Six tries a minute, per address. A ten-character passcode is fifty bits,
   which is not a key — it is a passcode with a token bucket in front of it, and
   the bucket is what makes ten characters enough to type on a phone.
4. The provenance fence, re-imposed at the public boundary. The harness
   refuses cross-site requests and mismatched Origins, and rewriting Host
   upstream would remove its copy of that check — so the gate asks the same three
   questions first, about the address the browser actually used.
5. A transport check. Under the tunnel a request that did not arrive over
   HTTPS is refused with 421 before a credential is read off it, so a
   misconfigured carrier is one refusal rather than a session cookie in the clear.

A sixth thing follows from the shape rather than being added to it: the controls
ride ctx.connection.rpc at authority: 'loopback', so they are the harness's
fence and not one written here. That fence now admits a signed-in browser too —
by design, and it cuts the useful way as often as not, because you can turn
remote control off from the phone you left the building with.

Signing in

The card shows three things: the address, a link with the passcode already on it,
and the passcode itself.

Send the link to your phone and tap it. The gate takes the passcode off the
query, sets the cookie, and redirects to the same URL without it — so it is gone
from the address bar, though not from that browser's history, which is what a
magic link costs. Type the passcode instead if you would rather; case does not
matter and neither do dashes, and the alphabet has no I, L, O or U in it
so nothing is ambiguous on a screen.

A browser stays signed in for sessionTtlDays. The card lists every one that is,
signs any of them out at once, and signs out all of them together behind a
two-step confirmation. Minting a new passcode changes only the way
in — browsers already signed in stay signed in, because a passcode read over
your shoulder and a phone left in a taxi are different problems with different
answers.

What happened at the door

The card keeps a log of it: every sign-in that worked, and every one that did
not, with the address it came from. A grant also prints a line the moment it
happens — a new browser signed in — iPhone from 203.0.113.9 — so a terminal
that is open says it out loud.

A record rather than a notification, and the distinction is the point: a
notification reaches whoever is looking, and the case worth catching is the one
nobody was looking at. The log survives a restart, holds the last 50 events, and
carries a count of what is new since you last read it.

Failed attempts from one address fold into a single row with a count on it —
otherwise a machine grinding at the passcode, throttled to six a minute, would
still push every real event out of a bounded log inside ten minutes. Nothing is
said out loud until the sixth failure from an address, which is the point at
which it stops looking like somebody mistyping and its throttle budget is spent.

The log can be cleared, and clearing it leaves one row saying so. Anyone who
can sign in can clear it — it is behind the same passcode as everything else —
so the question is not whether an intruder can erase their tracks but whether
the erasure is visible. One row naming the time and the count costs nothing and
is what keeps a wiped log from looking exactly like a log where nothing ever
happened.

On a phone

The harness's interface has no width media query anywhere in it. What it does
have is one breakpoint in JavaScript: below 1024px it collapses the sidebar to a
56px rail, so a phone already gets a rail plus a conversation rather than three
columns fighting over 390px.

Two things it does not handle, and this plugin adds both — to the forwarded copy
only, never to the window on your desk:

• The keyboard. The harness sizes itself at height: 100%, which on iOS
  resolves against the layout viewport — and the layout viewport does not shrink
  when the on-screen keyboard appears, so the composer ends up behind it with no
  page scroll to reach it. A few lines of script publish visualViewport as a
  custom property and the app is sized from that instead.
• The expanded sidebar. Tapping the rail re-expands it to 280px and leaves
  the conversation about 110px wide. On a narrow viewport it overlays the
  conversation instead of taking a track from it.

Both hang off data-shell-overlay and data-sidebar-collapsed, the two
attributes the harness's frame writes deliberately — never a CSS-module class,
every one of which is a build hash. A harness that stopped writing them leaves
the page exactly as it ships rather than broken.

Configuration

Everything lives in the omdsh-remctrl settings namespace, and the card in the
Plugin hub is the form for it. Five fields, of which most people touch one.

Field	Default	What it is
enabled	false	The switch. Nothing listens until it is on.
publicHost	''	The address people reach this machine at, if it has one. Empty means cloudflared fetches one. No scheme, no port.
port	3081	The port the door listens on — not the harness's own.
allowInsecure	false	Serve a publicHost over plain HTTP. Required before one will open at all.
sessionTtlDays	30	How long a signed-in browser stays signed in. 0 means forever.

Three more are written by the plugin: passcode, minted the first time you turn
it on and declared .role('secret'); browsers, which holds a hash of each
session token and never a token; and access, the door's log.

Install

npx @omdsh-plugins/omdsh-plughub add omdsh-remctrl

That is the plugin hub's own
installer with argv instead of a button. It resolves this plugin through the
collection's registry, installs it
from its GitHub repository, and writes the pnpm build-allowlist entry — which a
bare dsh plugin add github:… leaves to you, and which carries a commit hash
pnpm resolves, so it can only be copied out of an error message afterwards.

dsh plugin --profile web add @omdsh-plugins/omdsh-remctrl is not that
command yet: this package is not on npm, and pnpm answers
ERR_PNPM_FETCH_404. The same install is also a button, on this plugin's card
under Settings → Plugins → Plugin hub, whenever the hub is already in the
profile.

Or from a checkout, which is what an unpublished build wants:

pnpm install && pnpm run build
dsh plugin --profile web add "$PWD"

Remove it the same way:

dsh plugin --profile web remove @omdsh-plugins/omdsh-remctrl

cloudflared is not bundled and is not installed for you. On macOS:
brew install cloudflared; otherwise see
Cloudflare's downloads.
The card says so when it is missing, and a machine with a publicHost never
needs it.

The off states, per CONVENTIONS rule 9. Without
@omdsh-plugins/omdsh-plughub the card has no slot to sit in and withdraws;
every value stays editable through the hub's generic form or the settings file.
Without a webServer — a TUI profile — there is no interface to forward, and the
plugin says so instead of opening a door onto nothing. Without settings the
passcode and the signed-in browsers live in memory until restart. A remove
leaves the settings section behind, so reinstalling keeps the passcode.

Commands

pnpm install
pnpm run build        # tsdown bundles the host and browser halves
pnpm run typecheck
pnpm run test
pnpm run harness:local   # point the harness dependencies at a local checkout
pnpm run harness:npm     # point them back at the published versions
pnpm run check:harness-pin

Known limitations

• A signed-in browser is the desktop. There are no tiers and no read-only
  mode. That is what forwarding the real interface means, and it is why the
  passcode is the whole of the security.
• A quick tunnel's hostname changes on every restart. Cloudflare's
  account-less tunnels are ephemeral and carry no uptime guarantee, so the card
  shows the current address rather than a saved one, and a link you sent
  yesterday will not work today. A named tunnel is not supported yet.
• Everything crosses Cloudflare. Under the default carrier the TLS is
  theirs, so the traffic is in the clear on their side of it. publicHost with
  your own reverse proxy in front is the answer if that matters.
• The details pane is unreachable on a phone. The harness's column solver
  closes it whenever the conversation would fall below 640px, which is always on
  a phone, and nothing in the forwarded DOM distinguishes "closed because it
  does not fit" from "closed because you closed it".
• The phone stylesheet is unverified on hardware. It is written from the
  harness's own layout source and covered by tests that read it, not by a device.
• One tunnel, one door. Two harnesses on one machine need two ports, set by
  hand; nothing here discovers a free one.