08 · 安全、分享与团队使用

OpenCode 能读写项目、执行命令、连接模型、调用工具，也能分享会话。这些能力都很实用，但它们本质上也是安全边界。

先把权限当成产品功能

AI coding agent 的权限不是“阻碍效率”，而是让你敢把它放进真实项目。

使用 OpenCode 时，至少要明确：

• 哪些目录可以改。
• 哪些命令可以跑。
• 是否允许联网。
• 是否允许调用 MCP。
• 是否允许分享会话。
• 是否允许读取密钥文件。
• 是否允许发布或部署。

这些规则应该写进项目配置或团队文档，而不是靠每次口头提醒。

分享功能的边界

OpenCode 支持分享会话，生成公开链接。这个能力适合协作和求助，但默认要按“公开泄露风险”处理。

分享前必须检查：

• 对话里是否包含源码片段。
• 是否包含文件路径、客户名、业务数据。
• 是否包含 API key、token、cookie、账号信息。
• 是否包含未公开产品策略。
• 是否包含内部报错日志。

如果不确定，就不要分享。需要协作时，先整理一份脱敏摘要，再分享。

网络访问

网络能力会扩大 agent 的行动范围。它可能访问官方文档、下载依赖、调用外部 API，也可能把本地信息带到不该去的地方。

比较稳的策略：

默认本地优先
需要查官方资料时再临时放开
需要调用内部系统时走明确 MCP 或 API
生产服务写操作必须人工确认

不要让 agent 在没有说明的情况下自由联网排障。

密钥管理

模型 API key、GitHub token、Cloudflare token、数据库连接串都不应该写进仓库配置。

推荐方式：

• 使用环境变量。
• 使用系统 keychain 或 secret manager。
• .env 加入 .gitignore。
• 项目 README 只写变量名，不写真实值。
• 让 agent 修改配置模板，不直接接触真实密钥。

如果 agent 已经读到了真实密钥，不要继续把整段对话分享出去。

团队使用方式

团队使用 OpenCode 时，最有价值的不是每个人都单独配置，而是把公共部分版本化：

opencode.json
.opencode/rules/
.opencode/commands/
.opencode/agents/
README 或 AGENTS.md

这些文件应该回答：

• 这个项目怎么跑测试。
• 常见任务用哪些命令。
• 哪些目录禁止自动改。
• 什么时候必须人工 review。
• 什么时候允许 agent 自主提交 patch。

最小安全基线

把 OpenCode 用进真实项目，至少执行这条基线：

1. 第一次任务只读。
2. 第一次写操作限定单文件。
3. 所有大范围改动先看计划。
4. 涉及密钥、账号、支付、部署、数据删除必须人工确认。
5. 分享会话前默认脱敏。
6. 团队公共配置提交到 Git，个人密钥留在本机。

做到这些，OpenCode 才能从“能跑”进入“能长期使用”。