[FEATURE]: allowed_folders config + dev networking improvements (for restricted/remote dev use)

[wufei-png]

We use OpenCode internally and have implemented two small improvements that make our workflow easier. We’d like to ask whether the maintainers would be interested in having this in upstream; if so, we’ll refactor the code and open a PR.

1. allowed_folders config option

• What: An optional config field allowed_folders (array of strings, supports ~ for home). When set, the folder picker, recent projects list, and directory-picker results are filtered so users can only see and select projects under these roots.
• Why: In multi-user environments where a single service is exposed on a shared machine, limiting accessible directories ensures proper isolation between users and prevents unauthorized access to system or other users’ data).
• Where: Config schema, folder picker component, home recent list, and layout “choose project” flow all respect this list; SDK types updated.

2. Dev networking ergonomics

• What:
  • When VITE_OPENCODE_SERVER_HOST is not set in dev, the web app uses location.hostname (and existing port) to connect to the OpenCode server, so accessing the app at e.g. http://ip:3000 automatically connects to http://ip:4096.
  • Vite dev server host/port configurable via VITE_HOSTNAME and VITE_PORT (e.g. to bind to a specific LAN IP).
  • Server-side CORS allows origins from private LAN IP ranges (10.x, 192.168.x, 172.16–31.x) so the web app can be used from another machine on the same network.
• Why: We often run the server on one machine and open the web UI from another; this avoids manually setting VITE_OPENCODE_SERVER_HOST and fixes CORS for LAN access.
• Docs: CONTRIBUTING updated with the above behavior and examples.

Reference implementation

We have a working implementation in our fork. If this direction fits upstream, we can clean up the code (e.g. shared util for allowed_folders resolution and filtering) and open a PR here, and we can link to our fork’s PR for an early look:

• Fork PR: Wf/dev wufei-png/opencode#1

Happy to adjust scope or implementation to match upstream preferences (e.g. naming, defaults, or splitting into two PRs: one for allowed_folders, one for dev networking). Thanks for maintaining OpenCode.

[github-actions]

Thanks for the detailed feature proposal! This issue is well-structured and compliant with our guidelines.

---

Related existing issues that may be of interest:

• [FEATURE]: Limit tool (e.g. write, edit) permissions to specific folders #6318: [FEATURE] Limit tool (e.g. write, edit) permissions to specific folders — focuses on restricting tool permissions
• [FEATURE]: Add per-agent filesystem boundaries (allow/deny paths) + optional run-as user for bash #5529: [FEATURE] Add per-agent filesystem boundaries (allow/deny paths) — proposes broader per-agent access control
• [FEATURE]: ACP over WebSocket for remote/network access #13388: [FEATURE] ACP over WebSocket for remote/network access — related to remote development scenarios
• [FEATURE]: Support for custom web app proxy URL in firewalled environments #12445: [FEATURE] Support for custom web app proxy URL in firewalled environments — another angle on restricted network environments

Your proposal is distinct in addressing both UI-level folder filtering and dev networking ergonomics. The reference implementation in your fork should be helpful for discussion.

[wufei-png]

action search is better than human