feat(setup): isolate oMo/OpenCode config with OPENCODE_CONFIG_CONTENT

[fro-bot]

Summary

Set OPENCODE_CONFIG_CONTENT as a CI-safe environment variable during setup to enforce consistent, predictable OpenCode behavior across all runs — specifically preventing auto-updates and supporting user-supplied config overrides.

Motivation

OpenCode's config precedence order (from opencode.ai/docs/config/#precedence-order):

1. Remote config (.well-known/opencode)
2. Global config (~/.config/opencode/opencode.json)
3. Custom config (OPENCODE_CONFIG env var)
4. Project config (opencode.json in project)
5. .opencode directories
6. OPENCODE_CONFIG_CONTENT env var — highest priority

The original proposal used OPENCODE_CONFIG_DIR (per-run temp directory) for isolation. However, OPENCODE_CONFIG_DIR is not a config replacement — it adds an extra .opencode-style search path for agents/commands/plugins and does not prevent OpenCode from reading ~/.config/opencode/opencode.json. Additionally, per-run temp directories would break the tools cache (which keys on stable paths → guaranteed cache misses).

OPENCODE_CONFIG_CONTENT is the correct primitive. It has the highest precedence and reliably enforces CI-safe settings regardless of project or global config. This matches the pattern used by OCX, the established OpenCode CLI wrapper.

Implementation

File: src/lib/setup/setup.ts

In runSetup(), after oMo installation, export OPENCODE_CONFIG_CONTENT with CI-appropriate defaults:

// Build CI-safe OpenCode config (highest precedence — wins on all conflicting keys)
const ciConfig = {
  autoupdate: false,
  // Merge user-supplied opencode-config input on top
  ...(inputs.opencodeConfig != null ? JSON.parse(inputs.opencodeConfig) : {}),
}
core.exportVariable('OPENCODE_CONFIG_CONTENT', JSON.stringify(ciConfig))

The existing opencodeConfig field in SetupInputs (already parsed from the opencode-config input) provides user-supplied overrides — no new inputs required for the baseline case.

What NOT to Do

❌ Do not use mkdtempSync() for OPENCODE_CONFIG_DIR:

• Does not isolate ~/.config/opencode/opencode.json (still read at lower precedence)
• oMo installer writes to ~/.config/opencode/ regardless of OPENCODE_CONFIG_DIR
• Per-run paths break the tools cache (guaranteed cache misses)

If OPENCODE_CONFIG_DIR is ever used, it must point to a stable path (not a temp dir).

Considerations

