DSH Visualize

What it does

DSH Visualize gives the model a way to answer with something other than text. It registers a visualize(path, title?, mode?) tool: the model writes an HTML fragment to a file, calls the tool with its path, and the DSH Web UI renders that fragment as an interactive card inline in the conversation — a simulator, a chart, a comparison panel or a UI mockup instead of another paragraph.

The package description names two moving parts: the tool itself, and a bundled skill that teaches the model how to author the fragments. The README is open about lineage — the idea follows the Codex desktop app’s /visualize, and the skill’s layered references and Chart.js-first route borrow from the generative-UI skill in himself65/finance-skills. An optional mode: "wide" spreads a card across more horizontal space for side-by-side content.

Cards follow the harness’s light/dark theme and whale-blue palette. On session replay they are restored from the persisted tool result, so the original fragment file does not need to still exist.

The sandbox model

This is the section to read before installing, and the README is unusually specific about it:

• Each card renders in a sandboxed iframe with an opaque origin, cut off from the host page.
• A Content Security Policy blocks network requests, nested pages and form submissions; the only outbound loading permitted is static assets from a fixed CDN.
• Fragments are capped at 1,000,000 bytes by default, adjustable through a maxFragmentBytes option.

Two qualifiers keep this honest. “Fixed CDN” is still a third-party network dependency — a card that pulls in Chart.js is fetching from the internet at render time, and the README neither names the CDN nor says whether the allowlist is configurable. And the sandbox describes the rendered fragment’s containment; it says nothing about what the host-side half of the plugin can read or do. That half is undocumented — treat it as such, not as safe.

Requirements

• Harness version: not declared. The manifest has no dsh.compatibility block and no engines field. Its peer dependencies ask for the ^0.1.0-rc.6 generation of the dsh platform packages (dsh-fs, dsh-llm, dsh-session, dsh-tools, dsh-skill, dsh-sandbox-policy), Cordis ^4.0.1, Schemastery ^3.18.1 and React ^18.2.0; its devDependencies pin 0.1.1-rc.2. Treat anything outside that generation as untested, not as compatible.
• Web only. The client platform is declared web and injects @deepseek-ai/dsh-client-runtime. There is no TUI or headless rendering path.
• No install-time lifecycle scripts. The package defines build, typecheck, test and check only — no preinstall/install/postinstall/prepare. The README states the build artifacts are committed to the repository, so a GitHub install needs no local build.
• Permissions and telemetry: the README documents the iframe sandbox and nothing else — no permission model, no host-side file or network behaviour, no telemetry statement. Not documented; assume undocumented rather than safe.

Known limits

• Cards render only in the Web UI. TUI and headless clients show the plain tool result, so the same request produces nothing visual there.
• Cards cannot talk back. Buttons inside a card cannot send follow-up messages into the main conversation; interaction stays inside the card.
• The byte cap is a hard ceiling on fragment size; what oversize output does beyond hitting it is not described.
• The documented configuration surface is exactly one option (maxFragmentBytes). There is no documented way to widen the CSP, change the CDN, or restyle the cards beyond the automatic light/dark following.

When to use it — and when not to

Use it when you work in DSH Web and want the model to show you the answer — a parameter-tweakable sorting visualization, a small simulator, a comparison dashboard — rather than describe one. The tool-plus-skill pairing means you ask in plain language and the fragment authoring is the model’s problem.

Do not install it if you live in the TUI or run headless: there is nothing for the cards to render into. Do not treat the sandbox as a licence to render untrusted fragments casually — the iframe containment is documented, the host half is not, and this listing’s security status is unverified. And if what you want needs arbitrary third-party scripts, live API calls or forms, the CSP blocks all of that by design; a static charting CDN is as far as cards reach.

Install

dsh plugin --profile web add github:Nagi-ovo/dsh-visualize

GitHub install only — the package manifest is marked private and the plugin is not published to npm. Build artifacts are committed, so no local build step is needed; restart dsh web if it was running and refresh the page. The README suggests dsh --profile web --dump-config to confirm the plugin reached the final config, and notes that users of the community plugin-registry can also install it from Settings → Plugins.