[atornsii]

This runs the setup agent in a macOS sandbox. The agent runs shell commands without approvals, and OpenCode's rules limit only its file tools. In a test run without the sandbox, the agent searched the whole disk with find /, read files in another repo, and read the ldcli access token with ldcli config get.

What changed

• On macOS, ldcli starts OpenCode with sandbox-exec and a Seatbelt profile that it writes for each run. The sandbox applies to OpenCode and to every command that it runs.
• The profile denies the home folder. It opens the project and OpenCode's own folders for reading and writing, package caches for writing, and toolchains and ~/.gitconfig for reading. If XDG_CONFIG_HOME is set, only its opencode folder opens. System folders and the network stay open.
• The profile uses resolved paths, because Seatbelt matches the real path behind a symlink, such as /var/folders.
• OpenCode's rules also deny ldcli and npx skills.
• A cache or OpenCode folder can be missing on first use. The profile allows only the creation of its missing parent folders, and nothing else can be written in them.
• The Go settings file (~/Library/Application Support/go/env, or the file that GOENV names) opens for reading, so Go commands use the user's GOPROXY and GOPRIVATE.
• The sandbox resolves the home folder before the install folder check, so a symlink in HOME cannot make it open all of ~/.local.

Linux and Windows run without a sandbox for now.

Two review points were checked and need no change. The firmlink path /System/Volumes/Data/Users/<name> is denied too, because Seatbelt checks the resolved path. And sandbox-exec reads its profile before it applies the sandbox, so a profile in a denied folder still loads.

Testing

A macOS test runs real sandboxed commands with a fake home folder: they read and write in the project, and they get "Operation not permitted" for a fake ldcli config, an SSH key, and another repo's file. Other real sandbox tests check the creation of missing cache folders and a home path with a symlink. Unit tests cover the profile order, quoting, the Go settings file, and the install folder rule. The real OpenCode starts in the sandbox.

Diagram

flowchart TD
  oc["opencode.go from #894<br/>Start"]:::earlier
  cfg["opencode_config.go<br/>deny ldcli*<br/>deny npx skills*"]:::chg
  srv["server.go<br/>startServer<br/>box.Cleanup on stop"]:::chg
  sb["sandbox.go<br/>sandboxCommand<br/>buildSandboxPaths, installDir<br/>realPath, seatbeltProfile"]:::new
  prof[["ldcli-agent-*.sb<br/>deny home<br/>allow project, caches"]]:::ext
  sbx[["/usr/bin/sandbox-exec"]]:::ext
  proc[["opencode serve<br/>and every shell command"]]:::ext
  oc -->|openCodeConfig| cfg
  oc -->|startServer| srv
  srv -->|sandboxCommand| sb
  sb -.->|writes profile| prof
  srv -->|exec box.Name, box.Args| sbx
  sbx -.->|reads -f| prof
  sbx -->|runs inside| proc
  classDef new fill:#e6f0fa,stroke:#1d6fb8,stroke-width:2px,color:#19202b
  classDef chg fill:#fbf1e1,stroke:#a86a12,stroke-width:2px,color:#19202b
  classDef earlier fill:#ffffff,stroke:#7a8494,stroke-dasharray:5 4,color:#19202b
  classDef ext fill:#eceefa,stroke:#4e5a9c,stroke-width:2px,color:#19202b

Loading

Blue boxes are new files, orange boxes are changed files, dashed boxes are files from an earlier PR, and purple boxes are outside ldcli. A solid arrow goes from the caller to the code that it calls. A dashed arrow shows data that moves without a direct call.

server.go now asks sandbox.go how to start OpenCode. sandboxCommand builds the lists of open folders, resolves symlinks, writes the Seatbelt profile to a temporary .sb file, and returns a sandbox-exec command. server.go runs that command, so OpenCode and every command that it runs get the same file rules. When the run stops, server.go removes the profile. On Linux and Windows, sandboxCommand returns the plain OpenCode command. opencode_config.go also denies ldcli and npx skills.

This PR changes only how server.go from #894 starts the process. The adapter interface and the wizard from #895 do not change.

Stack

This is one of seven PRs for the ldcli setup agent. Review and merge them in order, after #877 (Go 1.26):

1. feat(setup): add an OpenCode adapter for the setup agent (1/7) #894 OpenCode adapter
2. feat(setup): add the setup agent step to the wizard (2/7) #895 Wizard agent step
3. feat(setup): run the setup agent in a macOS sandbox (3/7) #896 macOS sandbox
4. feat(setup): read the setup agent config through the gonfalon relay (4/7) #897 AI SDK and relay
5. feat(setup): run the setup agent through the Go AI SDK with an OpenCode handler (5/7) #898 OpenCode handler
6. fix(setup): fix the agent sandbox and give the agent more facts (6/7) #899 Run fixes
7. feat(setup): send the agent's model calls to a LaunchDarkly Bedrock relay (7/7) #930 Bedrock model routing

The gonfalon side is launchdarkly/gonfalon#75196 to #75199 (the SDK relay) and launchdarkly/gonfalon#75426 (the model relay). This stack replaces #876 and #878, which are closed.

🤖 Generated with Claude Code

---

Note

Overview
On macOS, the setup agent now launches OpenCode through sandbox-exec with a per-run Seatbelt profile so every shell command inherits filesystem limits, not just OpenCode’s file tools.

sandbox.go builds a deny-home profile with targeted read/write exceptions (project dir, package caches, OpenCode state, toolchain paths), resolves symlinks for Seatbelt, writes a temp *.sb file, and returns a cleanup hook. server.go uses that wrapper when starting opencode serve and removes the profile on start failure or process exit. Linux/Windows still run the binary directly when sandboxing isn’t available.

OpenCode bash rules also deny ldcli* and npx skills* so the agent can’t invoke the CLI or skills installer from the shell. Tests cover profile ordering, path allowlists, and real sandboxed reads/writes on macOS.

^{Reviewed by Cursor Bugbot for commit f08f4d1. Bugbot is set up for automated code reviews on this repo. Configure here.}