Feature: add a toggle to disable reusing Claude config/plugins/MCPs

[Strelitzia-reginae]

Summary

OpenCode/OMO currently appears to reuse parts of the Claude Code user environment from ~/.claude, including settings, plugins, MCP servers, skills, and CLAUDE.md context. This is convenient for some users, but for others it creates hidden coupling and makes runtime behavior harder to reason about.

Problem

Right now, it is difficult to tell which capabilities come from OpenCode/OMO itself and which are being inherited from the Claude environment.

This can cause problems such as:

• unexpected MCP servers or tools appearing
• plugins being loaded implicitly from Claude's plugin ecosystem
• CLAUDE.md instructions affecting behavior without an obvious OpenCode-side setting
• harder debugging, because behavior depends on another tool's user directory
• weaker isolation and less predictable trust boundaries

Requested feature

Please add a user-facing toggle or startup flag to control whether OpenCode/OMO reuses Claude Code user state.

Suggested modes:

1. Reuse Claude environment (current behavior)
2. Isolated mode (do not load from ~/.claude)
3. Optional granular controls for:
   • Claude settings
   • Claude plugins
   • Claude MCP servers
   • Claude skills
   • CLAUDE.md instructions/context

Why this would help

• clearer separation between OpenCode and Claude ecosystems
• easier debugging and reproducibility
• more predictable tool/MCP surface
• better security and trust clarity
• easier onboarding for users who want a clean OpenCode-only setup

Possible UX ideas

• ask on first startup whether Claude compatibility should be enabled
• expose a config option in settings
• add a CLI flag for strict isolation
• show the source of loaded capabilities (OpenCode vs Claude vs plugin)

Notes

I am not suggesting removing Claude compatibility. The issue is that reuse currently feels implicit. An explicit switch would preserve compatibility while giving users control over isolation and predictability.

[DianP]

This issue should probably be reported to the OpenCode repo, since this behavior appears to come from OpenCode itself.

Related issue: anomalyco/opencode#12604

Also, according to the OpenCode docs, you can set an environment variable to disable Claude compatibility: https://opencode.ai/docs/rules/#claude-code-compatibility

[Strelitzia-reginae]

Following up after doing a fairly deep trace on a real Windows machine with OMO enabled, I think the behavior is broader than "this is only an OpenCode issue". It looks more accurate to say that OpenCode core and OMO both participate in the final outcome.

What I verified:

1. On the local machine, C:\Users\aau\.claude.json currently contains:

   • mcpServers.memory -> cmd /c npx -y @modelcontextprotocol/server-memory
   • mcpServers.sequential-thinking -> cmd /c npx -y @modelcontextprotocol/server-sequential-thinking

2. In OpenCode runtime artifacts, those same MCPs later appear as connected/loaded local MCPs.

3. In OMO source, the runtime MCP merge path is explicit:

   • src/plugin-handlers/mcp-config-handler.ts -> applyMcpConfig()
   • merge order is:
     1. createBuiltinMcps(...)
     2. config.mcp
     3. loadMcpConfigs(...) (Claude-compatible MCP loader)
     4. pluginComponents.mcpServers

4. In OMO source, the Claude-compatible MCP loader explicitly reads ~/.claude.json:

   • src/features/claude-code-mcp-loader/loader.ts
   • getMcpConfigPaths() includes join(homedir(), ".claude.json") as the first user-level MCP config path

5. OMO tests also explicitly lock this behavior in:

   • loader.test.ts: reads user-level MCP config from ~/.claude.json
   • loader.test.ts: reads both ~/.claude.json and ~/.claude/.mcp.json for user scope

So from the evidence, the current behavior is not just "OpenCode core accidentally did something" while OMO is uninvolved. In a real OMO setup, OMO is actively part of the host-side merge path that imports Claude-compatible MCP config and materializes it into the effective runtime MCP set.

I agree there may also be OpenCode-side inheritance / compatibility behavior underneath, but for users running OMO, this still feels like an OMO concern because OMO is the layer assembling the final effective MCP configuration.

A more accurate framing might be:

