dsh-keyword-injector
DSH 的上下文注入与行为防护：基于用户输入或代理活动的关键词触发器、工具窗口防护，以及可由代理管理的触发工具。功能强大且危险：允许 AI 代理在任意步骤影响彼此的行为——请阅读警告 b
插件会安装到这里；不确定时保持 web。
npx -y @deepseek-ai/dsh plugin --profile web add dsh-keyword-injector@0.6.0Keyword Injector 以 dsh-keyword-injector 发布，当前版本为 0.6.0。Plugin Hub 会校验它的 manifest，并保存精确安装来源，便于复现安装结果。
Keyword-triggered context injection for the DeepSeek Harness (DSH).
Define keywords once; the plugin watches a session and, when a trigger fires, injects your payload into the conversation as a Context injection message — the same delivery surface memos-local-memory uses. The reminder renders in the Web GUI as a collapsed Context injection · dsh-keyword-injector row and reaches the model with its next request. The agent's flow is never interrupted: no turns are started, nothing is steered, no extra model calls are made for the delivery itself.
user: "please deploy to staging now"
└─ Context injection · dsh-keyword-injector ← collapsed row, model sees it too
[KEYWORD-INJECTOR REMINDER] …rules you configured… [END KEYWORD-INJECTOR REMINDER]
agent: (answers with your rules applied)
This plugin lets AI agents shape the behaviour of other AI agents — at any moment, in any session, persistently across restarts. Trigger rules are global by default (
all-sessions), survive daemon restarts, and are delivered to the model with a "configured by the user" trust framing. One injected payload silently re-programs every session it reaches. If you would not hand a stranger your system prompt, do not hand them this plugin's write tools.
This plugin injects instructions into your agent's context automatically. That is its job — and exactly why it must be treated like loaded weaponry. Misconfigured, it can be turned against you.
0. Agent-to-agent coordination is the sharpest edge.
The keyword_injector_* tools are registered for every agent session in
the profile. Any agent — an executor on a task card, a subagent, an agent
processing untrusted input — can create, edit, or delete triggers, and those
changes apply to all other agents, including orchestrators and supervisors.
Two agents can thus establish a private instruction channel: agent A plants a
trigger keyed to agent B's vocabulary, and B obeys A's payload believing it
came from you. A manipulated agent can also delete your guardrails while
telling you everything is fine. In multi-agent setups, audit the trigger list
(keyword_injector_list_triggers, or the Keywords panel) after any session
that touched untrusted content, and treat unexpected triggers as incidents.
1. Agent-source triggers match EVERYTHING your agent reads.
The agent source scans reasoning, tool calls, and tool results. Tool
results include web pages, file contents, code comments, task cards, and
messages from other agents. Untrusted content can deliberately contain
your keyword and fire your trigger — an attacker who knows your keyword
can inject your payload at a moment of their choosing. If any session with
an agent-source trigger fetches external content, assume the trigger is
remotely fireable by strangers.
2. Triggers are a covert instruction channel. Injected reminders render as a collapsed row and carry implicit "configured by the user" trust. Anyone who can edit your trigger list — via the settings file, the GUI, or the agent tools — can silently shape every session's behavior. Treat trigger configuration with the same seriousness as your system prompt.
3. The agent can edit its own triggers.
This plugin registers write tools (create/update/delete) for the model. A
manipulated agent can be talked into editing its own triggers — including
removing your guardrails. In untrusted workflows, audit the trigger list
afterwards, or don't expose the tools.
4. Broad matches = context flooding and cost amplification.
contains: "the" or regex: .* on the agent source fires every turn,
stuffing your payload into every request — token spend, degraded reasoning,
pushed-out context. Keep keywords narrow; check the live-test panel; prefer
exact for common words.
5. Payloads inherit user trust.
Whatever you write in a payload, the model is told the user configured it.
Never put secrets in payloads. Never configure payloads on behalf of
someone you don't fully trust. A steer-skill trigger auto-loads and runs
skill instructions — that's code execution adjacent.
Hard rules we recommend:
user-source triggers; use agent-source deliberately, with
narrow keywords, on sessions that handle trusted input.~/.dsh/settings.yaml (namespace dsh-keyword-injector) after
letting agents near untrusted content.The plugin itself sends no network traffic and stores no secrets — but it automates instruction delivery. The safety of that automation is entirely in how you scope your triggers.
Most injectors only watch user input. Real prompts often don't contain the word that matters — the agent's own reasoning does:
User: "resolve the issue" → agent thinks "I need to triage this first" → *
triagerules arrive on their own.
| Source | Watches | Fires when |
|---|---|---|
user (default) | What the user types | The triggering message lands in the session inbox — the reminder joins that message's step (reminder first, one model request) |
agent | The agent's own reasoning and actions (assistant messages incl. thinking, tool calls + arguments, tool results) | The agent's step boundary — e.g. it thinks "I need to triage this" mid-task and the rules are injected for its next step of the same turn |
The matcher enforces source isolation (user triggers never fire on agent text and vice versa), and agent-source triggers fire once per turn per trigger — the agent echoing the keyword after reading the rules never re-triggers.
Follow the rules (user source,
static-text) injects your personal operating law: keep the session to-do
list updated, use SEQUENTIAL THINKING for long problems, escalate to the
advisor when stuck, never work around broken system tools, clean up
leftover scripts. Three words typed; the full rulebook arrives as context.context manager (user source, steer-skill)
injects "load the context-manager skill" — the agent picks up the whole
methodology without pasted instructions.triage, rules arrive at its next step.deploy to staging rides a smoke-test
reminder along with every matching request, in every session.| Field | Values | Notes |
|---|---|---|
| keyword | any text (≤ 200 chars) | what to match |
| matchType | exact / contains / regex | regex validated at save time; ReDoS-shaped patterns (e.g. (a+)+) rejected up front; runtime matcher has a sample cap + budget as a second guard; case-sensitivity toggle |
| mode | static-text / steer-skill | inject a verbatim payload, or an instruction to load a named skill (validated against the live skills catalog at save time) |
| source | user / agent | see above |
| scope | all-sessions / this-session | this-session only settable from inside a session |
| enabled | on/off | toggle straight from the table |
Payloads are wrapped in fixed [KEYWORD-INJECTOR REMINDER] … [END KEYWORD-INJECTOR REMINDER] delimiters and sanitised (invisible control bytes stripped), so user-supplied payload text can never pose as system instructions — the model always sees it as data inside a marked block.
Two surfaces, same manager:
Both provide: trigger table (enabled toggle, keyword, match type, mode, source, payload preview, scope, edit/delete), filter box, and an edit modal with a live test panel — a host-side dry run using the exact runtime matcher, so the panel is always honest about what will fire.
The model can manage triggers itself (useful for self-configuring agents — and dangerous; see warning 0 above):
keyword_injector_list_triggerskeyword_injector_create_trigger (skill targets validated)keyword_injector_update_triggerkeyword_injector_delete_triggerkeyword_injector_test_triggerThere is no allowlist, approval step, or per-session restriction on these tools: any agent in the profile can rewrite the rulebook of every other agent. If you only want you to configure triggers, audit the list frequently and treat unexpected triggers as incidents.
Besides keyword triggers, the plugin ships guard triggers — conditions over session behaviour rather than message text. Guards carry no keyword; they are evaluated at each agent step and fire (subject to a cooldown, in tool-call steps) by injecting their payload as a binding reminder.
| Guard | Condition | Fires when |
|---|---|---|
todo-compliance | { window: N } | N tool calls passed with no todo_write / taskboard_* in the window — nudges the agent to maintain its in-session task list |
orphan-process | — | a background job/agent exists with no reminder/schedule covering it — nudges the agent to set a reminder before answering |
tool-window (v0.4.0) | { window: N, noneOf?: [tool globs], anyOf?: [tool globs], cooldownSteps } | over the LAST N tool calls: no call matched any noneOf glob, and (when anyOf is set) none of those appeared either |
tool-window examples: {window: 8, noneOf: ["mcp__*sequentialthinking*"]} =
"reason step-by-step if you haven't for 8 calls"; {window: 15, anyOf: ["skill"]} = "load the matching skill if you haven't recently". Any
"do X whenever the agent hasn't done Y recently" rule becomes a one-line
config. Guards keep a bounded 64-name ring buffer of recent tool calls per
session; globs are cached, not recompiled per step.
Guard limits (by design): the engine sees tool names only — not tool arguments, not whether a loaded skill is semantically right for the job, not wall-clock time. Those need an LLM judge or a scheduler; deliberate scope cut.
On npm as dsh-keyword-injector (beta channel):
dsh plugin --profile web add dsh-keyword-injector@beta
or with pnpm directly:
cd ~/.dsh/profiles/web
pnpm add dsh-keyword-injector@beta
# then add "dsh-keyword-injector" to dsh.profile.bundles in package.json
Prefer the source? Install straight from GitHub:
dsh plugin --profile web add github:markelayan/dsh-keyword-injector
Local-development (link:) installs: clone anywhere, run npm install (pulls
schemastery), then dsh plugin --profile web add link:<path>. Note for
link: users: DSH resolves a plugin's imports from its realpath, so the
cloned copy needs its own node_modules (the npm install above provides it).
Restart dsh web and hard-refresh the browser after installing.
Requires a DSH core from the 0.1.1-rc line (tested on 0.1.1-rc.2 and 0.1.6-alpha.2) — see Compatibility for the full matrix.
lib/
├── index.js host half — events, persistence, HTTP routes, agent tools
├── client.js client half SOURCE (sidebar entry, panel, settings page)
├── client.bundled.js SHIPPED client — esbuild bundle in ModuleLoader format
├── schema.js trigger validation (all trust boundaries)
├── matcher.js runtime matching (regex cache, budgets)
└── reminder.js reminder text formatting + sanitisation
dsh-keyword-injector (ends up in
~/.dsh/settings.yaml), registered on boot with a permissive schemastery
schema; every read passes strict validateDocument, so a corrupted store
degrades to an empty trigger list — never a crash.host.call bridge, so the UI
talks to plain HTTP routes on the host:
POST /api/dsh-keyword-injector/{list,create,update,delete,test,skills}.user/message events
inserted through the agent inbox (agent.inject() → next-step queue), so
they are claimed together with the triggering message — reminder first —
and render as Context injection rows. The inbox claims exactly one
next-turn message per turn, so the plugin never prepends to that queue
(that would strand user messages).agent/inbox/inserted (user source) and
agent/pre-step (agent-source scanner).The browser loader requires a single self-contained
window.__ModuleLoader__.load file, so the client ships bundled. After
editing lib/client.js:
npm install # once
npx esbuild lib/client.js --bundle --format=cjs \
--external:react --external:react-dom --external:react-dom/client \
--outfile=/tmp/kwi.cjs
# re-wrap with the ModuleLoader factory — see the exact steps in the header
# comment of lib/client.bundled.js
Then restart dsh web and hard-refresh.
| Requirement | Details |
|---|---|
| DSH core | 0.1.1-rc+ required; tested on 0.1.1-rc.2 and 0.1.6-alpha.1/alpha.2. Uses tools/pre-execute hooks, agent.inject() inbox delivery, settings namespaces, web bundle loading, and ctx.webServer HTTP routes — stable across those versions. The pre-0.1.6 agent.session.event hook is NOT used (removed in dsh 0.1.6). |
| Install shape | Standard DSH bundle plugin: declares dsh.bundle.patch: ./cordis.patch.yml and mounts its own insert row into the profile — never add a second - insert: for this id in the profile's main cordis.patch.yml (duplicate insert ids crash dsh web on boot). |
| Runtime | Node ≥ 18 (ESM). No native deps; the only runtime dep is schemastery. |
| Client | Web GUI bundle (esbuild → ModuleLoader format). Sidebar Keywords panel + Settings page; hard-refresh the browser after install/upgrade. |
| Storage | Trigger list lives in the dsh-keyword-injector namespace of ~/.dsh/settings.yaml — plain YAML, survives restarts, included in normal settings backups. |
| Network | None. No outbound calls, no telemetry. All matching is local. |
| Upgrades | Update the package in ~/.dsh/profiles/web, then restart dsh web (user-only) — bundle source changes never hot-reload; only the patch file does. Trigger data is untouched by upgrades. |
See CHANGELOG.md. MIT license — see LICENSE.