support loading config from env var

[kagbodji]

Short description

allow using different models for different opencode profiles

What problem does this solve?

I run two opencode profiles, one for work and one for personal stuff. I use magic-context for both. the problem is I cannot use different models for the historian / dreamer / sidecar between the two profiles. I tried using a project-level config, but that blocks overriding the models. what I would like is something similar to opencode's OPENCODE_CONFIG=, where I can specify which config to use for magic-context / AFT.

Proposed solution

an environment variable MAGIC_CONTEXT_CONFIG=, that can be used to override the default / project config when starting opencode.

Alternatives considered

project-level config: blocks changing model:

## ⚠️ Magic Context Config Warning

Some configuration values are invalid and were replaced with defaults:

- [project config] Ignoring historian.model from project config (security: historian model selection is user-level only; a repository cannot force extra compaction cost).

Check your `magic-context.jsonc` to fix these values.

(I understand preventing repos from forcing arbitrary models, so this will probably not change)

Area

OpenCode plugin

Additional context

No response

[alfonso-magic-context]

Thanks — the general form of this (an env-selected config file) unfortunately fights Magic Context's durable state model, so we won't take it as proposed. The config isn't only behavioral: several fields are folded into durable identity shared across every process that touches a project. Two OpenCode profiles alternating on the same project with different configs would fight through the shared store — the embedding provider/model resolves to one vector-space identity per project (alternating providers means guard trips or full re-embed churn), the system-prompt surface hash is part of the prompt-cache key (every profile switch on a session would force a hard rebuild of the cached prefix), and mode records like compaction.enabled are boot-resolved into durable per-session state (disagreeing profiles would flap modes).

What we would accept is the scoped version, which covers the use case you actually describe (different historian/dreamer models per profile): an env-selected overlay file carrying only per-run model selection — historian/dreamer/sidekick models with their variants/thinking levels, in the per-harness shape landing in the next release — with identity-bearing fields (embedding, storage, compaction, memory, prompt surface, thresholds) excluded by schema, the same discipline we apply to repository-level config.

If that shape works for your setup, say so here — that's the signal we'd build it on.