Memo Code 安全设计：子进程、命令防护与权限审批的统一方案

同步至个人站点：Memo Code 安全设计：子进程、命令防护与权限审批的统一方案

Memo Code 是我最近两个多月投入较多精力的 Agent 项目。类似于Claude Code 和 Codex 的 轻量级本地编程 Agent，目前已具备 Coding Agent 完备技能。

如果你感兴趣的话，欢迎参与：Memo Code - Github，或者给个 Star 鼓励一下哈哈～

做 Agent 这类能「替用户干活」的工具，安全性是躲不掉的坎。

我一开始做 memo（github.com/minorcell/m…）的时候，安全问题还没想那么多——能跑起来就行。后来工具越加越多，shell 命令也越跑越复杂，就开始踩坑了：

1. 子进程忘了关，内存慢慢涨
2. rm -rf / 差点真被我跑出来
3. 每次执行都要点批准，用户体验稀碎

这些问题逼着我认真设计了整套安全方案。今天把思路和实现细节都分享出来，希望对你有帮助。

先想清楚：安全设计要解决什么问题？

我把它拆成三件事：

1. 资源可控：子进程不能无限开，不能忘了关
2. 操作安全：危险命令要拦截，误操作要有缓冲
3. 权限平衡：该拦的拦住，该放的放行，还要给用户留个「后门」

下面逐一展开。

第一道防线：子进程管理——防止内存泄漏与资源耗尽

memo 的 shell 执行用的是 Node.js 的 child_process.spawn，但光 spawn 是不够的——你还得管得住。

统一会话管理器

我写了一个 UnifiedExecManager（packages/tools/src/tools/exec_runtime.ts），核心思路是单例 + 会话池：

classUnifiedExecManager {  private sessions = newMap<number, SessionState>()  private nextId = 1privateMAX_SESSIONS = 64}

好处很明显：

1. 所有子进程都有唯一 ID
2. 随时可以查询状态、发送信号、获取输出
3. 资源回收有统一入口

资源限制：数量 + 内存 + 时间

先看数量限制：

asyncstart(request: StartExecRequest) {    this.cleanupSessions()    if (this.activeSessionCount() >= MAX_SESSIONS) {        thrownewError(`too many active sessions (max ${MAX_SESSIONS})`)    }    // ...}

超过 64 个活跃会话就直接拒绝，防止被LLM恶意耗尽系统资源。

再看输出限制。Agent 交互是基于 token 计费的，子进程输出不能无限制返回：

functiontruncateByTokens(text: string, maxOutputTokens?: number) {  const maxChars = (maxOutputTokens || 2000) * 4if (text.length <= maxChars) {    return { output: text, deliveredChars: text.length }  }  return {    output: text.slice(0, maxChars),    deliveredChars: maxChars,  }}

默认最多返回 8000 字符，不够可以调，但不会无限大。

超时终止：SIGTERM → SIGKILL

子进程跑飞了是常见问题。memo 的策略是先礼貌后强硬：

privateasyncterminateForTimeout(session: SessionState) {    if (session.exited) return    session.proc.kill('SIGTERM')    awaitwaitForExit(session, 200)  // 等 200msif (!session.exited) {        session.proc.kill('SIGKILL')  // 还是没退就直接杀了awaitwaitForExit(session, 200)    }}

为什么要等一下？因为有些程序接收到 SIGTERM 会做清理工作（比如写入缓存、关闭句柄），直接 SIGKILL 可能导致数据丢失。

内存泄漏防护：自动清理已退出的会话

会话不能只增不减。我加了一个自动清理逻辑：

privatecleanupSessions() {    if (this.sessions.size <= MAX_SESSIONS) return// 优先清理已退出的，按启动时间从早到晚排序const ended = Array.from(this.sessions.values())        .filter(session => session.exited)        .sort((a, b) => a.startedAtMs - b.startedAtMs)    for (const session of ended) {        if (this.sessions.size <= MAX_SESSIONS) breakthis.sessions.delete(session.id)    }}

这样即使跑了几百个命令，内存也不会无限涨。

第二道防线：命令守卫——拦截危险操作

子进程管住了还不够，还得管住跑什么命令。

我见过太多「rm -rf /」惨案，也见过 dd if=/dev/zero of=/dev/sda 这种物理层面不可逆的破坏。memo 的做法是命令解析 + 黑名单匹配。

命令解析：不只是字符串匹配

直接正则匹配 rm -rf 是有漏洞的。比如 sudo rm -rf /、包裹在 bash -c 里、甚至写成十六进制，都能绕过简单匹配。

memo 的做法是先把命令拆成「段」，再逐段解析：

functionsplitCommandSegments(command: string) {  // 按 ; | && || 分割，处理引号和转义// 返回每一段独立的命令}functionparseSegment(segment: string) {  // 跳过 sudo/env/nohup 等包装// 提取真实的命令名和参数}

这样不管外面包了多少层 sudo env bash -c，最终都能追溯到真正的命令。

危险命令黑名单

目前 memo 拦截这几类（packages/tools/src/tools/command_guard.ts）：

拦截后返回的是 <system_hint> 标记，不是直接报错，方便 Agent 理解为什么被拦：

<system_hinttype="tool_call_denied"tool="exec_command"reason="dangerous_command"policy="blacklist"rule="rm_recursive_critical_target"command="rm -rf /">    Blocked a high-risk shell command to prevent irreversible data loss.    Use a safer and scoped alternative.</system_hint>

第三道防线：审批系统——平衡权限与体验

命令守卫是第一道关卡，但还有很多「不危险但需要知道」的操作，比如写文件、改配置。审批系统的目标就是分级管理、可追溯、可配置。

风险分级

memo 把工具分成三级（packages/tools/src/approval/constants.ts）：

审批模式

1. auto 模式：只读工具免审批，写/执行类工具需要审批
2. strict 模式：所有工具都需要审批，一个都跑不掉

check(toolName: string, params: unknown): ApprovalCheckResult {    if (ALWAYS_AUTO_APPROVE_TOOLS.has(toolName)) {        return { needApproval: false, decision: 'auto-execute' }    }    const riskLevel = classifier.getRiskLevel(toolName)    if (!classifier.needsApproval(riskLevel, approvalMode)) {        return { needApproval: false, decision: 'auto-execute' }    }    // 生成指纹，返回需要审批}

审批记忆：一次批准，记住一整场

如果每次执行都要点批准，用户体验会非常差。memo 用指纹 + 缓存解决这个问题：

const fingerprint = generateFingerprint(toolName, params)cache.toolByFingerprint.set(fingerprint, toolName)// 审批后记录recordDecision(fingerprint, decision: 'session' | 'once' | 'deny') {    switch (decision) {        case'session': cache.sessionTools.add(toolName); breakcase'once': cache.onceTools.add(toolName); breakcase'deny': cache.deniedTools.add(toolName); break    }}

1. session：这场对话内一直有效
2. once：用一次就失效
3. deny：以后再问直接拦截

dangerous 模式

审批系统是安全了，但有时候用户就是想要「无限制」——比如在本地开发、或者明确知道自己在干什么。

memo 提供了 dangerous 模式：

if (dangerous) {  return {    isDangerousMode: true,    getRiskLevel: () =>'read', // 所有操作都视为最低风险check: () => ({ needApproval: false, decision: 'auto-execute' }),    isGranted: () =>true,  }}

开启也很简单，CLI 里加上 --dangerous 标记：

memo --dangerous

开启后：

1. 所有工具都免审批

这是一把双刃剑。 我在 CLI 里加了这个选项，但默认是关闭的。开发者如果想用，需要明确加上 --dangerous 标记。

总结：三层防护 + 一个后门

memo 的安全设计可以总结为：

1. 子进程管理：数量限制 + 输出截断 + 超时终止 + 自动清理
2. 命令守卫：命令解析 + 黑名单拦截 + stdin 检测
3. 审批系统：风险分级 + 审批模式 + 记忆缓存
4. dangerous 模式：留一个「我知道我在干什么」的后门

这套方案不完美，还在持续迭代。比如命令守卫目前是硬编码的黑名单，后续可以考虑支持用户自定义规则；审批系统也可以考虑接入外部信任模型。

（完）