Introduction¶

When running a Worktree Session in DSH (DeepSeek Harness), if the worktree is not local but on a remote machine, clicking “Open in Editor” often yields only a local vscode://file/ link. After opening it in a browser or editor, the worktree cannot be accessed at all. The mismatch between the local and remote paths renders this action useless. The plugin introduced below, dsh-cockpit-worktree-open-shim, is designed to plug this gap. It does not actually open the editor; instead, it performs a deployment-side adaptation: it registers the remote editor capabilities provided by dsh-cockpit-bridge into the generic open-behaviour extension point of dsh-worktree-session. This ensures the “open” action lands on the correct machine rather than falling back to a local URI.

What is this¶

A deployment-side adapter (deployment-local adapter). The maintainer is prgrmrwy. The source code is hosted at ohmydsh’s packages/cockpit-worktree-open-shim. The dsh-cockpit-worktree-open-shim repository is the release mirror, licensed under MIT, with the current version 0.1.0. The connection problem it solves can be illustrated as follows:

dsh-cockpit-bridge ──provide──▶ shim ──register──▶ dsh-worktree-session
  不知道 ws 的存在                      不知道 cockpit 的存在

The two ends do not reference each other; coupling exists only in this shim. This guarantees that both sides can be upgraded independently, or the shim can be removed entirely.

Core Features¶

It does one thing only: observe at runtime whether the two services are present; if so, forward the absolute path of the worktree to the bridge as-is.

1. No top-level inject; it listens for the loading and unloading of the two services at runtime, so the loading order is unrestricted.
2. Reads the bridge service via the full dotted name: ctx.get('cockpitBridge.editorOpen'); syntax like ctx.get('cockpitBridge').editorOpen is prohibited.
3. Only forwards the absolute path of the worktree, without validation, rewriting, state saving, or retries.
4. When either end is missing or not loaded, the shim is in an inert state, and the Worktree Session automatically falls back to the default vscode://file/ behavior.

The two interfaces it connects to are the cockpitBridge.editorOpen service of dsh-cockpit-bridge and the worktreeSession.openHandler extension point of dsh-worktree-session.

Installation and Activation¶

The installation commands come from the README. It requires installing both ends: dsh-cockpit-bridge >= 0.4.0 (distributed as GitHub Release tarball) and dsh-worktree-session. The example below is from the README, with the bridge fixed at 0.6.4.

dsh plugin --profile web add https://github.com/prgrmrwy/dsh-cockpit/releases/download/dsh-cockpit-bridge-v0.6.4/dsh-cockpit-bridge-0.6.4.tgz
dsh plugin --profile web add dsh-cockpit-worktree-open-shim

Restart the DSH web to take effect after installation. To uninstall, use the corresponding command:

dsh plugin --profile web remove dsh-cockpit-worktree-open-shim

Typical Usage¶

After installation, it works without additional configuration. When clicking “Open in Editor” in the Worktree Session, what actually happens is:

1. Worktree Session calls its own side’s open-handler extension point;
2. The shim receives the absolute path of the worktree;
3. The shim passes the path to the cockpitBridge.editorOpen service, which launches VS Code on the remote machine.

To remove it during a downtime, follow the steps in the README: delete or disable cockpit-worktree-open-shim in dsh.yaml, run dsh build, and then restart the DSH web. After removal:

• Worktree Session reverts to the default vscode://file/ behavior;
• Existing dsh-cockpit-bridge capabilities (such as session read-confirmation, pending snapshot) are unaffected;
• Neither side requires any source code or configuration migration.

Use Cases and Notes¶

Suitable for deployments that are already using the dsh-cockpit remote editor and also using Worktree Session. This step only makes sense after both sides are installed; if only one is used, it can be skipped for now.

Points to note:

1. Runtime permissions are equivalent to the current DSH process; check the source code and license yourself before installation.
2. The bridge version needs to be >= 0.4.0; this repository currently fixes it at 0.6.4. If the version is too low, the service is not provided, and the shim will silently do nothing without throwing an error.
3. VS Code Remote-SSH must be installed on the host machine, and it must be able to connect to the target device via the SSH config alias registered by the Cockpit device.
4. Without Remote-SSH, the URI may be silently dropped; if the directory name contains dots, it might be treated as a file by VS Code’s URI handler.

Conclusion¶

The value of this plugin lies in “no guessing, no overstepping boundaries”: it only performs one path forwarding to integrate remote editor capabilities into the generic open-handler, without perceiving the existence of either side in normal operation. When you no longer need the dsh-cockpit remote editor, or when one of the sides natively implements this integration, simply remove it; there is no migration burden left.

Directory: https://www.skillhub.cn/plugins/prgrmrwy/dsh-cockpit-worktree-open-shim
GitHub: https://github.com/prgrmrwy/dsh-cockpit-worktree-open-shim