Context Mode
安全运维 Context Mode：执行权限、持久证据与清理范围
区分子进程控制与操作系统隔离，检查环境继承，明确会话或项目保留策略，避免误删。
你将学会
- 子进程继承有实际意义的宿主权限与环境。
- 只检查拒绝规则不等于交互确认。
- 删除前明确选择会话或项目保留范围。
开始前需要
- 基础 JSON 与 MCP 概念
- 隔离测试客户端和虚构数据
解释本章真实实现边界，并用明确的证据样例核验。
先看结论
- 子进程继承有实际意义的宿主权限与环境。
- 只检查拒绝规则不等于交互确认。
- 删除前明确选择会话或项目保留范围。
临时脚本目录不是操作系统边界
PolyglotExecutor 在临时目录写入脚本，再作为子进程启动语言运行时。所查 execute 路径中，普通语言进程默认以项目目录为工作目录，除非传入覆盖值。这些实现细节并不能证明存在容器、虚拟机或独立强制网络边界，应检查实际宿主账户与外围沙箱控制。
环境构造器会移除一组运行时注入变量，但仍传递其他已定义环境值，并保留真实主目录路径。它不是去除所有凭据的允许列表。不能因为工具描述用了沙箱一词，就在包含生产秘密的账户运行不可信片段。应使用隔离账户或独立强制沙箱，并验证文件与网络限制。
策略与检索过滤的含义更窄
security.ts 同时包含交互式风格权限评估器和 evaluateCommandDenyOnly。后者在没有命中拒绝模式时返回 allow，因为这个服务器辅助函数无法展示询问提示。这不是所有调用点的完整授权流程，但足以说明不能假设宿主确认策略会原样迁移到独立 MCP 执行路径。
索引段落、会话事件和自动记忆都可能含敏感材料。如架构章节所述，项目范围 ContentStore 过滤有意保留旧版无归属块。应把来源标签和检索过滤当作查询控制，而非完整保密保证。用两个项目的无敏感独特标记测试隔离，比看到一次普通搜索恰好符合预期更可靠。
清理前必须确定范围与恢复决策
所查 ctx_purge 接口要求确认，并区分一个会话与整个项目。会话级删除保留兄弟会话及共享项目文件，项目级删除则覆盖更广的产物。向后兼容的裸确认会映射成项目清理并发出警告。不要在运行手册或探索性测试中使用这种含糊的简写形式。
任何删除前都应列出数据路径和保留要求。如果适合备份，备份也应受同等敏感数据策略约束，否则它可能破坏原定保留期限。本章刻意提供审查记录而非可执行清理命令。本次编辑审查没有删除用户数据、配置、会话或索引内容。
实施步骤
- 1
梳理宿主账户、环境与实际隔离控制。
- 2
在一次性环境测试跨项目标记与拒绝操作。
- 3
盘点存储产物和备份保留期限。
- 4
调用清理前获得明确的范围删除决定。
可复制示例
{
"operation": "仅保留策略审查",
"scope": "未决定",
"sessionId": null,
"dataPathsReviewed": false,
"backupRetentionReviewed": false,
"deletionApproved": false
}常见问题
沙箱执行就无法读取我的秘密了吗？
不能这样推断。所查子进程实现并非操作系统隔离证明，其环境拒绝列表也不会移除全部凭据。
删一个会话等于清空项目数据吗？
不等于。所查清理实现有意让两种范围产生不同影响，应明确范围并审查产物清单。
资料来源
- README.md来源核查 2026-09-07
- package.json来源核查 2026-09-07
- LICENSE来源核查 2026-09-07
- src/store.ts来源核查 2026-09-07
- src/search/unified.ts来源核查 2026-09-07
- src/server.ts来源核查 2026-09-07
- src/executor.ts来源核查 2026-09-07
- src/security.ts来源核查 2026-09-07
- src/session/purge.ts来源核查 2026-09-07
- tests/store-bytecap.test.ts来源核查 2026-09-07