• Configs are merged, not replaced: OPENCODE_CONFIG_CONTENT only wins on conflicting keys. Non-conflicting project-level settings are preserved (e.g., a project's model choice is respected unless explicitly overridden).
• OPENCODE_DISABLE_PROJECT_CONFIG: Future input for untrusted contexts (e.g., fork PRs). Off by default to preserve expected repo behavior.
• Cache unchanged: omoConfigPath = ~/.config/opencode remains stable and continues to be cached as before. No tools cache changes needed.
• OCX precedent: Matches the pattern used by OCX — the established OpenCode CLI wrapper.

Acceptance Criteria

• OPENCODE_CONFIG_CONTENT exported in runSetup() with autoupdate: false as baseline
• User-supplied opencode-config input merged on top of baseline
• OPENCODE_CONFIG_DIR not set to a per-run temp directory
• Tools cache strategy unchanged (stable omoConfigPath = ~/.config/opencode)
• Tests updated to verify OPENCODE_CONFIG_CONTENT is exported with correct content
• Build succeeds (pnpm build)
• All tests pass (pnpm test)

Context

Identified in PR #236 as an improvement for CI reliability. Research conducted in issue comment — OPENCODE_CONFIG_DIR vs OPENCODE_CONFIG_CONTENT analyzed against official docs, OCX source, and reviewed by Oracle.

Scope

• Effort: Small (1 env var export + test update, ~1–4h)
• Risk: Low (OPENCODE_CONFIG_CONTENT only wins on conflicting keys; project configs otherwise preserved)
• Dependencies: None

[marcusrbrown]

@fro-bot research OPENCODE_CONFIG_DIR vs. OPENCODE_CONFIG_CONTENT: https://opencode.ai/docs/config/#precedence-order. Refer to the use case in OCX: https://github.com/kdcokenny/ocx/blob/ed74da6df23a69fc859df579e85a59e2d18d0f1f/packages/cli/src/commands/opencode.ts#L51. Ask Oracle to review your findings and update the issue. ulw

[fro-bot]

Research: OPENCODE_CONFIG_DIR vs. OPENCODE_CONFIG_CONTENT

Researched the OpenCode config docs, the OCX reference implementation, and the current codebase — then asked Oracle to review the findings.

---

Config Precedence Order (from docs)

Config sources loaded in order — later = higher priority:

#	Source	Env Var
1	Remote config (.well-known/opencode)	—
2	Global config (~/.config/opencode/opencode.json)	—
3	Custom config file	OPENCODE_CONFIG
4	Project config (opencode.json in project)	—
5	.opencode directories	—
6	Inline config	OPENCODE_CONFIG_CONTENT ← highest

OPENCODE_CONFIG_DIR does not appear in this table. It is described separately as: "a custom config directory searched for agents, commands, modes, and plugins just like the standard .opencode directory." It slips in between levels 2 and 5, adding an extra .opencode-style search path — it does not replace or suppress ~/.config/opencode/opencode.json.

---

What Each Variable Actually Does

OPENCODE_CONFIG_DIR

• Adds a directory treated like .opencode/ (scanned for agents, commands, modes, plugins)
• Does not prevent OpenCode from reading ~/.config/opencode/opencode.json
• Does not change where the oMo installer writes (~/.config/opencode/ regardless)
• Useful only if you need to supply action-owned file assets from a stable path

OPENCODE_CONFIG_CONTENT

• Injected as the highest-priority config (position 6)
• Overrides all other configs on conflicting keys; non-conflicting project settings are preserved
• No file I/O required — just core.exportVariable('OPENCODE_CONFIG_CONTENT', json)
• This is what OCX uses as its primary config injection mechanism

---

The OCX Pattern

OCX uses three env vars together for complete isolation:

OPENCODE_CONFIG_DIR     = profileDir              // stable dir for file-based assets
OPENCODE_CONFIG_CONTENT = JSON.stringify(config)  // PRIMARY: inline JSON (highest priority)
OPENCODE_DISABLE_PROJECT_CONFIG = "true"          // block project-level opencode.json

OPENCODE_CONFIG_CONTENT is primary. OPENCODE_CONFIG_DIR is secondary, pointing at a stable profile directory — never a per-run temp.

---

Problem with the Original Proposal

The issue proposed:

const configDir = mkdtempSync(join(tmpdir(), 'opencode-config-'))
core.exportVariable('OPENCODE_CONFIG_DIR', configDir)
const omoConfigPath = configDir  // ← also used as tools cache path

Oracle's verdict: misguided for three reasons:

1. OPENCODE_CONFIG_DIR doesn't isolate global config. ~/.config/opencode/opencode.json is still read (it's lower in precedence, but still loaded).
2. oMo writes to ~/.config/opencode/ regardless. OPENCODE_CONFIG_DIR has no effect on where oMo installs its config. The temp dir stays empty.
3. Per-run temp paths break the tools cache. The tools cache key is stable (keyed on version/OS), but the cached path (omoConfigPath) changes every run → guaranteed cache misses.

"Per-run OPENCODE_CONFIG_DIR temp dirs are misguided for 'isolation': they don't stop OpenCode from reading global config and they don't redirect where oMo writes; they also break your tools cache." — Oracle

---

Oracle's Recommendation

1. Use OPENCODE_CONFIG_CONTENT as the primary mechanism — inject { "autoupdate": false } (and merge any user-supplied opencode-config input on top)
2. Drop per-run temp dirs for OPENCODE_CONFIG_DIR entirely — if used at all, must be a stable path
3. Keep tools cache unchanged — omoConfigPath = ~/.config/opencode stays stable and cacheable
4. OPENCODE_DISABLE_PROJECT_CONFIG — add as a future input for untrusted contexts (fork PRs), off by default so repo-level opencode.json is respected normally
5. If "global config drift across runs" becomes a real issue, redirect via XDG_CONFIG_HOME (if OpenCode/oMo honor it) rather than trying to out-prioritize with OPENCODE_CONFIG_DIR

---

Updated Implementation (replaces original proposal)

File: src/lib/setup/setup.ts

// In runSetup(), after oMo installation:

// Build CI-safe baseline config (highest precedence — wins on all conflicting keys)
const ciConfig = {
  autoupdate: false,
  // Merge user-supplied opencode-config input on top
  ...(inputs.opencodeConfig != null ? JSON.parse(inputs.opencodeConfig) : {}),
}
core.exportVariable('OPENCODE_CONFIG_CONTENT', JSON.stringify(ciConfig))

The existing opencodeConfig field in SetupInputs already parses the opencode-config input — no new input needed for basic use.

Updating the issue body now to reflect this.

---

Run Summary

Field	Value
Event	issue_comment
Repository	fro-bot/agent
Run ID	22304247467
Cache	hit
Session	ses_375bbcbfeffem6dOgp2vDzhcOd

[fro-bot]

Closed: implemented and merged via PR #266 which included feat(setup): export OPENCODE_CONFIG_CONTENT for CI-safe OpenCode config isolation. All acceptance criteria met.