Why Sandbox OpenCode?
OpenCode has full access to your filesystem and can run arbitrary commands. Without isolation:- It could access files outside your project directory
- A malicious prompt or compromised dependency could exfiltrate credentials
- Unintended writes could affect configuration or system files
Quick Start
- Read+write access to the current working directory
- Read+write access to
~/.config/opencode(configuration) - Read+write access to
~/.cache/opencode(cache) - Read+write access to
~/.local/share/opencode(data) - Read+write access to
~/.local/share/opentui(OpenTUI parser/runtime data) - Read+write access to
/tmp(temp files) - Network access enabled (required for AI provider API calls)
The profile grants access to
/tmp because opencode writes temp files directly to $TMPDIR with dynamic filenames (e.g., {timestamp}.md for editor buffers, opencode-clipboard.png for clipboard images). Landlock cannot grant access to files with unpredictable names without granting the parent directory.Custom Profile
Create~/.config/nono/profiles/opencode.json for different permissions:
Security Tips
Use Secrets Management
Load your AI provider API key from the system keystore instead of environment exports: macOS:Read-Only Mode
For reviewing code without allowing modifications:Restrict to a Specific Project
Overriding Profile Settings
CLI flags always take precedence:Known Issues
Google Gemini Proxy Credential Injection
OpenCode routes Google Gemini requests directly to the Google API rather than through a configurable base URL. This means proxy-based credential injection does not work with Gemini models. Only environment variable injection is supported. Use--env-credential instead of proxy injection when working with Gemini: