False positive OMO conflict disables Magic Context with oh-my-opencode-slim

[dhaern]

Short description

False positive OMO conflict detection disables Magic Context when using oh-my-opencode-slim

What happened?

Magic Context disables itself with an OMO conflict warning when oh-my-opencode-slim is installed, even though this is not the real oh-my-opencode / OMO plugin and does not provide the conflicting OMO context-management hooks.
Example OpenCode config:

{
  "plugin": [
    "@cortexkit/opencode-magic-context@latest",
    "oh-my-opencode-slim"
  ],
  "compaction": {
    "auto": false,
    "prune": false
  }
}

The same happens with a local checkout:

{
  "plugin": [
    "@cortexkit/opencode-magic-context@latest",
    "file:///home/user/workspace/oh-my-opencode-slim-dev"
  ]
}

Magic Context reports that it is disabled due to conflicting OMO hooks such as:

• oh-my-opencode preemptive-compaction
• oh-my-opencode context-window-monitor
• oh-my-opencode anthropic-context-window-limit-recovery
  This is a false positive.
  oh-my-opencode-slim is a separate slimmed-down plugin:
  https://github.com/alvinunreal/oh-my-opencode-slim
  Its package name is:
  "name": "oh-my-opencode-slim"
  So a normal npm/plugin entry like:
  "oh-my-opencode-slim"
  or:
  "oh-my-opencode-slim@latest"
  will match Magic Context’s current substring-based OMO detection.
  The false positive appears to come from this logic:

const hasOmo = plugins.some(
  (p) =>
    p.includes("oh-my-opencode") ||
    p.includes("oh-my-openagent") ||
    p.includes("@code-yeongyu/"),
);

Because oh-my-opencode-slim contains oh-my-opencode, Magic Context classifies it as OMO.
Then, if no OMO config file exists, disabledHooks is empty and Magic Context assumes all OMO conflicting hooks are active:
result.preemptiveCompaction = !disabledHooks.has("preemptive-compaction");
result.contextWindowMonitor = !disabledHooks.has("context-window-monitor");
result.anthropicRecovery = !disabledHooks.has("anthropic-context-window-limit-recovery");
Expected behavior:
Magic Context should not disable itself just because a plugin name/path contains the substring oh-my-opencode.
Suggested fixes:

1. Match known OMO package/plugin entries more strictly.
2. Explicitly exclude oh-my-opencode-slim.
3. Only assume OMO hooks are active when a real OMO plugin/config is detected.
4. Optionally add an allowlist/ignore mechanism for compatible forks or slim variants.

Diagnostics

Magic Context version: 0.15.2
OpenCode version: 1.14.24
Platform: Ubuntu 24.04 LTS aarch64
Client: OpenCode TUI (CLI)
OpenCode plugin config:

[
  "@cortexkit/opencode-magic-context@latest",
  "oh-my-opencode-slim"
]

Alternative local plugin config that triggers the same issue:

[
  "@cortexkit/opencode-magic-context@latest",
  "file:///home/user/workspace/oh-my-opencode-slim-dev"
]

OpenCode compaction config:

{
  "auto": false,
  "prune": false
}

No real OMO config files are present:
- ~/.config/opencode/oh-my-opencode.json
- ~/.config/opencode/oh-my-opencode.jsonc
- ~/.config/opencode/oh-my-openagent.json
- ~/.config/opencode/oh-my-openagent.jsonc
The slim plugin does not define these OMO conflict hooks:
- context-window-monitor
- preemptive-compaction
- anthropic-context-window-limit-recovery

Plugin version

0.15.2

OpenCode version

1.14.24

Platform

Ubuntu 24.04 LTS aarch64

Client

OpenCode TUI (CLI)

Log output (optional)

Magic Context is disabled due to conflicting configuration:
- oh-my-opencode preemptive-compaction hook is active
- oh-my-opencode context-window-monitor hook is active
- oh-my-opencode anthropic-context-window-limit-recovery hook is active

Additional info

Separately, #42 appears to have been closed too narrowly, but that is a different issue. This report is specifically about a false-positive OMO conflict caused by broad substring matching against oh-my-opencode-slim.

[ualtinok]

Fixed in v0.15.3.

Confirmed your diagnosis by cloning oh-my-opencode-slim — it ships none of preemptive-compaction, context-window-monitor, or anthropic-context-window-limit-recovery. The substring matcher p.includes("oh-my-opencode") was treating any fork name containing that substring as canonical OMO, then checkOmoHooks defaulted all three hooks to active because slim has no OMO config — producing the false warning.

Replaced the substring matchers with canonical npm-name matching (oh-my-opencode, oh-my-openagent) that strips version suffixes and skips path/URL forms. Forks with different package names — slim, cli, custom forks under any other name — no longer trigger the conflict path.

16 regression tests cover the exact failure modes from your report (slim with and without version suffix, file:// paths, mixed canonical+fork installs).

To upgrade and clear the stale plugin cache:

bunx --bun @cortexkit/opencode-magic-context@latest doctor --force

Thanks for the clear repro and the suggested fix direction in the issue body — that made the diagnosis fast.