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
OPENCODE_CONFIG_DIR is broken since 0.15.30 when only world-readable #3610
We use OPENCODE_CONFIG_DIR=/etc/opencode which is only world readable.
Each user has his own ~/.config/opencode/ directory. Here we can see the package.json which is gets generated and used by opencode.
Since 0.15.30 we have the following error when we start opencode:
Error: Unexpected error, check log file at /home/opencode/.local/share/opencode/log/2025-10-31T140216.log for more details
EACCES: permission denied, open '/etc/opencode/package.json'
path: "/etc/opencode/package.json",
syscall: "open",
errno: -13,
code: "EACCES"
at write (unknown:1:1)
at installDependencies (src/config/config.ts:164:17)
at processTicksAndRejections (unknown:7:39)
Former versions work fine. Fresh setup creates the ~/.config/opencode/package.json and opencode starts.
0.15.30 throws this error.
This issue might be a duplicate of existing issues. Please check:
[FEATURE]:global configuration /etc/opencode #3410: This feature request specifically discusses global configuration support in /etc/opencode and mentions configuration data should be searchable in both /etc/opencode and ~/.config/opencode/. Your use case aligns closely with what was requested in that issue.
@rekram1-node I used Qwen 3 for analysis (i hope this helps) - result:
Root Cause
The issue is in the installDependencies function in packages/opencode/src/config/config.ts at line 150 - link:
if(!(awaitBun.file(pkg).exists())){awaitBun.write(pkg,"{}")// This fails for read-only directories }
When OpenCode loads a custom config directory via OPENCODE_CONFIG_DIR, it attempts to create a package.json file in that directory. If the directory is read-only (like /etc/opencode with 755 permissions), this write operation fails.
Relevant Commit
Concurrent Dependency Installation (commit c1ada30): Changed installDependencies calls to run concurrently using Promise.all for performance improvements
Solution
The installDependencies function should check directory write permissions before attempting to create files, or should handle permission errors gracefully when working with user-specified config directories.
maybe?!:
+ // Check if we have write permissions to the directory
+ try {
+ await fs.access(dir, fs.constants.W_OK)
+ } catch {
+ // If we don't have write permissions, skip installing dependencies
+ log.debug("skipping dependency installation due to lack of write permissions", { path: dir })
+ return
+ }
Activity
github-actions commentedon Oct 31, 2025
This issue might be a duplicate of existing issues. Please check:
/etc/opencodeand mentions configuration data should be searchable in both/etc/opencodeand~/.config/opencode/. Your use case aligns closely with what was requested in that issue.OPENCODE_CONFIGenvironment variable, which is related to yourOPENCODE_CONFIG_DIRusage.Feel free to ignore if none of these address your specific case.
rekram1-node commentedon Oct 31, 2025
hm ill take a look
qwertologe commentedon Nov 8, 2025
@rekram1-node I used Qwen 3 for analysis (i hope this helps) - result:
Root Cause
The issue is in the
installDependenciesfunction inpackages/opencode/src/config/config.tsat line 150 - link:When OpenCode loads a custom config directory via
OPENCODE_CONFIG_DIR, it attempts to create apackage.jsonfile in that directory. If the directory is read-only (like/etc/opencodewith 755 permissions), this write operation fails.Relevant Commit
Concurrent Dependency Installation (commit c1ada30): Changed
installDependenciescalls to run concurrently usingPromise.allfor performance improvementsSolution
The
installDependenciesfunction should check directory write permissions before attempting to create files, or should handle permission errors gracefully when working with user-specified config directories.maybe?!:
rekram1-node commentedon Nov 8, 2025
Yeah that looks fine, if u want u can open a pr and ill merge it since u found the issue, otherwise i can knock it out. Lmk ur preference @qwertologe
qwertologe commentedon Nov 8, 2025
@rekram1-node I really don't know if this is a good solution - maybe it would be better to fallback to project folder, ...
I would really be glad if you can take over from here.
rekram1-node commentedon Nov 8, 2025
sure will do thx @qwertologe just wanted to give u a chance to get the "credit" haha