macOS沙盒应用无法直接创建或管理容器，因其受内核强制限制，仅能运行在自身entitlements定义的权限范围内；真正的容器需在沙盒外由Docker Desktop、Lima等工具管理，并通过NSOpenPanel授权、security-scoped bookmarks及合规进程启动方式与沙盒应用交互。
macOS 沙盒环境下，应用本身不能直接创建或管理容器——沙盒机制禁止应用自行启动进程、挂载文件系统或操作底层资源。所谓“容器”，在 macOS 生态中通常指两类完全不同的技术：一类是 Apple 原生的 App Sandbox（即应用级沙盒），另一类是第三方运行时环境（如 Docker、Lima 虚拟机）所管理的隔离执行单元。二者不可混用，也不能由沙盒应用直接控制。
App Sandbox 是系统强制的运行环境，不是可编程容器
macOS 的 App Sandbox 是内核级访问控制技术，由代码签名和 entitlements 文件共同定义。它不提供 API 让应用“创建新沙盒”或“启动子容器”。一个已签名的沙盒应用只能在自身权限范围内运行，其生命周期由系统统一管理（启动、挂起、终止均由 macOS 决定）。你无法在沙盒应用内部调用 docker run 或 limactl start，除非该应用明确声明并获得了对应 entitlements（如 com.apple.security.network.client 和 com.apple.security.temporary-exception.files.absolute-path.read-write），但后者仅限调试，Mac App Store 审核严禁使用。
真正可管理的“容器”必须在沙盒外运行
如果你需要容器化能力（比如运行 AI 工具、隔离代码执行），正确做法是将容器运行时（Docker Desktop、Lima、Podman）部署在用户空间的非沙盒环境中，并通过合规方式与沙盒应用交互：
- 沙盒应用可通过
NSWorkspace.shared.launchApplication启动外部容器工具（需用户授权） - 数据交换必须走安全路径：例如用
NSOpenPanel获取用户选择的文件夹，再通过目录映射（mount）传入虚拟机或容器 - 命令行调用需经
Security-Scoped Bookmarks持久化授权，每次访问前调用startAccessingSecurityScopedResource() - 避免让沙盒应用直接执行 shell 脚本调用
docker—— 这会因权限缺失失败，且违反沙盒设计原则
生命周期管理必须由宿主系统或外部服务承担
容器的创建、启动、停止、销毁等操作，本质上属于系统级任务，不在沙盒应用职责范围内：
- 容器镜像拉取、配置、资源限制设置，应由独立 CLI 工具（如
cowork或codex-cli/scripts/run_in_container.sh）完成 - 若使用 Lima 虚拟机沙盒（如 VMCowork），其生命周期由
limactl管理，沙盒应用只负责发起请求并等待结果 - 日志与状态监控建议通过标准输出重定向 + 文件监听实现，而非尝试注入容器内部进程
- 所有清理动作（如删除临时卷、释放端口）应在容器退出后由外部脚本触发，不能依赖沙盒应用主动回收
安全边界必须清晰，不可模糊“沙盒”与“容器”的概念
常见误区是把 App Sandbox 当作 Docker 一样的可编程隔离层。实际上：
- App Sandbox 是静态策略（entitlements 决定你能做什么），容器是动态实例（runtime 决定你正在做什么）
- 沙盒应用可以调用网络 API，但不能监听端口 —— 除非声明
com.apple.security.network.server并通过审核 - 容器内进程不受 macOS 沙盒约束，但它对主机的访问仍受虚拟化层或容器引擎限制（如 Docker 的 cgroups、Lima 的 QEMU 隔离）
- 敏感操作（如读取剪贴板、访问摄像头）需分别在沙盒 entitlements 和容器配置中双重授权，缺一不可
