dsh-editor-link

dsh-editor-link

English | 中文

Using DSH today means living in two windows: the DSH web UI and VS Code. The ecosystem has fragments — a selection inserter, a file jumper, an ACP bridge — but nobody covers the two highest-frequency actions: answering approvals where you already are, and giving the agent the editor context that Claude Code users take for granted.

dsh-editor-link is one product with two halves — a DSH plugin and a VS Code extension — talking over a token-authenticated loopback JSON-RPC channel.

📑 Table of Contents

• ✨ Features
• 🚀 Install
• ⌨️ Usage
• ⚙️ Commands
• 🔌 Host routes
• 🧩 How it works
• 🛠️ Development
• 🔐 Security and cost
• ⚠️ Known limitations
• 📄 License

✨ Features

• Approvals in VS Code — a tool call needs permission and a native VS Code notification offers Allow once / Reject. No Alt-Tab.
• Questions in the sidebar — ask_user_question renders as a card in the sidebar: click to answer single-select, tick and submit for multi-select, or type a custom answer. No QuickPick pops up outside the sidebar.
• Editor context for the agent — the ide_context tool reads the active file, its diagnostics (file:line:col), and the current selection.
• Selection to composer — DSH Link: Send Selection to Composer drops path:lines plus a fenced block into the DSH composer.
• Jump to what the agent touched — a status-bar item opens the last file the agent read or wrote at its line, and file tool cards in the web UI grow a small ↗ button that does the same.
• Sidebar panel — an activity-bar view with the live transcript, inline approvals, and a composer that sends, steers, or stops a turn.
• Session picker that follows your folder — sessions are grouped by DSH workspace and scoped to the VS Code folder; archived and blank sessions stay hidden; switching folders re-scopes the list.
• Model, effort, and permission pickers — switch the session's model, reasoning effort, and permission preset without opening the web UI.
• Prompt completion — when a turn ends, the composer predicts your next message; typing cancels it, Tab accepts, ↻ rerolls, Esc dismisses.
• Full DSH in a tab — open the complete web UI inside VS Code with the authenticated URL already applied.

Both surfaces stay live: approvals and questions also appear in the web UI, and whichever you answer first wins — late answers are refused with an explicit error.

🚀 Install

1. Install the DSH plugin (recommended)

The plugin half runs inside DSH and publishes this package to npm.

• GUI: Plugins → Add plugin → paste dsh-editor-link → install.
• CLI: dsh plugin --profile desktop add dsh-editor-link

The CLI only installs the package. It does not register the profile bundle, so the plugin stays unloaded until dsh-editor-link is appended to dsh.profile.bundles in ~/.dsh/profiles/<profile>/package.json. The GUI does that step for you.

2. Install the VS Code extension

Install from the VS Code Marketplace:

code --install-extension ferrisching.dsh-link

Or, offline, download dsh-editor-link-extension-<version>.vsix from Releases and run code --install-extension <file>.vsix --force.

Then reload the VS Code window. The DSH view appears in the activity bar.

3. From source

git clone https://github.com/ferrisching/dsh-editor-link
cd dsh-editor-link
npm install                       # plugin tests (linkedom)
cd extension && npm install       # extension build (esbuild, @types/vscode)

Requirements

⌨️ Usage

1. Start DSH. The bridge connects on its own; the status-bar item appears the first time the agent touches a file.
2. Open the DSH view in the VS Code activity bar. Sessions load for the DSH workspace that contains your VS Code folder.
3. Ask something in the composer. When a tool needs permission, answer it in the notification — the web UI card disappears at the same time.
4. Mention "@ the file I'm looking at" and the agent gets it through ide_context; select code and run Send Selection to Composer to hand over an excerpt instead.

⚙️ Commands

The sidebar toolbar also exposes model, reasoning effort, permission preset, a + menu (/goal, /plan, /feedback, /compact, /export plus a file picker and the permission/model pickers), and the send/stop control.

🔌 Host routes

🧩 How it works

• Host plugin (lib/) opens a loopback TCP listener on ports 7410–7419 and writes a discovery file (~/.dsh/editor-link/<pid>.json, mode 0600) carrying the port and a token.
• VS Code extension (extension/) reads the discovery file, keeps one JSON-RPC 2.0 connection per DSH process and multiplexes every call over it, and answers the approval/request and user-questions/request waterfalls from native UI.
• Browser half (client/) subscribes to /editor-link/events and decorates file tool cards; the extension calls back through the host when a card button is clicked.
• Approvals race all surfaces. The first answer wins; later answers are rejected with -32002 instead of silently succeeding.

🛠️ Development

.
├── lib/                  host plugin (bridge, forwarding, panel RPC, ide capture)
├── client/               web UI half (SSE listener, tool-card buttons)
├── cordis.patch.yml      bundle patch — required for `dsh plugin add`
├── test/                 node:test suites (81 cases)
├── extension/            VS Code extension (TypeScript + esbuild)
│   ├── src/              extension host and sidebar webview
│   └── test/             runtime smoke test (vm.Script parse + linkedom DOM)
├── scripts/              real-cordis integration harness
└── docs/                 design notes, verified seams, verification log

npm test                 # plugin suites
npm run test:extension   # build + extension smoke test
DSH_BUNDLE_DIR=/path/to/dsh node scripts/integration-cordis.mjs   # real cordis harness

🔐 Security and cost

• The bridge listens on loopback only, requires the token from the discovery file on every request, and rotates when DSH restarts.
• No telemetry, no outbound network calls, no credentials stored in the repository or the discovery file beyond the per-process token.
• Prompt completion and session titles spend model tokens: completion pins the shallowest reasoning effort the model advertises and caps the reply at 80 tokens.

⚠️ Known limitations

• Multiple VS Code windows on one host are untested.
• With more than one DSH process running, requests go to the instance that connected first: the session list, approvals and questions all belong to it. There is no per-session routing between hosts yet.
• A question answered in VS Code stays visible in the DSH web/desktop client as a reply card until it is dismissed there. The answer itself is recorded — the tool result and the session projection both settle — but the client only closes its own card when that client submits the answer.
• Windows and WSL paths are untested; the discovery and path logic assume POSIX paths.
• The SSE route is loopback-only and unauthenticated; it carries no secrets but is not suitable for exposing.
• Verification targets DSH 0.2.0-rc.2, 0.2.1-rc.1 and 0.2.1-rc.2; other versions may move the seams this plugin relies on.

📄 License

MIT — see LICENSE.