Install verification: runtime verified (L5) · tested on dsh 0.2.2-rc.1 · last checked Install verification details →
Data as of (UTC)
What it doesAI
DSH plugin that stores notes as plain .txt/.md files on disk, with a sidebar panel, a popout editor window and a record_note agent tool.
- Notes are real .txt/.md files in a configurable root directory, no lock-in
- Daily log mode auto-appends to MMDD sections with numbering and day rollover
- Full-text search with case-sensitive, regex and whole-word modes; trash and mtime conflict protection
Capability tags are AI-inferred or rule-extracted from the README (see badge) — vocabulary-limited, not install-verified. AI = inferred; README = literal keyword from the readme.
Installation
dsh plugin --profile web add dsh-record-managerInstall method: npm · runtime verified (L5)
Verification & Compatibility
Grouped by plugin version: each card lists the dsh versions actually tested against that artifact version and their install verdicts (L5 wins). Untested combinations are omitted — absence means untested, never assumed compatible. L1–L3 are a plugin-level static archive (independent of the dsh version — the same verdict on every dsh row): they sit in each row's level grid next to L4/L5, marked "static", while their evidence is stored once per plugin inside that row's "checks & evidence" instead of being duplicated per version.
External credentials (plugin-level): none detected
package manifest not collected — the declared range is unknown.
| plugin ＼ dsh | dsh 0.2.2-rc.1 current |
|---|---|
| 0.1.0 | ✓ |
0.1.0npm✓ 1 runtime-verified2026-11-11
dsh-record-manager
✓dsh 0.2.2-rc.1current2026-11-11L5 · runtime verified
- • Node.js: v24.14.0
- • DSH: 0.2.2-rc.1
- • Plugin artifact: npm · dsh-record-manager@0.1.0
ID: dsh-record-manager@0.1.0@dsh0.2.2-rc.1 · profile: l4-sandbox
Issued: 2026-11-11 · expires: 2026-11-18
View checks & evidence
↳ carried from earlier record dsh-record-manager@a6243f@dsh0.2.2-rc.1 (l3-fullscan)
↳ carried from earlier record dsh-record-manager@a6243f@dsh0.2.2-rc.1 (l3-fullscan)
↳ carried from earlier record dsh-record-manager@a6243f@dsh0.2.2-rc.1 (l3-fullscan)
active in loader tree (150 entries)
L1–L3 are plugin-level static conclusions (baseline, identical across dsh versions): evidence is stored once per plugin.
Only the latest 3 published versions are shown; source-snapshot (commit hash) groups, unstated groups and older versions are omitted — the full archive stays in the data layer (snapshot/unstated groups appear only when a plugin has no published version).
Author badges
Embed the dsh.so badges in your README to show this plugin's automated security-scan and install-test status:
`[](https://www.dsh.so/artifact/dsh-record-manager/?ref=badge)``[](https://www.dsh.so/artifact/dsh-record-manager/?ref=badge-install)`dsh.so is an independent community project, not affiliated with or endorsed by DeepSeek AI. Badges are maintained by dsh.so; embed links carry a ?ref= attribution parameter.
Security Report
Two automated layers, neither a manual review: a static scan (per-plugin rule checks) and a model-driven dynamic security audit that covers only the subset static-flagged at warn or above and never executes plugin code.
Static high; dynamic medium (authoritative when present) → overall medium.
v0.1.0dsh manifest0.1.0npm2026-11-110.1.0same versionsuspicious · npmVet is an AST static scan (npm artifact or git source).
show static findings (5)
- warningshellExec · shell
index.js:85execFile('rundll32', ['url.dll,FileProtocolHandler', t], () => {}) - warningshellExec · shell
index.js:87execFile('open', [t], () => {}) - warningshellExec · shell
index.js:89execFile('xdg-open', [t], () => {}) - warningfsWrite · files
index.js:48fs.writeFileSync(SETTINGS_FILE, JSON.stringify(obj, null, 2), 'utf8') - warningfsWrite · files
index.js:148fs.writeFileSync(tmp, text, { encoding: 'utf8' })
show 3 audit findings
- mediumPOST /config lets any same-origin caller retarget the notes root at an arbitrary absolute directory
index.js:60setRoot only rejects a bare Windows drive letter; on POSIX '/' is accepted, and any absolute directory can be persisted to .dsh-record-manager.json. After that, /read, /write, /create, /delete and /trash/restore operate on any .txt/.md file anywhere on disk (e.g. ~/.config, documents, log dumps), so a single request to a documented endpoint widens the plugin's file reach far beyond its own data directory. The origin/Sec-Fetch-Site guard limits this to same-origin pages and local processes, and the .txt/.md whitelist prevents arbitrary-extension writes.
- lowUser-supplied regular expression executed server-side without timeout in /search
index.js:279GET /search?q=<pattern>®ex=1 compiles an arbitrary pattern and runs it per line over every .txt/.md under ROOT (up to 4MB each, unlimited file count) on the single-threaded Node server. A catastrophic-backtracking pattern such as (a+)+$ against a long line blocks the event loop and stalls the whole DSH harness. Reachable by direct API call (the bundled client never sets regex=1) and by anyone already same-origin.
- lowPath fence is lexical only; symlinks inside ROOT escape safePath/safeDirPath
index.js:112The containment check uses path.resolve/path.relative without fs.realpathSync, so a symlinked directory or file placed inside the notes root lets /read, /write, /create, /delete and directory listing reach paths outside ROOT (still limited to .txt/.md for files). Exploitation requires the attacker to already be able to create a symlink inside the notes root, e.g. another local process or a user mistake.
Well-guarded local notes plugin: shell-free execFile and a lexical path fence hold, but the /config API can repoint the notes root at any absolute directory, widening .txt/.md read/write/delete scope.
Rule (2026-10-28): when a dynamic conclusion exists it is authoritative (it may raise or lower the level); the static scan tier (vet primary, dsh backstop) applies only when there is none (not queued / audit failed / withdrawn). The audit never writes the exemption list (exemptions are manual only); a wrong conclusion is withdrawn by human review and the tier falls back to the static scan tier.
Disclaimer: the static scan and the dynamic security audit are both automated analysis, not a security guarantee. Always review what you install.
Activity
Last commit 2026-11-04 · activity: Active
• Repo created: 2026-11-04
• Stars: ★ 0 · Forks: 0
• Health: Active — committed within last 30 days
Source
Author README
View on GitHub ↗The author's original README from the repository — fetched live, unedited (the English page loads the default README).
Frequently asked questions
What is @void0042/dsh-record-manager?
@void0042/dsh-record-manager is a DeepSeek Harness (dsh) plugin listed on dsh.so — an independent community registry that indexes public source repositories and publishes automated security-scan and install-verification results for each entry.
Is dsh.so or this plugin page official?
dsh.so is an independent community registry and is not affiliated with, endorsed by, or sponsored by DeepSeek AI.
How do I install @void0042/dsh-record-manager?
Run dsh plugin --profile web add dsh-record-manager in a DeepSeek Harness (dsh) environment. That exact command passed a real install inside an isolated sandbox (L4) plus web smoke testing (L5).
How does the security scan relate to a manual audit?
Both layers are automated, not a manual audit. The static scan is heuristic analysis of the repository source, so it can produce false positives and miss context. The model-driven dynamic security audit only covers plugins static-flagged at warn or above, never executes plugin code, and its conclusion is authoritative when there is one (it may raise or lower the static tier); exemptions stay manual. Neither layer is an endorsement: review the repository and the permissions it asks for before installing, together with the verification level and health signals.
How fresh is the data on this page?
The data on this page is as of 2026-11-11 (UTC) — the most recent valid timestamp among the registry refresh, install verification, security scan and dynamic audit. Build time is never used as a data date.