dsh-frontend-tools — turn any web/Electron/Tauri app into the agent's hands

[ludaokai]

Most agent tooling is filesystem-centric. But countless applications and systems are built on frontend technologies — places an agent cannot reach by reading and writing files.

dsh-frontend-tools flips the model: instead of granting the agent direct access to underlying data, your connected application becomes a stand-in for a human operator. The agent works through the app's own interaction entry points, exactly like a person sitting in front of the screen.

Inspired by the frontend tools of CopilotKit.

Why this matters

• Aligned authority — the agent can do exactly what a human user can, nothing more. Source-of-truth data is never accessed out-of-band.
• Intact data flow — every operation still passes through the app's original validation, linkage, and side effects.
• Preserved interaction semantics — undo stacks, optimistic updates, and other built-in mechanics keep working for the agent.

What you get

• dsh-frontend-tools-bridge — DSH plugin: runs a loopback WebSocket server inside DSH, mirrors your app's tools onto ctx.tools and forwards model calls back to the application. One bridge serves many apps at once via KEY-based namespace isolation.
• dsh-frontend-tools-client — SDK for your app: register tools, receive calls. Zero runtime dependencies beyond platform WebSocket. Works in browser, Electron, Tauri, and Node.

Quick start

1. Install the bridge plugin in DSH

dsh plugin --profile web add dsh-frontend-tools-bridge

2. Install the client SDK in your application

npm install dsh-frontend-tools-client

3. Connect your app (browser/Electron/Tauri/Node)

import { createFrontendToolsClient, generateClientKey } from 'dsh-frontend-tools-client'

const key = localStorage.getItem('dsh-key') ?? generateClientKey()
localStorage.setItem('dsh-key', key)

const client = createFrontendToolsClient({ url: 'ws://127.0.0.1:31870', key })
await client.connect()

// Register a tool
await client.registerTools([{
  name: 'get_current_page',
  description: "Get information about the current page the user is viewing.",
  parametersSchema: { type: 'object', properties: {} },
  async execute() {
    return { url: location.href, title: document.title }
  },
}])

4. Register the KEY with DSH

Display the DSH KEY to the user (use buildClientKeyClipboardText() for a ready-to-paste format), then paste it into a DSH conversation. The model calls frontend_tools_register_client to register the KEY against a namespace, and your app's tools are live in the agent's tool list.

Built-in admin tools

• frontend_tools_register_client — register a new app KEY
• frontend_tools_list_clients — list all connected apps and their tool counts
• frontend_tools_revoke_client — revoke a KEY and disconnect the app

Config

Default port: 31870. Override any config in your cordis.patch.yml:

- id: frontend-tools-bridge
  config:
    port: 31870
    callTimeoutMs: 30000
    maxTools: 200

---

中文说明

大多数 Agent 工具围绕文件系统设计，但大量应用与系统构建在前端技术上，Agent 读写文件根本触达不了。本插件把方向反过来：不把底层数据交给 Agent，而是让已连接的应用充当"人机替身"——Agent 通过应用自身的交互入口操作，就像一个坐在屏幕前的人。

• 权限对齐：Agent 能做的 = 人能做的，不多不少
• 数据流完整：所有操作照常经过应用原有的校验、联动与副作用
• 交互语义保留：撤销栈、乐观更新等机制对 Agent 依然有效

一个 bridge 同时服务多个应用（KEY 命名空间隔离），自带注册/列出/吊销三个管理工具。

---

• 📦 npm: dsh-frontend-tools-bridge · dsh-frontend-tools-client
• 📂 GitHub: https://github.com/lukaiwuyi/dsh-frontend-tools
• 📝 License: MIT
• ✅ 166 unit tests

Feedback welcome — especially on the protocol design and the KEY/namespace model!

[leenkcool]

#1728 可以自己提PR收录 。记得互相赞赏。

[ludaokai]

我再加上写入类工具进人工审批后，提一个

[leenkcool]

好的

[rohit-binaried]

The part I would test next is revocation while a request is waiting for approval: the app disconnects, its component unmounts, or the user changes workspace before approving. The original request should not silently execute against the replacement binding.

I maintain RCIP, which handles typed capabilities and live React bindings inside an application. Your bridge covers a complementary transport problem. A possible integration would project selected RCIP client capabilities into your registry and map invocation outcomes back, while keeping host approval controls inside the app. Lifecycle notes.

I have not built or tested that integration. I saw your reply about adding write approval; how are you planning to invalidate pending requests when a KEY is revoked or an app reconnects under the same namespace?