OPENCODE_DISABLE_PROJECT_CONFIG silences config.instructions from OPENCODE_CONFIG #30233

Summary

Setting OPENCODE_DISABLE_PROJECT_CONFIG=true alongside OPENCODE_CONFIG produces partial config loading: the config file is loaded (its JSON is parsed and merged), but the instructions files it references are silently not resolved. This is worse than completely ignoring the config -- it gives the appearance of working while actually producing incomplete behavior.

Steps to Reproduce

1. Create an opencode.json with relative instruction paths:

{ "instructions": ["AGENTS.md"] }

2. Create an AGENTS.md in the same directory with a recognizable string:

hello-world-123

3. Run with both flags:

export OPENCODE_CONFIG=./opencode.json
export OPENCODE_DISABLE_PROJECT_CONFIG=true
opencode run "what does AGENTS.md say?"

4. The model does not see the instruction content.
5. Remove OPENCODE_DISABLE_PROJECT_CONFIG=true -- it works.

Root Cause

Config loading and instruction resolution are two separate stages. Only the first respects OPENCODE_CONFIG:

Stage 1 -- Config loading (config.ts): The file specified by OPENCODE_CONFIG is loaded correctly regardless of OPENCODE_DISABLE_PROJECT_CONFIG. config.instructions = ["AGENTS.md"]. ✓

Stage 2 -- Instruction resolution (session/instruction.ts): The relative() function gates on OPENCODE_DISABLE_PROJECT_CONFIG:

const relative = Effect.fnUntraced(function* (instruction: string) {
  const ctx = yield* InstanceState.context
  if (!Flag.OPENCODE_DISABLE_PROJECT_CONFIG) {
    return yield* fs.globUp(instruction, ctx.directory, ctx.worktree)
  }
  return yield* fs.globUp(instruction, global.config, global.config)
  //     ↑ restricted to ~/.config/opencode/ -- never finds project files
})

When OPENCODE_DISABLE_PROJECT_CONFIG=true, globUp is restricted to ~/.config/opencode/ only, so project-relative instruction paths resolve to nothing.

Why This Is a Bug

The core issue is partial loading: the config is half-applied. The JSON is parsed and merged, but its instructions silently resolve to nothing. A user or automation that sets both flags gets no error and no indication that instructions were dropped -- the config appears to work, but the model behaves differently than expected.

From a user intent perspective: OPENCODE_CONFIG says "use this config"; OPENCODE_DISABLE_PROJECT_CONFIG says "don't scan for project configs." An explicitly provided config should take priority over implicit discovery blocking -- or at minimum, the conflict should produce a warning rather than silent data loss.

Suggested Fix

When resolving instructions in relative(), check whether the instruction came from an explicitly loaded config (via OPENCODE_CONFIG) and, if so, resolve relative to that config file's directory rather than falling back to global.config.