omdsh-remdev

DeepSeek Harness Web GUI was always a single-machine tool: file browsing, terminals, Code mode, Work mode, conversations and agents all run locally. The moment your real development target is a cluster node, a server behind a jump host, or any headless internal machine, the workaround is fragile: hand-roll an SSH tunnel, install dependencies on the far end, then somehow point Harness at it. omdsh-remdev collapses that ritual into one button (or one keyboard chord) at the tail of the Workspaces bar. Pick a host, pick a folder, done. The plugin installs the Harness on the target if it is missing, pushes a vendored Node and pnpm over SFTP when the server cannot reach nodejs.org, and probes for the correct login shell so that PATH is whatever a human would see at a real TTY. What comes back is an ordinary workspace wearing a globe badge: files, terminals, Code, Work, conversations and skills all execute on the remote machine, while the local side holds nothing but an empty mirror directory as an anchor. Nothing in the local workflow changes.

A few design choices deserve a closer look. To the Harness, a remote workspace is just a real directory under $DSH_HOME/remotes/hostname/, which means the session store, registry, projections and usage roll-up all aggregate on that path with zero special-case branching. omdsh-sidepanel and omdsh-codemode each gained one structural view and one branch; neither imports a value from this package and neither knows what SSH is. The entire seam is a single remoteFor(cwd) query. Project skills (.dsh/skills and .agents/skills) are read back over SFTP into the harness Skills service, parsed with the harness own frontmatter grammar, with directory bundles and flat Markdown treated identically; an unreachable server simply contributes no skills and local ~/.dsh/skills stay intact. The terminal application (default @omdsh-plugins/omdsh-tui-app) is provisioned alongside Node and pnpm on first connect, so there is no separate button or profile to remember.

Who it is for: engineers whose primary work target is a remote machine—internal GPU clusters, shared build nodes, development boxes behind firewalls. You do not need to abandon your local setup, memorise tunnel commands, or context-switch between VS Code Remote and the Harness GUI. Connect once and the workspace sits in the sidebar, ready to resume whenever you come back. Without the plugin, without a remote workspace, the Harness resolves no extra service and leaves no trace.