Repository navigation
Description
Description
Detached spawn chdir($HOME) + config discovery walks to / treating EPERM as fatal with opencode v2.0.21 (macOS arm64); macOS Seatbelt sandbox (w/ nono 0.79.0) granting the project workdir but not $HOME or its ancestors. Both start modes affected (managed background service and --standalone).
Suggested fixes:
spawnServiceContender: pass an explicitcwd(e.g.process.cwd()or a granted dir) so the detached child never needs $HOME access.FSUtil.resolve: catchPermissionDeniedalongsideNotFound— treat unreadable as absent. Makes the ancestor walk safe under any sandbox.- Optionally bound the walk (stop at $HOME) instead of probing candidates at every level to
/.
Plugins
none
OpenCode version
v2.0.21
Steps to reproduce
-
opencode serve --service(or plainopencode) under a profile that doesn't grant $HOME:Error: EPERM: operation not permitted, getcwd '/path/to/project' -> '/Users/<user>' at chdir (unknown) Error: Server process exited with code 1spawnServiceContender(packages/client/src/service-conteder.ts) spawns with{ detached: true, ... }and nocwd; the runtime's detached-spawn path performs an internal chdir targeting $HOME (observed:at chdir, error formattedgetcwd '<cwd>' -> '<home>'). Home-denying sandboxes kill every start at this spawn. -
After granting chdir($HOME), the TUI starts but
/api/locationand/api/fs/list
return 500:PlatformError: Unknown: FileSystem.realPath (/Users/antoine) at FileSystem.resolve at ConfigDiscovery.discover at ServerProcess.start [cause]: Error: EPERM: operation not permitted, lstat '/Users/<user>'ConfigDiscovery.discover(packages/core/src/config/discovery.ts) walks from the project to/(fs.up({ targets: ["."], start: location.directory })), resolving every ancestor dir and five candidate paths per level (.claude,.agents,.opencode,opencode.json[c]).FSUtil.resolve(packages/util/src/fs-util.ts) only catchesNotFound; any other errno isEffect.orDie, so the first unreadable ancestor kills startup with a bare 500.
Screenshot and/or share link
No response
Operating System
macOS 26.7
Terminal
Ghostty
Activity
[-]v2 fails under filesystem sandboxe[/-][+][BUG] v2 fails under filesystem sandboxe[/+]github-actions commentedon Oct 1, 2026
This issue might be a duplicate of an existing issue. Please check:
feat(opencode): add v2 status line plugin
Starefossen commentedon Oct 8, 2026
Also on 2.0.24 under macOS Seatbelt. It is not just the ancestor walk:
discovery.ts:28-32always resolves~/.claudeand~/.agents, so denying read on an existing~/.claudeis enough to get a 500. Allowingfile-read-metadatadoes not help; Bun'srealpathneedsfile-read-data.Fix: treat
PermissionDeniedlikeNotFoundinFSUtil.resolve(fs-util.ts:105-111), as skill scanning already does (compatibility.ts:43).Happycoil commentedon Oct 15, 2026
Still exists in 2.0.29. One-line repro:
Tarquinen commentedon Oct 20, 2026
This was fixed by #55817. It mentioned this issue as related rather than closing it, so GitHub didn't close it automatically. Closing as completed. If you still see this on the latest OpenCode, please open a new issue with details.
— from 𝕺𝖕𝖊𝖓𝕮𝖔𝖉𝖊
antoinetanzilli-cure51 commentedon Oct 20, 2026
Confirmed using
2.1.0, it works! Thanks!