• OpenCode core has Claude-compat / inheritance behavior
• OMO currently builds on top of that and also explicitly loads + merges Claude-compatible MCP config
• therefore users need an OMO-side isolation control too, not just an OpenCode-side fix

From the current source, the most obvious OMO-side control surface seems to be around:

• pluginConfig.claude_code?.mcp
• disabled_mcps
• and/or a higher-level "isolated mode" that disables reuse of Claude config/plugins/MCPs by policy

So I still think this issue belongs here as a valid product/runtime concern for OMO users, even if a related part also belongs upstream in OpenCode.

[Strelitzia-reginae]

Small but important runtime follow-up after more testing.

I was able to get a stable interactive OpenCode session running under Windows by installing tmux-windows and launching OpenCode through a persistent tmux session instead of relying on short-lived subprocesses.

Test setup:

• OpenCode launched via a wrapper script that sets OPENCODE_DISABLE_CLAUDE_CODE=1
• OMO user config updated to disable all Claude-compatible feature imports:

  {
    "claude_code": {
      "mcp": false,
      "commands": false,
      "skills": false,
      "agents": false,
      "hooks": false,
      "plugins": false
    }
  }

• Effective OMO config file on this machine was the legacy-but-still-supported:
  C:\Users\aau\.config\opencode\oh-my-opencode.json

Actual runtime result from the stable session:

• OpenCode UI came up successfully
• Bottom status bar showed 3 MCP
• Fresh runtime log (2026-03-31T012106.log) showed those 3 MCPs were exactly:
  • websearch
  • context7
  • grep_app
• They were all connected as remote MCPs

Crucially, after this configuration:

• memory did not appear
• sequential-thinking did not appear
• claude-mem:mcp-search did not appear

So this seems to confirm the practical split very clearly:

1. The Claude-compatible/Claude-derived layer can in fact be suppressed in OMO at runtime by disabling the claude_code.* imports (especially claude_code.mcp) together with OPENCODE_DISABLE_CLAUDE_CODE=1.
2. The remaining MCPs in a stable session are the OMO built-in remote MCP set (websearch, context7, grep_app), not the previous Claude-origin entries like memory, sequential-thinking, or claude-mem:*.

So the issue is not that OMO cannot be controlled at all — it can — but that this behavior and the control boundary are not obvious to users. The practical confusion is:

• Claude-derived things can show up unless both layers are understood/configured correctly
• after that, users may still see OMO built-in MCPs and assume Claude leakage is still happening

That suggests the product/documentation gap may be:

• clarify the difference between Claude-compatible imports vs OMO built-in MCPs
• document claude_code.* as the real host-side control plane more prominently
• ideally expose an even clearer "fully isolate from Claude ecosystem" mode in UX/docs

[Strelitzia-reginae]

Adding a more complete write-up from a full end-to-end investigation, because I think the most useful part for future users is not just the final answer, but the mental model for how to debug this class of problem.

Executive summary

After tracing this on a real Windows machine, I think the practical behavior is best understood as a layered startup stack rather than a single "Claude compatibility" switch.

There are at least 4 distinct layers that matter:

1. Launcher / process environment

   • HOME
   • USERPROFILE
   • OPENCODE_CONFIG_DIR
   • CLAUDE_CONFIG_DIR
   • CLAUDE_PLUGINS_HOME
   • CLAUDE_SETTINGS_PATH
   • OPENCODE_DISABLE_CLAUDE_CODE

2. OpenCode core

   • reads OpenCode config roots
   • applies official Claude Code compatibility behavior
   • loads plugins

3. OMO plugin layer

   • reads oh-my-opencode.json[c] / oh-my-openagent.json[c]
   • merges built-in MCPs
   • optionally imports Claude-compatible MCP/commands/skills/agents/hooks/plugins

4. Runtime result

   • which MCPs actually appear in the UI
   • which MCPs actually connect
   • which tools/commands/skills really survive into a running session

A lot of confusion comes from mixing these layers together.

---

The most important distinction I found

There are two very different ways to "stop Claude things from appearing":

