opencode loads kimaki-managed config only — project opencode.json::instructions never reaches LLM context

[chubes4]

Summary

On a wp-coding-agents install where runtime=opencode and chat_bridge=kimaki, the project-level opencode.json (written and repaired by lib/repair-opencode-json.py) is not layered into opencode's effective config. Only /root/.kimaki/opencode-config.json (written by Kimaki at startup) is loaded.

Net effect: instructions (Data Machine memory files: SOUL.md, MEMORY.md, USER.md, SITE.md, RULES.md, NETWORK.md) and the DM OpenCode plugins (dm-context-filter.ts, dm-agent-sync.ts) never enter the LLM context window, even though everything on disk is correct and the upgrade script reports opencode.json already correct.

The user reports the exact same site config works on a different machine, so this is environment-sensitive — likely an opencode config-merge behavior difference, but wp-coding-agents cannot rely on it.

Environment

• wp-coding-agents: v0.8.2 (commit 4c35a2eaf6d26f81c2b59baca512d2775415e66b)
• kimaki: kimaki/0.8.1 linux-x64 node-v25.7.0
• opencode: 1.14.33
• OS: Ubuntu (linux), running as root via systemd kimaki.service
• Site: /var/www/extrachill.com (multisite subdomain)
• Runtime detected by upgrade.sh: claude-code (also incorrect — see note below)
• Actual runtime in use: opencode (/usr/lib/node_modules/opencode-ai/bin/.opencode serve)

Reproduction

1. Install wp-coding-agents on a VPS with runtime=opencode, chat_bridge=kimaki.

2. Run ./upgrade.sh to latest. It reports Phase 3b: opencode.json additive repair... opencode.json already correct.

3. Confirm project file is correct:
   ```bash
   python3 -c "import json; d=json.load(open('/var/www/extrachill.com/opencode.json')); print(d['instructions']); print(d.get('plugin'))"
   ```
   Output:
   ```
   ['./wp-content/uploads/datamachine-files/shared/SITE.md',
   './wp-content/uploads/datamachine-files/shared/RULES.md',
   './wp-content/uploads/datamachine-files/agents/extra-chill-bot/SOUL.md',
   './wp-content/uploads/datamachine-files/users/1/USER.md',
   './wp-content/uploads/datamachine-files/agents/extra-chill-bot/MEMORY.md',
   './wp-content/uploads/datamachine-files/network/NETWORK.md']
   ```
   All 6 files exist on disk with content.

4. Inspect the running opencode-serve process:
   ```
   readlink /proc//cwd → /home/opencode
   env OPENCODE_CONFIG → /root/.kimaki/opencode-config.json
   env OPENCODE_PROJECT_ROOT → (unset)
   ```

