Repository navigation
Windows: startup fails with EPERM lstat 'C:\' when the drive root is unreadable (AppContainer) #53508
Description
Description
On Windows, OpenCode exits at startup when the process cannot read the attributes of the drive root:
Error: Unexpected error EPERM: operation not permitted, lstat 'C:\'
This happens in a Windows AppContainer without capabilities that has been granted only the project folder, and in any other process without read-attributes on C:\.
Cause: Filesystem.resolve (packages/opencode/src/util/filesystem.ts) and FSUtil.resolve (packages/core/src/fs-util.ts) call the JS realpathSync. Bun's Windows implementation (ported from Node) lstats the drive root and then every ancestor of the path. Only ENOENT is caught, so the EPERM on C:\ is rethrown. The TUI (resolveThreadDirectory) and opencode run call this first, and instance-store.ts, project.ts and plugin/shared.ts call it later.
realpathSync.native opens only the target path and succeeds in the same process.
Related: #52458 reports the same class of failure on macOS v2 (FSUtil.resolve through Effect's realPath).
Plugins
none
OpenCode version
1.18.34 (also current dev)
Steps to reproduce
- Start
opencode.exein an AppContainer with no capabilities, with grants on the project folder and the binary only. - OpenCode exits with
EPERM: operation not permitted, lstat 'C:\'.
Minimal check with a Bun 1.3.14 compiled executable in the same AppContainer: realpathSync(<granted folder>) throws EPERM ... lstat 'C:\'; realpathSync.native(<granted folder>) returns the path.
Screenshot and/or share link
No response
Operating System
Windows 11 Pro 10.0.26200
Terminal
Windows pseudo console (not terminal-specific)
Activity
github-actions commentedon Oct 6, 2026
This issue might be a duplicate of an existing issue. Please check:
FSUtil.resolvetreatsEPERMwhile traversing an unreadable ancestor as fatal in a filesystem sandbox.The Windows AppContainer and drive-root scenario here may be distinct, but the underlying
EPERM/ancestor-resolution failure appears closely related.changazo commentedon Oct 18, 2026
Native canonicalization follow-up
Reproduced this on 1.19.3 rebuilt with Bun 1.4.2. Source maps locate the first
failure at
InstanceStore.load -> FSUtil.resolve -> realpathSync. An actual-helpercontrol compiled with Bun 1.4.3 still fails; this is not a full 1.4.3 ACP run.
#55817 explicitly leaves Windows untested. Its sync fallback can also return an
unresolved string for a genuinely denied root.
Minimal source-level probe:
cwd/workspacecontaininginside.txtwithsynthetic, arealdirectory, and analiasjunction targetingreal.granting only the fixture/runtime, without network capability or root access.
physical path. With the Windows-native correction, visible/physical/alias/
repeated resolution succeeds; missing-path fallback remains and the truly
denied root throws.
After the sync correction, a separate Effect callback
realpathfails in thesame environment: Effect-TS/effect#9489. The combined
release backport passes a synthetic ACP/MCP proposal journey; that is not a
current-dev end-to-end claim. No drive-root ACL grant or global filesystem shim
is involved.
opencodejr commentedon Oct 27, 2026
Thanks for the detailed report and root-cause analysis!
Version
1.18.34is OpenCode v1, which only gets fixes for critical bugs, so this is unlikely to be fixed there. The files you point to (packages/opencode/src/util/filesystem.ts,instance-store.ts,project.ts,plugin/shared.ts) are v1 code and are no longer ondev.OpenCode v2 (
@opencode/cli) has already changed this, in #55817:FSUtil.resolve(inpackages/util/src/fs-util.ts) now catchesEPERM/EACCESfromrealpathSyncas well asENOENT/ENOTDIR, and the Effect version treats permission denials like not-found, falling back to the unresolved path.realpathSync.native.So an
EPERMonC:\should no longer stop v2 at startup. Please try upgrading to v2. Until then, granting read-attributes on the drive root avoids the error on v1.Related: #52458, the same problem on macOS v2 under a filesystem sandbox.
If this still happens on v2, or you think it's critical for v1, please reply here with details.
opencodejr commentedon Oct 28, 2026
Closing this as not planned. It was reported on v1 (
1.18.34), which only gets fixes for critical bugs, and we haven't heard that it also happens on v2. In v2,FSUtil.resolveno longer fails onEPERM/EACCES(#55817), so startup in an AppContainer should get past thelstat 'C:\'error. Thanks again for the detailed analysis! If you still see this on OpenCode v2 (@opencode/cli), please open a new issue with the v2 version and the error output.