OpenCode V2 官方文档说明：默认共享后台服务为当前用户账号管理会话、配置、集成、权限和工具执行。因此，OpenCode 2.0 多人共用 Mac 不能把“各自打开客户端”当成隔离证明；未验证账号、目录、凭证和服务访问边界前，不要让多人通过同一个 macOS 用户会话处理不同课题组项目。（OpenCode V2 CLI 文档）
谁该看：课题组负责人，正在决定多人是否共用一台 Mac 运行 OpenCode 2.0。
实验室管理员，需要审查账号、服务和项目目录边界。
研究软件开发者，准备从个人环境迁移到团队可访问的 Mac 环境。
最后更新于 2026 年 11 月 3 日；我们复核了 OpenCode V2 CLI、权限、远程服务文档及官方版本变更记录。官方变更记录列有 2026 年 10 月 30 日发布的 V2 版本更新；部署前仍应核对机器上实际安装的版本及对应文档。
OpenCode 2.0 多人共用 Mac：后台服务不提供隔离证明
先把“共用”拆成三种情况。风险不取决于几个人坐在同一台机器前，而取决于他们是否共用同一个操作系统身份或服务实例。
- 多人轮流登录同一个 macOS 用户：OpenCode 服务、用户目录、可访问文件和该账号拥有的凭证可能落在同一权限范围内。不能把客户端窗口分开当成系统隔离。
- 多人各用独立 macOS 账号：系统账号和主目录可以分开管理，但还要检查共享文件夹、账号权限、远程服务连接目标，以及是否有人共用同一服务凭证。
- 多人连接同一个 OpenCode 服务：客户端连到同一服务时，必须确认该服务实际管理的会话、配置与工具执行范围。不同客户端本身不能证明各自拥有独立服务状态。
官方文档把默认共享后台服务描述为当前用户账号使用的服务，并提供 --standalone 启动私有服务、--server 连接指定服务等方式。这能说明服务如何选择，不能据此推断多人共用同一 macOS 账号时可以互相隔离。
共享后台服务会管理哪些会话与配置？
OpenCode 共享后台服务管理会话、配置、集成、权限和工具执行；客户端只是连接到服务的入口。对于科研 Mac 多用户隔离，管理员至少要分别确认：当前登录的 macOS 用户是谁、客户端连接到哪个服务、会话列表属于谁、OpenCode 配置文件由谁读取。
我们建议在测试记录中保存以下结果，而不是凭桌面窗口或账号显示名作判断：
- 终端执行
whoami、echo "$HOME"，记录系统用户名与主目录。 - 执行
opencode service status，确认服务状态和实际连接地址。 - 分别启动正常模式、
opencode --standalone，比较看到的会话和设置；不要在含敏感数据的项目里做首次验证。 - 用
opencode debug paths查看 OpenCode 配置、数据库等路径，再确认这些文件由哪个系统用户拥有、谁有读写权限。
OpenCode 官方配置文档描述了配置与权限规则的设置方式；不同版本的配置结构可能不同，尤其不要把旧版本的配置键直接复制到 V2。发布前请对照当前 V2 配置说明。
多人共用 Mac 跑 OpenCode，会看到彼此项目吗？
有可能，但不能仅凭共用一台物理 Mac 或使用不同客户端得出结论。会话管理和文件系统权限是不同层面：服务会管理会话；工具执行则可能读取或修改服务所在机器上、当前用户能够访问的文件。OpenCode V2 权限文档明确提醒，Shell 命令使用主机用户的文件系统、进程和网络权限（权限说明）。
项目目录选错、多个课题组共用一个工作副本、不同会话指向相同路径，都会增加改动交叉的可能。Git 分支也不等于访问控制：多个工作树能让同一仓库并行检出不同分支，但仍共享仓库中的部分数据与管理信息。Git 官方 git worktree 说明也列出了不同工作树共用仓库数据的边界。
在测试仓库里按下面步骤验收，再决定能否处理真实课题代码：
- 创建不含真实数据、密钥或个人信息的临时仓库。
- 为两个测试用户分别登录，记录各自的账号、主目录和服务连接地址。
- 在各自终端中启动 OpenCode，确认工作路径；不要只看会话标题。
- 在一个测试项目里创建标记文件，再检查另一个账号是否能列出、读取或修改它。
- 分别创建分支或工作树，检查会话实际工作目录、Git 状态和文件变化位置。
- 退出客户端后重新登录，复查会话列表与最近使用路径；把结果和安装版本一并记录。
如果任一用户能读取不该接触的目录，或两边的修改落入同一工作副本，就先停止真实项目验证。改用独立系统账号、单独目录，并重新确认 OpenCode 连接到的服务实例。
权限和凭证必须落到操作系统边界
OpenCode 的 ask、allow、deny 等规则控制工具能否执行某项操作，但它们不等同于 macOS 的用户隔离。权限配置过宽、Shell 命令执行范围过大，或多个人共用一个账号下的环境变量，都可能让项目密钥和提供商凭证落入共同的可访问范围。
按以下顺序审查，避免只检查应用内的权限弹窗：
- 检查
opencode.json、opencode.jsonc和全局配置里的 Shell、读取、编辑及外部目录规则。特别确认是否存在过宽的通配规则。 - 在测试环境中确认拒绝规则生效，并检查是否有更高优先级或后续规则改变了结果。V2 文档说明规则按顺序组合，最后匹配的规则会影响结果。
- 检查启动服务时继承的环境变量、终端配置、SSH 密钥，以及模型或提供商凭证的存放方式；不要把真实密钥放进共享仓库或通用脚本。
- 在 macOS 系统设置中为不同使用者建立独立账号，并确认不是所有人都拥有管理员权限。Apple 的新增 Mac 用户说明列出管理员、标准和仅共享等账号类型；文件共享说明也指出管理员账号可能访问整台 Mac。
- 检查研究数据目录和密钥文件的权限。macOS 的文件与文件夹权限说明区分可读、可写和无权访问；共享目录不能仅因“账号不同”就被视为隔离。
如果成员必须共用同一系统账号，至少应把凭证、项目目录和服务访问做独立边界验证；做不到时，不要把 OpenCode 应用权限当成补偿控制。
OpenCode 2.0 远程服务如何限制访问？
先辨认连接属于本机、局域网还是外网。OpenCode V2 远程服务文档说明，默认监听本机地址；允许远程连接则需要明确启用（远程服务说明）。配置监听到所有网络接口、开放来源或建立外网访问，会扩大服务暴露面，因此不能把“设置了密码”直接等同于已通过机构安全审查。
有几个可核验的参数，适合直接纳入运维记录：
- 配对链接只能使用一次，有效期为 5 分钟。
- 配对后的会话可持续 30 天；更改服务密码会使已有会话退出。
- 官方文档列出的 macOS 默认服务端口是 49374；实际地址应通过
opencode service status核对，而不是从旧记录复制。
按这份检查清单做远程连接验收：
- [ ] 记录服务监听地址、端口、客户端目标地址和实际登录用户。
- [ ] 确认是否启用了远程服务、全接口监听或额外跨域来源；未审批的配置保持关闭。
- [ ] 使用测试账号验证未授权设备无法连接，并确认密码没有写入仓库、公开日志或共享脚本。
- [ ] 从外部网络检查真实访问路径；若使用 SSH 转发，验证连接只经过预期通道。
- [ ] 明确谁能创建配对、谁保管服务密码，以及退出成员访问时如何撤销连接。
官方说明可帮助核对服务设置，却不能代替课题组对数据分类、网络访问和机构审批要求的判断。具体版本的行为也应根据实际安装版本及官方发布记录复核。
两张表，确定团队环境的隔离级别
| 使用方式 | 能确认的边界 | 主要残余风险 | 建议 |
|---|---|---|---|
| 多人轮流用同一个 macOS 账号 | 账号身份与主目录相同 | 会话、配置、凭证与文件权限可能重叠 | 不用于不同课题组的敏感项目，除非已逐项验证并获准 |
| 独立 macOS 账号、各自启动服务 | 系统用户可区分；需确认文件和服务配置 | 共享目录、管理员权限或共用服务凭证仍可能造成交叉 | 先做双账号读写与会话验收 |
| 多人连接同一个 OpenCode 服务 | 客户端连接目标相同 | 服务管理的会话和工具执行范围可能被共享 | 只在确认服务端隔离策略后使用 |
| 各自使用独立主机或环境 | 主机与账号边界更清晰 | 数据传输、密钥、机构规则仍需管理 | 对敏感或相互独立的课题组优先评估 |
| 验收项 | 通过条件 | 未通过时的回退动作 |
|---|---|---|
| 系统账号 | 每人身份可识别，非必要人员无管理员权限 | 拆分账号并收紧权限 |
| 服务目标 | 能明确证明每个用户连接到哪个 OpenCode 服务 | 停用共享连接，改用独立服务 |
| 项目目录 | 测试用户无法读写不属于自己的项目 | 拆目录、重设权限或隔离主机 |
| 凭证与命令 | 密钥不在共用环境中裸露，敏感命令有审查边界 | 撤销共享凭证并改用独立密钥 |
| 远程访问 | 监听范围、认证、来源和撤销方式均有记录 | 关闭远程访问，完成审批后再启用 |
课题组应该共用账号还是拆分账号？
按下面的条件分支决定，不要把“一台 Mac”当成唯一选项：
- 若只有一名使用者，且项目与凭证均归该用户管理：可先验证 OpenCode 默认服务和本机目录，再投入真实工作。
- 若多人共用主机，但账号、会话、目录和凭证都能分别验证：可以评估独立 macOS 账号与各自服务；在测试读写边界通过前，不纳入真实数据。
- 若多人需要连接同一个 OpenCode 服务：只有在确认会话可见范围、权限规则、服务密码管理及退出访问流程后，才考虑共享服务。
- 若不能证明项目或凭证边界，或数据规则不允许共用：回退到独立账号、独立服务，必要时使用独立主机环境。远程 macOS 课题组环境只是部署方式，不自动提供隔离或合规保证。
需要检查远程主机接入时，可先参考我们的SSH 与 VNC 连接说明。如果课题组确认需要一台可交互的远程 Mac，再核对远程 Mac 的交付方式及可选租用方案。这适合临时测试 macOS 专属软件或补充实验室缺少的 Mac 环境；但共享的 Linux 或 Windows 远程主机不能替代原生 macOS 验证，而租用一台主机也不会自动解决多人账号、凭证和数据隔离问题。若团队长期持续重负载，或依赖本地物理接口，优先评估自有 Mac；若只是短期需要可交互的 macOS 测试环境，再把远程租赁纳入比较。