5. Query opencode's effective config:
   ```bash
   curl -s http://127.0.0.1:/config | jq 'keys'
   ```
   Returns: [\"$schema\", \"agent\", \"command\", \"formatter\", \"lsp\", \"mode\", \"permission\", \"plugin\", \"plugin_origins\", \"skills\", \"username\"]

   No instructions field. No model, provider, small_model. No dm-context-filter.ts / dm-agent-sync.ts in plugin.

   plugin_origins shows only:
   ```json
   [{ "spec": "file:///usr/lib/node_modules/kimaki/dist/kimaki-opencode-plugin.js",
   "source": "/root/.kimaki/opencode-config.json",
   "scope": "global" }]
   ```

The kimaki-managed config has no instructions array and only the kimaki plugin. Per the comment in kimaki/dist/opencode.js:447-450:

OPENCODE_CONFIG (file path) is loaded before project config in opencode's priority chain, so project-level opencode.json can override kimaki defaults.

That layering is not happening for instructions (and isn't happening for plugin, model, etc. either). The project opencode.json is being completely ignored.

Expected

After upgrade, opencode's effective config (queried at runtime) should include:

• instructions: the 6 DM memory file paths from project opencode.json
• plugin: kimaki plugin plus file:///opt/kimaki-config/plugins/dm-context-filter.ts and file:///opt/kimaki-config/plugins/dm-agent-sync.ts
• model / provider / small_model from project file

Actual

Only the kimaki defaults are loaded. DM memory never enters the context window. DM plugins never run, so dm-context-filter strip rules never apply (Kimaki-only prompt sections leak to the agent — the same scenario tests/effective-prompt/run.mjs is supposed to catch).

Why upgrade.sh thinks it's healthy

Phase 3b (lib/repair-opencode-json.py --additive) only inspects the project file at /var/www/extrachill.com/opencode.json and reports opencode.json already correct because that file is correct. The script has no awareness of:

• Whether opencode is actually loading project config (it isn't — cwd=/home/opencode, no OPENCODE_PROJECT_ROOT).
• The kimaki-generated config at \$KIMAKI_DATA_DIR/opencode-config.json that opencode actually loads via OPENCODE_CONFIG.

Suggested fixes (one or both)

1. Detect the layering failure during upgrade.sh verify. Hit http://127.0.0.1:<port>/config (or read /root/.kimaki/opencode-config.json) and confirm instructions and the DM plugins are present. Fail loudly if not. The current verify block only checks file existence on disk.
2. Write instructions and DM plugins into the kimaki-managed config, not (only) the project opencode.json. Since opencode-serve runs with cwd=/home/opencode and never visits the site root, the project file is structurally the wrong place to put these on a Kimaki install. Either:
   • Have repair-opencode-json.py (or a new helper) merge into \$KIMAKI_DATA_DIR/opencode-config.json instead of (or in addition to) the project file, and make the merge persist across kimaki restarts (kimaki currently overwrites that file on every start — see kimaki/dist/opencode.js:497-509).
   • Or coordinate with kimaki upstream so kimaki reads project opencode.json for the active session and merges instructions + plugin into the config it generates.

Option 2 is the real fix; option 1 at least surfaces the failure instead of greenlighting an upgrade that did nothing useful.

Side note

upgrade.sh reports Runtime: claude-code on this install even though the actual running runtime is opencode (opencode-ai/bin/.opencode serve is the live process). Likely the detector triggers on CLAUDE.md existing at the project root (which the upgrade itself creates as a symlink to AGENTS.md). Probably worth a separate issue, but flagging here in case it relates to which config branch is taken.

Diagnostics on request

Happy to attach full `/config` JSON, full `/root/.kimaki/opencode-config.json`, and the project `opencode.json` if needed.

[chubes4]

Related: Phase 7 unconditionally installs opencode-claude-auth wrapper on chat_bridge=kimaki installs

Same install (extrachill.com VPS, runtime=opencode + chat_bridge=kimaki) had a bash wrapper at /usr/lib/node_modules/opencode-ai/bin/opencode (named wp-coding-agents-opencode-wrapper-v2) shimming the npm-shipped binary. The real binary was renamed to .opencode and the wrapper:

1. Read Kimaki's account store (~/.local/share/opencode/anthropic-oauth-accounts.json)
2. Wrote refreshed Anthropic OAuth tokens into ~/.claude/.credentials.json for opencode-claude-auth to consume
3. exec'd the real .opencode binary

The wrapper exists to feed opencode-claude-auth. But runtimes/opencode.sh:260-267 already correctly skips loading opencode-claude-auth when CHAT_BRIDGE=kimaki, with the comment:

Kimaki v0.6.0+ ships a built-in AnthropicAuthPlugin that handles the same concerns (OAuth, token refresh, request/response rewriting, multi-account rotation). Loading both plugins causes them to compete for the same anthropic auth provider in OpenCode. See #51.

So the plugin is correctly skipped, but upgrade.sh::reapply_claude_auth_patch (Phase 7) still calls _install_opencode_wrapper unconditionally (line 664), guarded only by RUNTIME=opencode || CHAT_BRIDGE=kimaki. The wrapper is installed on every kimaki install even though there is no opencode-claude-auth plugin loaded for it to feed. Net effect: the wrapper does useless cred-shimming work and replaces the npm binary with a bash shim, for no benefit.

The user confirms their working laptop install (Studio + Kimaki on macOS) does not have this wrapper — Anthropic OAuth is handled entirely by Kimaki's built-in plugin. The VPS install is the only one that grew the wrapper, presumably because Phase 7 ran and _install_opencode_wrapper doesn't gate on chat_bridge.

Proposed fix

reapply_claude_auth_patch (and _install_opencode_wrapper) should bail when CHAT_BRIDGE=kimaki, mirroring the plugin gate at runtimes/opencode.sh:265. Same logic both places.

Currently:
```
if [ "$RUNTIME" != "opencode" ] && [ "$CHAT_BRIDGE" != "kimaki" ]; then
log "Phase 7: Skipping (runtime is $RUNTIME and chat bridge is $CHAT_BRIDGE)"
return 0
fi
...
_install_opencode_wrapper
```

Should be:
```
if [ "$RUNTIME" != "opencode" ]; then
log "Phase 7: Skipping (runtime is $RUNTIME)"
return 0
fi

if [ "$CHAT_BRIDGE" = "kimaki" ]; then
log "Phase 7: Skipping wrapper + claude-auth patch (Kimaki bridge handles Anthropic OAuth natively)"

Optionally: actively remove a stale wrapper here.

return 0
fi

_install_opencode_wrapper
... reapply patch ...
```

Bonus: actively remove a stale wrapper when CHAT_BRIDGE=kimaki, since previous upgrades may have installed it. Existing kimaki VPS installs (like this one) currently have a wrapper that shouldn't exist.

Manual remediation on this install

```bash
cd /usr/lib/node_modules/opencode-ai/bin
rm opencode opencode.bak.*
ln .opencode opencode # restore real binary as a hardlink
```

After this, opencode --version works, no shim layer, and Kimaki's built-in AnthropicAuthPlugin is the sole auth path (matching the working laptop install).