@local/dsh-image
通过兼容 OpenAI 的中继为 DeepSeek Harness 生成图像，并同时提供斜杠命令和智能体工具。
插件会安装到这里；不确定时保持 web。
npx -y @deepseek-ai/dsh plugin --profile web add github:merlotqi/dsh-image#68e1df7f68ef26a63a94c28b365ef66da927bc4cImage 以 @local/dsh-image 发布，当前版本为 0.2.0。Plugin Hub 会校验它的 manifest，并保存精确安装来源，便于复现安装结果。
Image generation for DeepSeek Harness through an OpenAI-compatible relay
(configured for api.ykh.ai / gpt-image-2).
No dependencies, no build step.
| Surface | Name | Started by |
|---|---|---|
| Slash command | /image <prompt> | you |
| Agent tool | generate_image | the model |
Both call one shared operation (lib/generate.js), per DSH's guidance for
user actions and agent tools: "Do not maintain separate operation logic in the
UI and tool paths."
The command's result is UI-side and never enters model history, so /image
costs no tokens. The tool's result does enter the conversation, which is what
lets the model show the picture and keep working.
Install with
file:, notlink:. This is the one thing that will silently break the plugin.
dsh plugin --profile <profile> add file:C:/abs/path/to/dsh-image
Restart DSH once. Then / lists image, and the next agent gets
generate_image.
file: and not link:A link:ed package resolves its own imports from the link target's real
path. When that path is outside the profile — a workspace, say — the host's
installation-scope resolver does not cover it, so every bare @deepseek-ai/*
import fails and the entry is dropped with:
dsh: warning: 1 entry did not activate
dsh-image (@local/dsh-image): failed to import
That message is a bare literal the loader emits when no fiber could be created,
and nothing else reports it: --dump-config only composes (it never imports),
and the plugin market reads composition state, not load outcomes. So the
failure is completely silent in the UI.
file: installs a real copy inside the profile, where those packages resolve.
(The zero-dependency plugins that get away with link: do so by importing
nothing but node:* builtins.)
file: is a copy, so the installed plugin does not follow your edits:
dsh plugin --profile <profile> remove @local/dsh-image
dsh plugin --profile <profile> add file:C:/abs/path/to/dsh-image
Re-running only add may be reported as "Already up to date" and skip the copy,
so remove first.
The config holds only the name of a credential reference. The value is resolved per operation through DSH's credential service, so rotating the key never needs a restart. Resolution order (fixed by DSH, highest wins):
~/.dsh/.credentials.yaml<project>/.env, then $DSH_HOME/.envTo set it persistently, add it to ~/.dsh/.credentials.yaml — the store reloads
on change:
version: 1
refs:
YKH_API_KEY: <your key>
Two things that quietly produce "no key":
YKH_API_KEY: with nothing after it) — DSH treats a blank
as absent, and also lists empty values among the things it refuses;YKH_API_KEY:sk-… is parsed as one plain
string, not a mapping).The key is never written into this plugin's config, never logged, and never sent anywhere except the configured relay.
Caveat, from DSH's own documentation: the shipped credential provider is file-backed, and file permissions cannot keep a key away from the agent — the agent's tool processes run as your OS user. A keyring or KMS provider exists only as an unimplemented seam. If that matters, do not put the key in the credential file.
Change these in the profile patch, not in code — the user's patch layer survives upgrades:
- id: dsh-image
name: '@local/dsh-image'
config:
baseUrl: https://api.ykh.ai/v1
model: gpt-image-2
apiKeyRef: YKH_API_KEY
defaultSize: 1024x1024
requestTimeoutMs: 180000
outputDir: images
baseUrl is everything up to but not including /images/generations, so
switching relays is a config edit.
The relay's response format is not assumed. The client branches on the
content-type and handles all three shapes seen in the wild:
| Shape | Handling |
|---|---|
raw bytes, image/* | written straight to disk |
JSON data[0].b64_json | base64-decoded (OpenAI's own behaviour for gpt-image) |
JSON data[0].url | downloaded, then written |
The shape actually used is reported in the tool result, the log line and the
command summary, so a first run resolves the question instead of us guessing.
test/relay.test.mjs covers all three plus the failure modes.
Images are written to <session workspace>/<outputDir>/<timestamp>-<slug>.<ext>.
Two paths are reported:
path — absolute, for tools that need a real filesystem pathrelPath — workspace-relative with forward slashes, for markdown
An absolute Windows path in a markdown image reference is both an escape hazard and unresolvable by the transcript's loader, which resolves against the session workspace.
index.js wiring: identity, config schema, caller registration
client.js browser half: the command row's label/description/icon
lib/generate.js the one operation both callers use
lib/command.js /image adapter
lib/tool.js generate_image adapter
lib/relay.js HTTP client (three response shapes)
lib/credentials.js API-key resolution
lib/config.js defaults + the config merge
lib/context.js service lookup helper
lib/errors.js error type + logging
test/relay.test.mjs relay tests (stubbed fetch; no host, no network, no key)
Run the tests:
npm test # node --test test/
node test/relay.test.mjs # same tests, in-process
/ entry works from the host-side registration
alone (input.hint makes it a leadingInput command). client.js is plain
hand-written JS in the shape DSH's module loader expects — there is no
rolldown/tsdown build step.tools/pre-execute
listener returning ask; that belongs on model-initiated calls.data[0] only.