1. Disable Claude compatibility by policy

Example:

• OPENCODE_DISABLE_CLAUDE_CODE=1
• OMO claude_code.* = false

This says:

"You may still run in the same environment, but do not import Claude-compatible content."

2. Isolate Claude-compatible inputs at the filesystem/environment level

Example:

• change HOME / USERPROFILE
• point CLAUDE_* vars to an empty isolated directory
• but keep OPENCODE_CONFIG_DIR pinned to the real OpenCode config dir

This says:

"Even if something still tries to look for Claude-origin content, it will only see an empty fake Claude home."

These are not equivalent controls. One is a policy gate. The other is an input isolation boundary.

---

The two launcher scripts are NOT equivalent launchers

I compared two launchers:

opencode-no-claude-official.ps1

This only sets:

• OPENCODE_DISABLE_CLAUDE_CODE=1

It does not change:

• HOME
• USERPROFILE
• OpenCode config root

So this launcher tests:

whether OpenCode core's official Claude compatibility disable flag is sufficient by itself.

opencode-no-claude.ps1

This one is much more aggressive.
It changes:

• HOME
• USERPROFILE
• CLAUDE_CONFIG_DIR
• CLAUDE_PLUGINS_HOME
• CLAUDE_SETTINGS_PATH

It also creates empty stub files like:

• isolated ~/.claude.json
• isolated ~/.claude/.mcp.json
• isolated ~/.claude/settings.json

But crucially, it restores:

• OPENCODE_CONFIG_DIR = C:\Users\aau\.config\opencode

That restoration matters a lot.

Without it, changing HOME would not only isolate Claude-origin inputs — it would also move OpenCode/OMO itself into a different config/data universe.

So that custom launcher is not merely "another way to disable Claude".
It is actually:

"isolate Claude-origin inputs while preserving the real OpenCode/OMO config root."

That is a much more sophisticated and robust design than it may look at first glance.

---

Why this matters in practice

If you only change HOME / USERPROFILE, then OpenCode itself can start loading from a different root, such as an isolated home:

• different .config/opencode
• different .local/share/opencode
• different DB / state / plugin-install cwd

That means you are no longer just testing "Claude isolation".
You are also changing:

• where OpenCode reads config
• where OMO reads plugin config
• where runtime state is written

That makes debugging harder, because now multiple variables changed at once.

The custom script avoided that by explicitly pinning:

• OPENCODE_CONFIG_DIR back to the real OpenCode config directory

That pattern is worth documenting as a general technique.

---

The OMO layer is a separate control plane from OpenCode core

This was one of the most important findings.

Even if OpenCode core disables official Claude Code compatibility behavior, OMO still has its own Claude-compatible import layer.

In OMO source/runtime, the relevant control surface is:

{
  "claude_code": {
    "mcp": false,
    "commands": false,
    "skills": false,
    "agents": false,
    "hooks": false,
    "plugins": false
  }
}

That means there are two different control planes:

OpenCode core control plane

• env vars like OPENCODE_DISABLE_CLAUDE_CODE

OMO control plane

• plugin config like claude_code.*

This is the practical reason users can be confused.
A user can think:

"I disabled Claude compatibility already. Why do Claude-like things still appear?"

And the answer can be:

because OpenCode core was disabled, but OMO was still importing Claude-compatible content on top.

That is the kind of distinction many users will not infer from the current UX.

---

What finally gave the decisive answer: runtime logs, not docs or schemas

There is another important lesson here.

A lot of things that look like Claude leakage are actually not runtime leakage at all. They can just be:

• schema definitions
• feature reference text
• built-in docs mentioning .claude compatibility
• fallback model descriptions mentioning Claude models

Those are not the same as runtime imports.

The only really decisive evidence was runtime evidence such as:

• service=mcp key=... found
• connected
• create() successfully created client

That is what finally separated:

• real runtime MCPs
  from
• documentation or packaged feature text

So the general debugging rule is:

When trying to determine whether Claude-origin things are actually loaded, trust runtime logs over feature reference text.

---

Stable interactive session was necessary

