dscode
github.com/HQ1995/deepseek-code
v0.0.12
开发与运行时
可执行外部程序以 shell 执行命令写入文件
DeepSeek Harness 编码 TUI,以 dsh 插件形式分发:本包 包含 grok-leader 桥接层(TUI 所驱动的 dsh 侧服务器)以及 `dscode` 启动器,它会在首次运行时从 GitHub Releases 拉取与发行版绑定的 TUI 二进制文件(经 SHA-256 校验,缓存于 `~/.dsh/profiles/dscode/bin/`)。
作者原文(英文)
dscode - DeepSeek Harness coding TUI, distributed as a dsh plugin (grok-leader bridge + launcher)
中文简介由 DeepSeek 模型翻译,仅供参考。
源仓库没有任何提交 仓库存在但是空的,没有源码可看。npm 上的包仍然可以安装,但作者没有公开对应源码。
检测报告
关注度高。命中了不少能力模式,其中可能有需要留意的。逐条看下面的清单。
2高关注4需留意3一般15未命中
高关注需留意一般
能力清单
- 可执行外部程序
spawns-processes高关注3 处命中lib/types/index.js:14import { execFile } from 'node:child_process';bin/dscode.mjs:28import { spawn, spawnSync } from 'node:child_process'src/index.ts:15import { execFile } from 'node:child_process'- 看它调用哪些程序。调用本机已有的工具是常见做法。
- 以 shell 执行命令
shell-exec高关注2 处命中lib/types/index.js:1381grokShell: true,src/index.ts:1677grokShell: true,- 看命令字符串是拼出来的还是写死的。拼接用户输入才是真正的风险。
- 写入文件
writes-files需留意28 处命中lib/types/index.js:2023await writeFile(temporary, JSON.stringify(raw, null, 2) + '\n');lib/types/index.js:2024await rename(temporary, target);lib/types/index.js:2168await writeFile(join(stage, 'package.json'), JSON.stringify({ private: true }, null, 2) + '\n');lib/types/index.js:3414titleService.rename(record.agent.session, title);- 看写入位置。写自己的配置目录是正常的,写系统目录不是。
- 发起网络请求
network需留意5 处命中lib/types/index.js:236const response = await fetch(url, {bin/dscode.mjs:302const res = await fetch(url, { redirect: 'follow', signal: AbortSignal.timeout(120000) })bin/dscode.mjs:309const res = await fetch(url, { redirect: 'follow', signal: AbortSignal.timeout(120000) })bin/dscode.mjs:324const shaRes = await fetch(`${base}/${asset}.sha256`, { redirect: 'follow' })- 看请求发往哪些域名。发往作者自己的后端是常见做法。
- 运行时改写自身配置
modifies-own-manifest需留意2 处命中lib/types/index.js:2168await writeFile(join(stage, 'package.json'), JSON.stringify({ private: true }, null, 2) + '\n');src/index.ts:2478await writeFile(join(stage, 'package.json'), JSON.stringify({ private: true }, null, 2) + '\n')- 运行时改写自身配置会让下次启动的行为和你看过的源码不一致。
- 启动伪终端
spawns-pty需留意1 处命中bin/dscode.mjs:89const probe = spawnSync('/bin/sh', ['-c', 'command -v -- "$1"', 'sh', name], {- 伪终端等于给了一个完整 shell。确认这是插件的核心功能。
- 接触凭据或密钥
credentials一般231 处命中lib/types/index.js:234async function discoverEndpointModelCapabilities(baseURL, apiKey) {lib/types/index.js:240...apiKey === undefined ? {} : { authorization: 'Bearer ' + apiKey },lib/types/index.js:371const SENSITIVE_ROW_IDS = new Set(['sandbox', 'sandbox-policy', 'approval', 'permission-presets', 'credentials', 'settin…lib/types/index.js:675* section: the only endpoints a resolved env secret may be sent to. */- 看它读取哪些凭据、发往哪里。用于登录自己的服务是正常的。
- 读取文件
reads-files一般30 处命中lib/types/index.js:63if (existsSync(candidate)) {lib/types/index.js:64const manifest = JSON.parse(readFileSync(candidate, 'utf8'));lib/types/index.js:543process.stderr.write('grok-leader: loaded ' + self + ' (built ' + statSync(self).mtime.toISOString() + ')\n');lib/types/index.js:1964return existsSync(join(fallback, 'package.json')) ? fallback : undefined;- 读文件是绝大多数插件的正常工作方式,本身不构成顾虑。
- 读取环境变量
reads-env一般23 处命中lib/types/index.js:574const combineQueued = config.combineQueuedPrompts === true || process.env.DSCODE_COMBINE_QUEUED === '1';lib/types/index.js:577const followUpSteer = (config.followUpBehavior ?? process.env.DSCODE_FOLLOW_UP ?? 'queue') === 'steer';lib/types/index.js:703const value = process.env[ref];lib/types/index.js:995if (process.env.DSCODE_DEBUG === '1') {- 环境变量里常混有密钥。看它是否把整个 env 都读走。
逐条扫描明细
| 能力 | 标识 | 关注度 | 命中次数 |
|---|---|---|---|
| 可执行外部程序 | spawns-processes | 高关注 | 3 |
| 以 shell 执行命令 | shell-exec | 高关注 | 2 |
| 写入文件 | writes-files | 需留意 | 28 |
| 发起网络请求 | network | 需留意 | 5 |
| 运行时改写自身配置 | modifies-own-manifest | 需留意 | 2 |
| 启动伪终端 | spawns-pty | 需留意 | 1 |
| 接触凭据或密钥 | credentials | 一般 | 231 |
| 读取文件 | reads-files | 一般 | 30 |
| 读取环境变量 | reads-env | 一般 | 23 |
这份报告的口径
扫描读的是包里的源码,全程不执行第三方代码。 本次读了 16 个文件,扫描于 2026-10-14。 命中次数只说明源码里出现过这类调用,不说明行为好坏——一个插件读写文件 500 次和 1 次 都会被记为「读取文件」。这是能力清单,不是信任评分,也不是安全结论: 没扫出来的能力可能只是写法没被规则覆盖。
依赖安全公告
这个插件声明的依赖中,有 6 条已公开的安全公告 (最高等级:中):
| 等级 | 依赖包 | 编号 | 摘要 |
|---|---|---|---|
| 中 | js-yaml | CVE-2026-84375 | js-yaml: maxTotalMergeKeys does not limit CPU use for empty merge sources 修复版本:3.15.2, 4.3.2 详情 → |
| 中 | js-yaml | CVE-2026-59869 | js-yaml: YAML merge-key chains can force quadratic CPU consumption 修复版本:3.15.0, 4.3.0 详情 → |
| 中 | js-yaml | GHSA-5p4m-2wfm-xmqj | JS-YAML: Quadratic CPU consumption in !!omap resolution (3.x and 4.x) — CVE-2026-59870 fix not backported 修复版本:3.15.1, 4.3.1 详情 → |
| 低 | js-yaml | CVE-2026-53550 | JS-YAML: Quadratic-complexity DoS in merge key handling via repeated aliases 修复版本:3.15.0, 4.2.0 详情 → |
| 低 | js-yaml | CVE-2025-64718 | js-yaml has prototype pollution in merge (<<) 修复版本:3.14.2, 4.1.1 详情 → |
| 低 | js-yaml | GHSA-r3ph-w7gj-g6xm | js-yaml: maxTotalMergeKeys does not limit CPU use for empty merge sources 修复版本:5.4.1 详情 → |
查询的是依赖声明范围的下界(如 ^4.2.0 查 4.2.0),
不是实际安装到的版本。真正装的时候如果解析到了修复版本,就不受影响——
所以这是「可能受影响」,不是「这个插件有漏洞」。数据来自
OSV.dev。