dsh-keyword-injector

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)

⚠️ DANGER — read this before you use it

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:

• Only edit triggers from a trusted seat (your machine, your settings file).
• Prefer user-source triggers; use agent-source deliberately, with narrow keywords, on sessions that handle trusted input.
• Never use keywords likely to appear in code, data, or fetched content.
• Audit ~/.dsh/settings.yaml (namespace dsh-keyword-injector) after letting agents near untrusted content.
• Keep payloads short, factual, and secret-free.

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.

Why two trigger sources

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" → *triage rules 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.

Real use cases

1. Standing rules on demand — trigger 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.
2. Skill steering — trigger context manager (user source, steer-skill) injects "load the context-manager skill" — the agent picks up the whole methodology without pasted instructions.
3. Triage rules the agent asks for itself — the agent-source example above: user says "resolve the issue", the agent's own reasoning matches triage, rules arrive at its next step.
4. Deploy guardrail — trigger deploy to staging rides a smoke-test reminder along with every matching request, in every session.

Trigger model

| 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.

UI

Two surfaces, same manager:

1. Sidebar → Keywords — a main panel alongside Task Board / SSH / Skill Center.
2. Settings → Keyword Injector.

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.

Agent tools

The model can manage triggers itself (useful for self-configuring agents — and dangerous; see warning 0 above):

• keyword_injector_list_triggers
• keyword_injector_create_trigger (skill targets validated)
• keyword_injector_update_trigger
• keyword_injector_delete_trigger
• keyword_injector_test_trigger

There 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.

Guards (behavioural triggers)

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.

Install

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.

Architecture

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

• Persistence: settings namespace 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.
• Client ↔ host: bundle clients have no 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}.
• Delivery: reminders are durable, plugin-sourced 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).
• Events used: agent/inbox/inserted (user source) and agent/pre-step (agent-source scanner).

Rebuilding the client

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.

Security & privacy

• No network calls. The client fetches same-origin DSH routes only; the host touches local files (the DSH settings store) and in-process APIs. No telemetry, no analytics, no outbound requests, ever.
• No secrets. The plugin stores no credentials and reads none.
• Injection-hardened. Reminder payloads are fenced in constant delimiters, sanitised, and length-capped; the keyword itself is sanitised before embedding. The model is told, in-band, that the block is configured by the user — not instructions from the payload author.
• ReDoS guards. Regex triggers are shape-checked at save time and sample-capped + budgeted at match time.
• Self-matching impossible. The scanner reads only genuine user input or assistant/tool events — never the plugin's own injections — and fires at most once per message (user source) or per turn (agent source).

Compatibility

| 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. |

Changelog

See CHANGELOG.md. MIT license — see LICENSE.