You signed in with another tab or window. Reload to refresh your session.You signed out in another tab or window. Reload to refresh your session.You switched accounts on another tab or window. Reload to refresh your session.Dismiss alert
{{ message }}
Repository navigation
Server answers 500 when an optional discovery path (~/.claude, ~/.agents, ancestors' .opencode, ...) cannot be opened #58142
opencode v2.0.32, macOS (reproduced under sandbox-exec; any EPERM on these paths behaves the same)
Summary
At startup the server runs ConfigDiscovery.discover, which calls FileSystem.resolve (realPath) on:
the config dir, ~/.claude and ~/.agents, and
every ancestor directory of the working directory up to /, and inside each ancestor, .claude, .agents, .opencode, opencode.json and opencode.jsonc.
resolve only tolerates NotFound. Any other error, such as EPERM from a sandbox, fails the whole request. The TUI then exits with a message that does not name the path:
UnknownError: An error occurred in Effect.tryPromise
[cause]: ClientError: UnexpectedStatus: 500
The real cause is only in opencode.log:
PlatformError: Unknown: FileSystem.realPath (/Users/<me>/.claude)
[cause]: Error: EPERM: operation not permitted, lstat '/Users/<me>/.claude'
at ConfigDiscovery.discover ... at ServerProcess.start
and without the deny ((allow default) only) it prints No authenticated integrations.
With a deny-default profile that grants the home dir but not the probed paths, the failure moves along as each path is granted (~/.claude, then ~/.agents, then ~/.opencode, then each ancestor directory of the project such as ~/source/github.com), until every existing path in the list is openable.
Expected
A discovery path that exists but cannot be opened should be skipped and logged, not fail the server. These are optional compatibility locations (Claude/agent skills, project-local config), not required files.
Also
The error shown to the user should name the failing path instead of a bare Effect.tryPromise.
OPENCODE_DISABLE_CLAUDE_CODE=1 and OPENCODE_DISABLE_CLAUDE_CODE_SKILLS=1 do not avoid this, so there is currently no way to opt out of the probe.
Impact
Anything that runs OpenCode under a deny-default sandbox (macOS Seatbelt, Landlock-style wrappers, locked-down CI) cannot start the TUI unless it predicts and grants every ancestor of the project plus the names above. Granting only file-read-data on the paths themselves is enough, so there is no need to read their contents.
Thanks for the detailed report and the minimal sandbox-exec repro!
I think this is a duplicate of #52458. It is the same failure: config discovery runs FSUtil.resolve on ~/.claude, ~/.agents and each ancestor's .opencode/.claude/.agents/opencode.json(c), and an EPERM there made the server return 500.
This was fixed in #55817, where FSUtil.resolve now treats permission denials (including macOS sandbox EPERM that surfaces as Unknown) like missing paths. That change is in v2.1.0 and later, but not in v2.0.32, which you are running. Could you upgrade and try your repro again?
Possible duplicates and related issues, ordered by likelihood:
The bot will close this issue as a duplicate in 1 day unless you reply explaining how your problem is different, for example if it still happens on v2.1.x. If it's only the error message (that it should name the failing path), that would be best as its own small issue.
Closing as completed. This optional-path discovery failure was fixed by #55817, and current code tolerates access denials during discovery. The report used v2.0.32; please upgrade to v2.1.0 or later and open a new report if a current version still reproduces the problem.
We haven't heard back in the day since my last comment, so I'm closing this as a duplicate of #52458.
The fix in #55817 treats EPERM/permission denials during config discovery like missing paths. It shipped in v2.1.0, after the v2.0.32 you reported against, so upgrading should get the TUI starting under your sandbox-exec profile.
If it still fails on v2.1.x, please reply here with the version and the opencode.log error, and we can reopen. The suggestion that the startup error should name the failing path would also be welcome as its own issue.
Activity
opencode-agent commentedon Oct 22, 2026
Thanks for the detailed report and the minimal
sandbox-execrepro!I think this is a duplicate of #52458. It is the same failure: config discovery runs
FSUtil.resolveon~/.claude,~/.agentsand each ancestor's.opencode/.claude/.agents/opencode.json(c), and anEPERMthere made the server return 500.This was fixed in #55817, where
FSUtil.resolvenow treats permission denials (including macOS sandboxEPERMthat surfaces asUnknown) like missing paths. That change is in v2.1.0 and later, but not in v2.0.32, which you are running. Could you upgrade and try your repro again?Possible duplicates and related issues, ordered by likelihood:
/treatsEPERMas fatal (macOS Seatbelt via nono)The bot will close this issue as a duplicate in 1 day unless you reply explaining how your problem is different, for example if it still happens on v2.1.x. If it's only the error message (that it should name the failing path), that would be best as its own small issue.
neriousy commentedon Oct 23, 2026
Closing as completed. This optional-path discovery failure was fixed by #55817, and current code tolerates access denials during discovery. The report used v2.0.32; please upgrade to v2.1.0 or later and open a new report if a current version still reproduces the problem.
opencode-agent commentedon Oct 23, 2026
We haven't heard back in the day since my last comment, so I'm closing this as a duplicate of #52458.
The fix in #55817 treats
EPERM/permission denials during config discovery like missing paths. It shipped in v2.1.0, after the v2.0.32 you reported against, so upgrading should get the TUI starting under yoursandbox-execprofile.If it still fails on v2.1.x, please reply here with the version and the
opencode.logerror, and we can reopen. The suggestion that the startup error should name the failing path would also be welcome as its own issue.