Short-lived subprocess launches were not enough to reach a trustworthy answer.

We had to:

1. install tmux-windows
2. launch OpenCode in a persistent tmux session
3. keep the TUI alive long enough to observe a stable state
4. then correlate that stable state with a fresh runtime log

This ended up being the breakthrough.

Because before that, it was too easy to confuse:

• old logs
• old tool-output artifacts
• startup text
• partial initialization
• real steady-state runtime behavior

This is worth explicitly noting for anyone debugging TUI/plugin/runtime issues on Windows:

A stable session is much more valuable than repeated short launches.

---

Final runtime result after applying both control layers

Test conditions:

• OpenCode launched with OPENCODE_DISABLE_CLAUDE_CODE=1
• OMO config set to disable all claude_code.* imports
• stable interactive session created via tmux

Result:

• OpenCode UI came up successfully
• bottom bar showed 3 MCP
• fresh runtime log showed those 3 were exactly:
  • websearch
  • context7
  • grep_app
• all three were remote MCPs

Critically, the following did not reappear in the stable session runtime evidence:

• memory
• sequential-thinking
• claude-mem:mcp-search

That gives a very practical final split:

Claude-derived / Claude-compatible things that disappeared after proper disabling

• memory
• sequential-thinking
• claude-mem:*

Remaining MCPs after disabling Claude-origin layers

• websearch
• context7
• grep_app

Those appear to be OMO built-in remote MCPs, not remaining Claude leakage.

This is a very important distinction for user understanding.

---

The legacy config filename/path issue is also worth documenting

Another source of confusion was the rename/migration state around:

• oh-my-opencode.json[c]
• oh-my-openagent.json[c]

What the investigation showed is:

• old names are still intentionally supported
• in some detection paths, legacy names still effectively win
• users should not assume that seeing oh-my-opencode.json on disk means something is broken or stale in a suspicious way
• compatibility seems to be intentionally preserved during migration

So the presence of a legacy config filename is not, by itself, a red flag.

---

The reusable troubleshooting heuristics I took away from this

For future OpenCode/OMO/Claude-compat debugging, this order seems much more effective than ad-hoc guessing:

1. Identify the layer first

Ask:

• Is this OpenCode core?
• Is this OMO built-in?
• Is this OMO Claude-compatible import?
• Is this actual Claude plugin / .claude content?
• Or is it only docs/schema text?

2. Verify the real config root in runtime

Especially on Windows, do not assume docs paths match actual runtime behavior.
Check what config root actually loaded.

3. Separate "policy disable" from "input isolation"

These are different tools:

• env flags disable behavior
• isolated home/config tricks remove inputs entirely

4. Prefer source-category controls over item-by-item blacklists

If the real issue is "Claude-origin imports", disabling that whole source category is cleaner than disabling individual MCP names.

5. Use runtime logs to confirm, not just UI or docs text

UI can mislead. Docs text can mislead. Runtime logs are the most trustworthy source for what actually loaded.

6. Use a stable session for TUI systems

Without a stable session, it is too easy to misread partial startup behavior.

---

Suggested product/docs takeaway

The product/docs gap may not be that OMO cannot be controlled. It can.

The real gap is that users are likely to miss the distinction between:

• OpenCode Claude compatibility
• OMO Claude-compatible imports
• OMO built-in MCPs

That leads to understandable confusion such as:

• "I disabled Claude, why do MCPs still appear?"
• "Are these remaining MCPs still Claude leakage?"
• "Why did changing HOME also seem to change OpenCode behavior?"

If the docs/UX made the layer model more explicit, this would likely become much easier to reason about.

In particular, it may help to document more clearly:

• OpenCode env-side compatibility knobs vs OMO plugin-side import knobs
• the difference between disabling Claude-compatible imports and isolating Claude-origin inputs
• how to verify runtime reality from logs
• that built-in MCPs can remain after Claude-origin imports are disabled

I hope this helps future users avoid a lot of trial-and-error.

[abhinavm24]

+1, same issue with omo. None of the claude plugins or mcp show up in vanilla opencode