背景
当前运行时仍然依赖 sandbox-agent,同时在接入 Codex / Claude Code 时,文件上传边界也偏大,容易演变成整目录拷贝(如 .codex、.claude)。
这两个问题本质上都指向同一个目标:
- 运行时协议层应尽量收敛到统一标准
- 本地 agent 状态与认证材料的上传范围应尽量最小化
目标
- 彻底放弃
sandbox-agent
- 统一只使用 ACP 作为 agent 协议/抽象层
- 不再完整拷贝
.codex 或 .claude 目录
- Codex / Claude Code 只上传运行或登录所必需的最小文件集合
需求范围
1. Runtime / Protocol
- 删除对
sandbox-agent 的运行时依赖
- 清理相关适配层、抽象层、配置项和文档
- 统一改为 ACP 作为唯一协议层
- 梳理当前
sandbox-agent 承担的能力,并明确 ACP 对应实现方式
2. File Upload / Auth Material
- 不再整目录传输
.codex 或 .claude
- 为 Codex / Claude Code 分别定义必要文件 allowlist
- 仅上传认证、登录或运行真正需要的文件
- 排除缓存、日志、历史、临时文件和无关本地状态
建议关注点
sandbox-agent 退出后,对现有任务执行、事件流、会话管理、日志采集的影响
- ACP 是否已覆盖当前关键能力;未覆盖部分如何调整设计
- Codex / Claude Code 所需最小文件集合的定义与审计方式
- 缺失必要文件时的错误提示与排障体验
- 文档中明确新的运行时架构和安全边界
验收标准
- 代码库中不再依赖
sandbox-agent 作为运行时方案
- ACP 成为唯一 agent 抽象/协议层
- Codex 登录不再需要完整上传
.codex 目录
- Claude Code 登录不再需要完整上传
.claude 目录
- 上传集合可审计、可解释,并明显小于整目录拷贝
- 相关文档、脚本、配置与实现保持一致
背景
当前运行时仍然依赖
sandbox-agent,同时在接入 Codex / Claude Code 时,文件上传边界也偏大,容易演变成整目录拷贝(如.codex、.claude)。这两个问题本质上都指向同一个目标:
目标
sandbox-agent.codex或.claude目录需求范围
1. Runtime / Protocol
sandbox-agent的运行时依赖sandbox-agent承担的能力,并明确 ACP 对应实现方式2. File Upload / Auth Material
.codex或.claude建议关注点
sandbox-agent退出后,对现有任务执行、事件流、会话管理、日志采集的影响验收标准
sandbox-agent作为运行时方案.codex目录.claude目录