Jump to content

Opencode isolation and burner workflow 260216: Difference between revisions

From Game in the Brain Wiki
No edit summary
No edit summary
Line 345: Line 345:
'''Cause:''' This is a "Nest Isolation" conflict. Firejail is trying to create a sandbox inside a container that has already virtualized the system files.
'''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.
'''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.
=== "WARN: failed to kill all processes / cgroup not exist" ===
When stopping a container, you may see this scary warning:
<pre>
WARN[0000] failed to kill all processes... error="cgroup not exist"
u260217
</pre>
'''Verdict:''' It worked. This is a common warning in rootless containers where Distrobox cannot access the deep system-level "cgroups" to force-kill background processes. The fact that the container name (e.g., u260217 or opencode-burner) is printed on the last line indicates the container stopped successfully.

Revision as of 14:45, 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.

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 tokensTokens (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

Choose your preferred method.

Option A: Command Line (Recommended)

1. Install Distrobox

HOST TERMINAL

curl -s https://raw.githubusercontent.com/89luca89/distrobox/main/install | sudo sh

2. Create the Burner Container

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 TERMINALCONTAINER TERMINAL

Run this to step inside. Your prompt will change.

distrobox enter opencode-burner

Option B: BoxBuddy (GUI Users)

WARNING: By default, BoxBuddy shares your real home directory. You must explicitly change this setting during creation, or you are not isolated.

Open BoxBuddy and click the + (Create) button.

Name: opencode-burner

Image: ubuntu:24.04

Home Directory: Click the File icon. Navigate to and select your created opencode_burner_data folder. Do not leave this blank.

Click Create.

Once created, click the Terminal Icon (right side) to enter the box.

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

9. Save Your Work & Create Base Image (Optional)

Persistence: Since we used the --home flag, all your code and configs are already saved on your Host Machine in ~/opencode_burner_data. You can delete the container, and your files remain safe.

Creating a "Golden Image": To avoid reinstalling Node/Git/OpenCode for the next burner, save this container as a base image.

IMPORTANT: You must exit the container first! distrobox is a tool installed on your host, not inside the box.

1. Leave the container FIRST

exit

Your prompt should change (e.g., from justin@u260216 back to justin@host)

2. Stop the container (Run this on HOST)

CLI User:

distrobox stop opencode-burner

BoxBuddy User: Click the "Stop" (Square) button.

3. Save as a new image (Use 'podman' or 'docker')

Note: BoxBuddy does not currently support 'commit'. You MUST use the terminal for this step.

podman commit opencode-burner opencode-golden-image

Future Usage:

Spin up a new burner instantly using your saved image

distrobox create --name burner-v2 --image opencode-golden-image --home ~/new_project_data

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.

"WARN: failed to kill all processes / cgroup not exist"

When stopping a container, you may see this scary warning:

WARN[0000] failed to kill all processes... error="cgroup not exist"
u260217

Verdict: It worked. This is a common warning in rootless containers where Distrobox cannot access the deep system-level "cgroups" to force-kill background processes. The fact that the container name (e.g., u260217 or opencode-burner) is printed on the last line indicates the container stopped successfully.