
omdsh-dev/dsh-custom-tool
240Last commit Aug 13, 2026
dsh-custom-tool DSH plugin
This plugin lets users create, edit, and manage custom JavaScript tools directly in the settings UI, using a Monaco editor with TypeScript intellisense. The model can also create, list, and remove tools itself via `custom_tool_create`, `custom_tools_list`, and `custom_tool_remove`. Tools execute in restricted worker threads with configurable budgets and security scopes.
How to install the dsh-custom-tool DSH plugin
dsh plugin --profile web add https://github.com/omdsh-dev/dsh-custom-tool/archive/refs/tags/v0.1.2.tar.gzCopying does not run this command. Review the repository and version before installing the dsh-custom-tool DSH plugin.
dsh-custom-tool DSH plugin data source
dsh-custom-tool DSH plugin snapshot date: Aug 16, 2026
discovered
What the dsh-custom-tool DSH plugin can do
- Settings UI with Monaco editor and TypeScript intellisense for authoring tool code
- Live registration: tools become available to the model immediately after saving
- Model self-service: the model can create, list, and remove its own tools through dedicated functions
- Durable store: tools persist across restarts via the settings namespace
- Two execution scopes: global (no filesystem access) and workspace (limited filesystem access inside the session workspace)
- Configurable execution budgets: timeout, memory, result size, code size, and tool count
Where the dsh-custom-tool DSH plugin fits
- Add custom data-fetching capabilities to the model without writing a full harness plugin
- Let the model autonomously create file-processing tools for recurring tasks within a workspace
- Quickly prototype and test new functions in the UI, then call them via the model
- Share global tools across workspaces, while workspace-specific tools remain isolated
Who the dsh-custom-tool DSH plugin is for
- DSH users who want to extend the model's capabilities with custom code
- Developers who need a low-friction way to add and manage tools without modifying the harness
dsh-custom-tool DSH plugin limitations
- Custom tool names cannot shadow tools owned by other packages; collisions surface as registration failures
- Workspace confinement is lexical, not symlink-proof – a symlink inside the workspace could point outside the root
- No per-tool test-run button in the UI yet; tools must be exercised through model calls or headless runs
- Requires the harness web configuration namespace allowlist to include 'custom-tools' for the UI to save settings
dsh-custom-tool DSH plugin: from the repository README
Quoted from the omdsh-dev/dsh-custom-tool README, the upstream source of the dsh-custom-tool DSH plugin. Copyright remains with the original authors.
Custom tools for the DeepSeek Harness: users author their own JavaScript tools in the settings UI with a Monaco (VS Code) editor and TypeScript intellisense, and the model grows and prunes the same toolset itself through `custom_tool_create` / `custom_tool_remove` / `custom_tools_list`. Every tool is durable, hot-registered, and written into the model prompt on the next step.   ## Problems it solves - **Users cannot extend their agent**: before this plugin, adding a capability meant shipping a harness package. Now a tool is a form in the settings UI — name, description, parameters, code — saved live and callable by the model immediately. - **The model cannot grow itself**: `custom_tool_create` lets the model persist tools mid-session (hot-registered, visible on its next step), with the same validation gate the UI uses — the model cannot persist anything the settings UI would refuse. - **User-authored code runs in a restricted worker**: every call executes in a fresh worker thread inside a `node:vm` realm with an explicit allowlist, Node Permission Model
Read the full READMERepository license: MIT
dsh-custom-tool DSH plugin questions
How do I install the custom tool plugin?
Run `dsh plugin --profile web add https://github.com/omdsh-dev/dsh-custom-tool/archive/refs/tags/v0.1.2.tar.gz` and then restart the server with `dsh web`. The plugin will be available after restart.
Can the model create tools on its own?
Yes, the model can call `custom_tool_create` to create new tools, `custom_tools_list` to list them, and `custom_tool_remove` to delete them. However, creating a global-location tool requires user approval via a GUI prompt. The model cannot remove user-created tools.
What security restrictions are applied to custom tool code?
Each tool runs in a fresh worker thread inside a `node:vm` realm with an explicit allowlist, Node Permission Model, and hard budgets. There is no filesystem access in the global scope, and workspace scope has limited read/write access confined to the session workspace root. Network access is controlled by the `allowNetwork` configuration.
How do I configure the execution budgets for custom tools?
You can set `timeoutMs`, `memoryLimitMb`, `maxResultChars`, `maxCodeBytes`, `maxTools`, and `allowNetwork` in the `cordis.yml` config file under the `dsh-custom-tool` entry. Defaults are provided for each field.
Why are my tools not saving in the UI?
Check that the harness web configuration namespace allowlist includes `'custom-tools'` in `packages/host/apiproxy/src/api-proxy.ts`. Without this, the UI will render but saves will be silently refused.