Security on tsvinc

Lock OpenCode 2.x to your self-hosted model

Mon, 02 Nov 2026 00:00:00 +0000

Two config lines make OpenCode 2.x send prompts only to your self-hosted OpenAI-compatible model, and a self-contained script proves which model a headless run picks.

Tested on: OpenCode V2 (npm @opencode/cli) 2.2.5, headless opencode run, throwaway HOME, first in a container with no network, then with the PoC below behind a dead proxy (2026-11-02). The no-model case was also run on 2.2.0.
Not verified: the interactive TUI, a fresh install's first-run screens, 2.2.1 to 2.2.4, a config with both lines at once, "model" alone with the local server down, a full personal config.
Needs: an opencode 2.x binary, a local OpenAI-compatible model server already configured as a provider (one way: /guides/serve-local-models-to-opencode-llama-router/), python3 for the PoC. No opencode.ai account and no API key.
Time: about 10 min, my estimate, not timed (the PoC caps each of its three runs at 60 s).
Risk: low. You edit one config file after copying it; the PoC points HOME and the four XDG_* directories it sets (config, data, state, cache) at a mktemp -d directory and starts a server on 127.0.0.1:18765 for the length of the run.

Before you start#

Placeholders used below:
- <CONFIG>: your global OpenCode config file. The PoC writes its own as $XDG_CONFIG_HOME/opencode/opencode.json inside a throwaway HOME, so on a default setup this is ~/.config/opencode/opencode.json.
- <PROVIDER_ID>: the key of your local provider under "provider" in <CONFIG>. The PoC uses local.
- <MODEL_ID>: the key of your model under that provider's "models". The PoC uses qwen-local.
- <OPENCODE_BIN>: path to the opencode 2.x binary; the PoC defaults to opencode on PATH.
Check the version with <OPENCODE_BIN> --version. Mine printed opencode v2.2.5 (it is also the PoC's first output line).
Back up the config before step 3:
```
cp <CONFIG> <CONFIG>.bak
```

My agent guardrails passed every test. Then I used them.

Mon, 02 Nov 2026 00:00:00 +0000

Assumes you've set up a terminal coding agent's permission rules, or wondered what a model sees when they say no.

For weeks, the only user my test suites knew was a fake model. The suites cover my configuration templates for six terminal coding agents (OpenCode in two major versions, V1 and V2, plus pi, omp, Hermes Agent and Claude Code): each one runs local models and refuses destructive commands even with nobody approving. Every suite drove them with a scripted fake model in a container with no network. It was an ideal user: it ran exactly the command the test told it to, it never improvised, and it never once wanted a screenshot of anything.

OpenCode didn't want an account. It wanted a model name.

Mon, 02 Nov 2026 00:00:00 +0000

Assumes you've pointed a terminal coding agent at a model you serve yourself.

The warning reached me second-hand, the way the most confident warnings travel. Don't install a fresh OpenCode 2.x if you run your own models, it said: the new version won't talk to a self-hosted model until you activate an account on opencode.ai and pay for a subscription, and it asks for an API key on your very first prompt. A second message came along with it, an AI assistant's explanation, and that one had a mechanism: fresh installs now default to OpenCode's own hosted model, the switch that turns the hosted provider off is fairly new and may not work, and in that case there's a third-party plugin, installed globally with npx.

The leak scan found me in my own guard's tests

Mon, 02 Nov 2026 00:00:00 +0000

Publishing a private repository as a single orphan commit sounds like the safe kind of open source. No history goes out, so nothing buried in the history can leak: you choose the files, you commit them once, you push. It's the plan that looks best on a whiteboard, and that is exactly why I didn't let it go out on its own.

The repository holds my hardened configuration templates for six terminal coding agents that run on local models (OpenCode V1 and V2, pi, omp, Hermes Agent, Claude Code), plus the guard code that stops them running destructive commands. It's public now, under MIT, as one commit. On the first builds, the checks I'd put in front of that commit, plus one review of the plan, found six things. Each pointed at a real defect, two of them in the scanner itself. One of them was me, by name, in the test cases of that guard.

Another guard's test list found holes in mine

Sat, 31 Oct 2026 00:00:00 +0000

Builds on My guard blocked bash -c. Models write bash -lc., which explains the guard this post tests.

Comparing two guards for coding agents sounds like a code review: read theirs, read mine, note the differences, nod. I walked in with the posture of a visiting inspector. It turned into the best test run my guard has had, none of the test cases came from my own list, and the inspection went the other way.

Confine a coding agent's HTTPS to an allowlist with bwrap

Sat, 31 Oct 2026 00:00:00 +0000

Run a command (a coding agent, a build, a shell) in a bubblewrap sandbox whose only way out is HTTPS through a small proxy on the host that lets through the hosts on your list and refuses the rest.

Tested on: Fedora Linux 44 (KDE), kernel 7.2.13-200.fc44.x86_64, bubblewrap 0.12.0, Python 3.14.8, curl 8.18.0, Node.js v22.23.1 (2026-10-31).
Not verified: running a coding agent inside the sandbox. The test commands were curl, Python, bash and Node's fetch, run from a test script.
Needs: Linux with bubblewrap (bwrap) and Python 3; curl for the tests. No root. Node.js for the two fetch checks only.
Time: not timed. The scripted re-run of the whole procedure, failure captures included, took 3 s (13:44:32 to 13:44:35); that is script speed, not the time to set this up by hand.
Risk: low and reversible. Nothing outside the working directory and the project directory changes, and the proxy runs as your user. The project directory is mounted read-write, so the command inside can change or delete files there.

Before you start#

Check the tools. My run:

$ bwrap --version; python3 --version; curl --version | head -1; /usr/bin/node --version; uname -r; grep PRETTY_NAME /etc/os-release
bubblewrap 0.12.0
Python 3.14.8
curl 8.18.0 (x86_64-redhat-linux-gnu) libcurl/8.18.0 OpenSSL/3.5.9 zlib/1.3.1.zlib-ng brotli/1.2.1 libidn2/2.3.8 libpsl/0.21.5 libssh/0.12.2/openssl/zlib nghttp2/1.68.0 ngtcp2/1.22.1 nghttp3/1.18.0 mit-krb5/1.22.2 OpenLDAP/2.6.15
v22.23.1
7.2.13-200.fc44.x86_64
PRETTY_NAME="Fedora Linux 44 (KDE Plasma Desktop Edition)"

Pick a working directory for the scripts. Every command below runs from it, and the proxy's files go in run/ under it. In the output below it is shown as /home/user/egress.
Placeholders, used only in step 8:
- <PROJECT_DIR>: the directory the sandboxed command may read and write. It appears as /work inside.
- <AGENT>: the command to run in the sandbox.
- <INSTALL_DIR>: the directory the agent is installed in, if it is not under /usr.
Back up or commit <PROJECT_DIR> before you run anything in it: the sandbox mounts it read-write.

How it fits together, from the two scripts:

An exception in one layer deleted a block in another