Opencode isolation and burner workflow 260216: Difference between revisions
Justinaquino (talk | contribs) No edit summary |
Justinaquino (talk | contribs) No edit summary |
||
| Line 8: | Line 8: | ||
'''Simpler than Claude Code:''' | '''Simpler than Claude Code:''' | ||
This workflow is significantly more streamlined than typical Claude Code isolation setups. | This workflow is significantly more streamlined than typical Claude Code isolation setups. We rely on '''Distrobox Custom Homes''' instead of Firejail for stability. | ||
'''No Re-Authentication Loop:''' Unlike Claude, which often forces you to re-login via browser or copy keys every session, this container '''persists''' your "Burner Identity" (Git credentials & Configs). | '''No Re-Authentication Loop:''' Unlike Claude, which often forces you to re-login via browser or copy keys every session, this container '''persists''' your "Burner Identity" (Git credentials & Configs). | ||
| Line 18: | Line 18: | ||
'''The Loop:''' | '''The Loop:''' | ||
'''Spin up''' a fresh Arch/Ubuntu container. | '''Spin up''' a fresh Arch/Ubuntu container with a '''Custom Home'''. | ||
'''Inject''' the necessary tools (NodeJS, Git, OpenCode CLI | '''Inject''' the necessary tools (NodeJS, Git, OpenCode CLI). | ||
'''Mount''' only the target project. | '''Mount''' only the target project. | ||
| Line 134: | Line 134: | ||
</syntaxhighlight> | </syntaxhighlight> | ||
=== 2. Create the Burner Container === | === 2. Create the Burner Container (The "Clean Room" Method) === | ||
'''HOST TERMINAL''' | '''HOST TERMINAL''' | ||
We create a container with a '''custom home directory'''. This is the key isolation step. | |||
On your host, this folder will be <code>~/opencode_burner_data</code>. | |||
Inside the container, this folder will be seen as <code>/home/username</code>. | |||
The AI '''cannot''' see your real SSH keys or Documents because they literally do not exist in this folder. | |||
<syntaxhighlight lang="bash"> | <syntaxhighlight lang="bash"> | ||
distrobox create --name opencode-burner --image ubuntu:24.04 | |||
Create the storage folder on your host first | |||
mkdir -p ~/opencode_burner_data | |||
Create the container mapped to this folder | |||
distrobox create --name opencode-burner --image ubuntu:24.04 --home ~/opencode_burner_data | |||
</syntaxhighlight> | </syntaxhighlight> | ||
| Line 151: | Line 166: | ||
</syntaxhighlight> | </syntaxhighlight> | ||
=== 4. Install Dependencies | === 4. Install Dependencies === | ||
'''CONTAINER TERMINAL''' | '''CONTAINER TERMINAL''' | ||
Now that you are ''inside'', install the necessary tools. | Now that you are ''inside'', install the necessary tools. We no longer need Firejail. | ||
'''For Ubuntu 24.04:''' | '''For Ubuntu 24.04:''' | ||
<syntaxhighlight lang="bash"> | <syntaxhighlight lang="bash"> | ||
sudo apt update && sudo apt install -y nodejs npm git build-essential python3 | sudo apt update && sudo apt install -y nodejs npm git build-essential python3 | ||
</syntaxhighlight> | </syntaxhighlight> | ||
| Line 167: | Line 182: | ||
<syntaxhighlight lang="bash"> | <syntaxhighlight lang="bash"> | ||
sudo npm install -g opencode | sudo npm install -g opencode-ai | ||
</syntaxhighlight> | </syntaxhighlight> | ||
| Line 235: | Line 250: | ||
<code>Ctrl</code> + <code>X</code> (Exit). | <code>Ctrl</code> + <code>X</code> (Exit). | ||
=== 7. Create | === 7. Create Workspace === | ||
'''CONTAINER TERMINAL''' | '''CONTAINER TERMINAL''' | ||
<syntaxhighlight lang="bash"> | <syntaxhighlight lang="bash"> | ||
mkdir -p ~/opencode_workspace | mkdir -p ~/opencode_workspace | ||
| Line 245: | Line 259: | ||
</syntaxhighlight> | </syntaxhighlight> | ||
=== 8. Launch | === 8. Launch OpenCode === | ||
'''CONTAINER TERMINAL''' | '''CONTAINER TERMINAL''' | ||
Because we isolated the entire home directory in Step 2, we don't need complex Firejail commands. The AI is already in a padded cell. | |||
<syntaxhighlight lang="bash"> | <syntaxhighlight lang="bash"> | ||
opencode | |||
</syntaxhighlight> | |||
== Part 5: Automated Launcher (Optional) == | |||
If you get tired of typing <code>distrobox enter</code> every time, you can use the <code>launch_burner.sh</code> script (provided separately) from your '''HOST TERMINAL'''. It handles the context switching automatically. | |||
== Troubleshooting == | |||
=== "Failed to mount /sys" or Immediate Exit === | |||
If you try to run Firejail inside Distrobox, you may see: | |||
<pre> | |||
Warning: failed to mount /sys | |||
Child process initialized in 91.91 ms | |||
(Prompt returns immediately) | |||
</pre> | |||
'''Cause:''' This is a "Nest Isolation" conflict. Firejail is trying to create a sandbox inside a container that has already virtualized the system files. | |||
'''Fix:''' Use the "Clean Room" method (Part 4, Step 2). This creates a container where the ''entire'' home directory is fake, so you don't need Firejail to protect your files—they simply aren't there. | |||
Revision as of 13:20, 17 February 2026
OpenCode "Burner" Workflow & Hardware Reality Check
This guide establishes a Distrobox-based isolation workflow for running OpenCode. This prevents AI agents from accidentally modifying your host system files and allows you to "nuke" the environment if it gets corrupted or compromised.
Part 1: The "Burner" Philosophy
The Goal: Run OpenCode in a disposable container (opencode-burner) that shares only specific project folders, not your entire home directory.
Simpler than Claude Code: This workflow is significantly more streamlined than typical Claude Code isolation setups. We rely on Distrobox Custom Homes instead of Firejail for stability.
No Re-Authentication Loop: Unlike Claude, which often forces you to re-login via browser or copy keys every session, this container persists your "Burner Identity" (Git credentials & Configs).
Zero Boot Time: Distrobox shares your host kernel. There is no VM overhead; it launches instantly.
One-Step Launch: You don't need to manually start a Docker daemon, attach a shell, and then run a binary. The launcher script handles the context switch automatically.
The Loop:
Spin up a fresh Arch/Ubuntu container with a Custom Home.
Inject the necessary tools (NodeJS, Git, OpenCode CLI).
Mount only the target project.
Burn it (delete the container) when the project is done or the environment gets messy.
Part 2: The Hardware Reality (VRAM is the Limit)
Running local coding agents requires massive Context Windows. Codebases are large. The standard 4k or 8k context is useless for an agent reading multiple files.
The Golden Rule: You need at least 32k Context for a usable agent.
GPU Tier List (Discrete VRAM)
| GPU Class | VRAM | Price (PHP) | Practical Limit | Verdict |
|---|---|---|---|---|
| RX 7600 | 8 GB | ~₱18,000 | 8k - 16k (32k Unstable) |
Entry Level. 8GB is the hard floor. You can run a 7B model, but 32k context "sometimes works" and often crashes (OOM) because the OS + Model leaves almost no room for the cache. |
| RX 9070 XT | 16 GB | ~₱50,000 | 64k (Unstable) | The Danger Zone. 16GB is tight. You can force a 64k context, but it requires creating a custom Modelfile and is unstable. The model weights (~5GB) + OS (~4GB) leave little room for the KV cache. Expect OOM crashes.
|
| RX 7900 XT | 20 GB | ~₱80,000 | 64k - 80k | The Sweet Spot. That extra 4GB VRAM is crucial. It creates enough headroom to run a quantized 7B or 14B model with a healthy 64k context window comfortably. |
| Workstation (e.g., W7800/R9700) |
32 GB | High | 128k+ | The AI King. Required if you want to run full 128k context locally. 32GB VRAM allows for uncompressed cache or running larger parameters (e.g., 32B models) with decent context. |
Unified Memory & Workstation Architectures (Massive Capacity, Slower Speed)
Use these if you need to run Huge Models (70B, 405B) that won't fit on any consumer GPU.
Trade-off: While capacity is massive, Tokens Per Second (T/s) is significantly lower (slower generation) compared to the Discrete GPUs above due to lower memory bandwidth.
| System / Chip | RAM (Unified) | Est. Cost (PHP) | Capability | Verdict |
|---|---|---|---|---|
| AMD Ryzen AI Max+ PRO 395 (Strix Halo) |
128 GB (allocates ~112GB to AI) |
~₱135,000 (Framework/MiniPC) |
Llama 3 70B @ Q8 DeepSeek V2 Lite |
The Compact Beast. Allows running 70B models comfortably. Excellent value for capacity, but slower inference than a dGPU. |
| Apple Mac Studio (M3/M4 Ultra) |
Up to 512 GB | ~₱400,000 - ₱600,000+ (Max Config) |
Llama 3 405B @ Q4 DeepSeek V3 671B |
The Whale. One of the few ways to run "Frontier" models locally. Extremely expensive and slower generation speeds, but unparalleled privacy for massive models. |
Recommended High-Context Models
Select the model that fits your GPU tier.
7-8 Billion Parameter Models (Best for 12GB - 16GB VRAM)
Qwen2.5-Coder-7B-Instruct: The current gold standard. Supports up to 128k natively. Excellent for bug fixing and large codebase understanding on consumer hardware.
YaRN-Mistral-7b-64k: Specifically configured for 64k context using the YaRN extension method. Benchmarks show stable perplexity at long lengths.
OpenCodeReasoning-Nemotron-7B: Supports 64k context. Excels specifically at reasoning tasks for code generation.
14-16 Billion Parameter Models (Best for 20GB - 24GB VRAM)
Qwen2.5-Coder-14B-Instruct: The heavy hitter. Supports 128k natively. Provides significantly more capacity for complex, multi-file project analysis and agentic workflows than the 7B version.
DeepCoder-14B-Preview: Supports 64k context. Uses reinforcement learning to achieve performance comparable to much larger proprietary models.
The "DeepSeek V3" Alternative
Before spending ₱80k on hardware, consider the DeepSeek API.
Context: 64k (Output) / 128k (Input) natively.
Intelligence: DeepSeek V3 (671B MoE) is vastly smarter than any local Qwen 7B/14B.
Cost: ~₱7.80 ($0.14) per 1 Million tokens.
Strategy: Use Local 7B for small, private edits. Use DeepSeek V3 for "Build" agent tasks requiring long context.
Part 3: GitHub Burner Identity
Agents need to pull/push code. Do not give them your main GitHub credentials (SSH keys) that have access to your private company/client repos.
The Strategy:
Start by testing with your main account (carefully) to verify the tool works.
IMMEDIATELY switch to a Burner GitHub Account for daily agentic work.
Generating a Token (PAT): You cannot use a simple password for Git over HTTPS. You need a Personal Access Token.
Log in to your Burner GitHub Account.
Click your Profile Picture (top right) → Settings.
Scroll to the very bottom left sidebar → Developer settings.
Click Personal access tokens → Tokens (classic).
Click Generate new token (classic).
- Note: You may be asked for 2FA or Email authentication.
Scopes: Select repo (Full control of private repositories) and workflow.
Expiration: Set to 90 days. (This is fine; we want these to expire so we don't leave loose ends).
Copy the token immediately. You will not see it again.
Inside the Burner Container: When OpenCode asks for Git authentication, use your Burner Username and paste this Token as the password.
Part 4: Setup Instructions (Manual / "Claude Style")
Use this method if you prefer to enter the terminal first and run commands manually.
1. Install Distrobox
HOST TERMINAL
curl -s https://raw.githubusercontent.com/89luca89/distrobox/main/install | sudo sh
2. Create the Burner Container (The "Clean Room" Method)
HOST TERMINAL
We create a container with a custom home directory. This is the key isolation step.
On your host, this folder will be ~/opencode_burner_data.
Inside the container, this folder will be seen as /home/username.
The AI cannot see your real SSH keys or Documents because they literally do not exist in this folder.
Create the storage folder on your host first
mkdir -p ~/opencode_burner_data
Create the container mapped to this folder
distrobox create --name opencode-burner --image ubuntu:24.04 --home ~/opencode_burner_data
3. Enter the Container
HOST TERMINAL → CONTAINER TERMINAL
Run this to step inside. Your prompt will change.
distrobox enter opencode-burner
4. Install Dependencies
CONTAINER TERMINAL
Now that you are inside, install the necessary tools. We no longer need Firejail.
For Ubuntu 24.04:
sudo apt update && sudo apt install -y nodejs npm git build-essential python3
5. Install OpenCode
CONTAINER TERMINAL
sudo npm install -g opencode-ai
6. Configure OpenCode (Manual Edit)
CONTAINER TERMINAL
We need to manually edit the config file. Since we are in a minimal terminal, we use nano.
Open the file:
mkdir -p ~/.config/opencode
nano ~/.config/opencode/opencode.json
Nano Shortcuts to Clear File: If the file already has content, use this sequence to clear it quickly:
Alt + : Go to the very first line (Top).
Alt + A : 'Mark' the text (Start selection).
Alt + / : Go to the very last line (End).
Ctrl + K : Cut/Remove the selected text.
Paste the Configuration:
Copy the JSON below and paste it into the terminal (usually Ctrl+Shift+V or Right Click).
{
"provider": {
"ollama": {
"npm": "@ai-sdk/openai-compatible",
"name": "Ollama Local",
"options": {
"baseURL": "http://127.0.0.1:11434/v1"
},
"models": {
"qwen2.5-coder:7b": { "name": "Qwen 2.5 Coder (7B)" }
}
},
"deepseek": {
"npm": "@ai-sdk/openai-compatible",
"name": "DeepSeek API",
"options": {
"baseURL": "https://api.deepseek.com/v1",
"apiKey": "sk-YOUR_API_KEY"
},
"models": {
"deepseek-chat": {
"name": "DeepSeek V3 (Fast & Smart)"
},
"deepseek-reasoner": {
"name": "DeepSeek R1 (Thinking Model)"
}
}
}
}
}
Save and Exit:
Ctrl + O (Write Out/Save) -> Press Enter to confirm.
Ctrl + X (Exit).
7. Create Workspace
CONTAINER TERMINAL
mkdir -p ~/opencode_workspace
cd ~/opencode_workspace
8. Launch OpenCode
CONTAINER TERMINAL
Because we isolated the entire home directory in Step 2, we don't need complex Firejail commands. The AI is already in a padded cell.
opencode
Part 5: Automated Launcher (Optional)
If you get tired of typing distrobox enter every time, you can use the launch_burner.sh script (provided separately) from your HOST TERMINAL. It handles the context switching automatically.
Troubleshooting
"Failed to mount /sys" or Immediate Exit
If you try to run Firejail inside Distrobox, you may see:
Warning: failed to mount /sys Child process initialized in 91.91 ms (Prompt returns immediately)
Cause: This is a "Nest Isolation" conflict. Firejail is trying to create a sandbox inside a container that has already virtualized the system files. Fix: Use the "Clean Room" method (Part 4, Step 2). This creates a container where the entire home directory is fake, so you don't need Firejail to protect your files—they simply aren't there.