Autopilot Approval Cache Can Enable Persistent Dangerous Shell Execution Escalation

[krrish612]

Deep Copilot’s approval system includes cached shell-command approvals and full autopilot execution modes for trusted workspaces. Under long-running agent sessions, there is a potential privilege-escalation risk where previously approved dangerous shell execution patterns may persist across evolving agent contexts without sufficient contextual revalidation.

The issue becomes especially dangerous because:

shell approvals can become stateful
workflows are multi-turn and autonomous
tools can chain recursively after edits
post-tool hooks inject execution feedback back into the model
MCP servers extend external execution surfaces

This creates a compound trust-escalation surface inside long-running autonomous coding sessions.

cc: @maintainers

Affected areas:

approval manager
run_shell tool
post-tool hooks
MCP integration layer
agent orchestration runtime

Potential attack vectors:

stale dangerous-command approval reuse
prompt-injected shell escalation
malicious MCP tool chaining
approval cache poisoning
recursive hook-triggered execution
context drift during autopilot sessions

Steps to reproduce:

Enable autopilot or auto-edit mode
Approve a dangerous shell pattern once
Trigger multiple autonomous tool-calling loops
Inject modified shell payloads through iterative agent reasoning
Observe whether execution trust persists without semantic revalidation

Expected behaviour:

dangerous shell commands should require contextual revalidation
approval state should expire deterministically
command semantics should be re-evaluated after context drift
recursive execution chains should remain isolated
MCP-triggered execution should enforce separate trust boundaries

Actual behaviour:
The current approval architecture may potentially allow previously trusted execution contexts to persist across evolving orchestration flows, increasing the risk of unintended or escalated shell execution.

Potential impact:

unintended filesystem mutation
privilege escalation inside trusted workspaces
recursive destructive command execution
compromised agent isolation
malicious MCP execution propagation
automated destructive workflow chaining

Suggested fix:

semantic approval hashing
short-lived approval leases
contextual execution attestation
per-tool trust isolation
recursive execution depth limits
approval replay invalidation
separate MCP execution sandboxing

Suggested labels:
security
shell-execution
mcp
agentic-ai
advanced
backend

[ZhouChaunge]

Hi @krrish612,

Thank you for the thorough and well-structured security report. We appreciate the time you put into analyzing the approval architecture and identifying these potential escalation vectors.

You're right that the session-scoped _dangerCmdApprovals cache and the blanket trust granted in autopilot mode create a surface that could be exploited — particularly via prompt injection or recursive tool chaining. We also acknowledge the gap in hooks.js, where hook commands bypass the isDangerous() check entirely.

We'll be addressing these issues as soon as possible, including:

• Routing hook execution through the dangerous-command gate
• Adding an expiry/TTL mechanism for the approval cache
• Enforcing stricter trust boundaries for MCP-triggered execution

Thanks again for helping make DeepCopilot more secure. We'll update this issue as fixes land.

[ZhouChaunge]

Tracking Fix Plan | 修复跟踪计划

After a full code-level review of the affected modules, three concrete vulnerabilities were confirmed. Tracking them here for transparency.

经对相关模块的完整代码审查，确认存在以下三个具体漏洞，在此公开跟踪。

---

Finding 1 — hooks.js bypasses the dangerous-command gate entirely

问题一 — hooks.js 完全绕过危险命令检测

Severity | 严重程度: High | 高

Location | 位置: src/hooks.js → execCmd()

Root cause | 根本原因:

Hook commands defined in .deepcopilot/hooks.json are executed directly via cp.exec(cmd, { shell: true }) with no call to isDangerous() or confirmDangerous(). Any destructive hook command will execute silently, regardless of the user's approvalMode setting.

.deepcopilot/hooks.json 中定义的 hook 命令通过 cp.exec(cmd, { shell: true }) 直接执行，完全没有调用 isDangerous() 或 confirmDangerous()。无论用户设置了何种 approvalMode，破坏性 hook 命令都会静默执行。

// Example — executes without any prompt | 示例 — 无任何提示即执行
{ "event": "after_tool", "tool": "write_file", "run": "rm -rf /" }

Planned fix | 修复方案:

• Route each hook command through the same isDangerous() + confirmDangerous() flow used in shell.js

• autopilot mode → audit-log and allow; manual / auto-edit → prompt and block if denied

• 将每条 hook 命令接入 shell.js 中相同的 isDangerous() + confirmDangerous() 流程

• autopilot 模式 → 记录审计日志并放行；manual / auto-edit 模式 → 弹窗确认，拒绝则阻断

---

Finding 2 — _dangerCmdApprovals cache has no TTL

问题二 — _dangerCmdApprovals 缓存无过期机制

Severity | 严重程度: Medium | 中

Location | 位置: src/tools/shell.js line 16

Root cause | 根本原因:

The approval cache is a plain Set with no expiry. Once approved, a command is never re-prompted for the entire VS Code session. This is exploitable via prompt injection: a payload matching any previously approved normalized command string will execute silently.

审批缓存是一个没有过期机制的普通 Set。命令一旦被批准，在整个 VS Code 会话期间都不会再次询问。这可被 prompt 注入利用：与已批准命令归一化字符串匹配的 payload 将静默执行。

Planned fix | 修复方案:

• Replace Set with Map<string, number> storing approval timestamps

• Add deepseekAgent.dangerApprovalTTLMinutes config (default: 30)

• Evict expired entries on each cache lookup

• 将 Set 替换为存储批准时间戳的 Map<string, number>

• 新增配置项 deepseekAgent.dangerApprovalTTLMinutes（默认值：30 分钟）

• 每次查询缓存前清除已过期条目

---

Finding 3 — MCP-triggered execution has no independent trust boundary

问题三 — MCP 触发的执行缺乏独立信任边界

Severity | 严重程度: Medium | 中

Location | 位置: src/mcp.js + src/chat/tool-executor.js

Root cause | 根本原因:

MCP tool calls are dispatched through a separate path that does not invoke the run_shell dangerous-command gate. A malicious or compromised MCP server could trigger destructive shell operations bypassing all approval logic.

MCP 工具调用走独立通道，不经过 run_shell 的危险命令门控。恶意或被入侵的 MCP 服务器可绕过所有审批逻辑触发破坏性 shell 操作。

Planned fix | 修复方案:

• Tag tool calls with their origin: user | agent | mcp

• Enforce that any run_shell call from MCP always requires explicit user confirmation, even in autopilot mode

• Audit-log every MCP-originated shell execution

• 为工具调用标记来源：user | agent | mcp

• 强制要求所有来自 MCP 的 run_shell 调用必须经过显式用户确认，即使处于 autopilot 模式

• 对每次 MCP 来源的 shell 执行记录审计日志

---

Acceptance Criteria | 验收标准

• Hook commands pass through isDangerous() before execution | hook 命令执行前经过 isDangerous() 检测
• _dangerCmdApprovals entries expire after the configured TTL | 审批缓存条目在配置的 TTL 后过期
• MCP-originated run_shell calls always require confirmation | MCP 来源的 run_shell 始终需要确认
• All three behaviours covered by tests | 三项行为均有测试覆盖
• package.json schema updated for the new TTL setting | package.json 新增 TTL 配置项声明

---

Affected files | 涉及文件: src/tools/shell.js, src/hooks.js, src/mcp.js, src/chat/tool-executor.js