Activity

1. opencode-agent

   assigned

   rekram1-node

   on Jul 15, 2026
2. opencode-agent

   added

   2.0

   on Jul 15, 2026
3. malarahfelipe commented on Aug 27, 2026

   

   malarahfelipe

   on Aug 27, 2026

   Contributor

   More actions

   done a partial MR #44725 for that – can you take a look once you got time @rekram1-node ?
4. EpicEric

   marked v2 regression: OPENCODE_CONFIG environment variable is ignored #48853 as a duplicate of this issue on Sep 13, 2026
5. Xarth-Mai commented on Sep 22, 2026

   

   Xarth-Mai

   on Sep 22, 2026

   More actions

   One more v2 path seems worth including here.

   On v2.0.12, project instruction discovery can be disabled, but a successful read still performs its own nested AGENTS.md discovery:

   • packages/core/src/tool/plugin/read.ts calls fs.up() and sessionInstructions.load() after an internal file read/listing.
   • That path does not check the InstructionDiscovery project setting.
   • packages/core/src/session/instructions.ts then reads those candidates directly and publishes them as durable synthetic instructions.

   So the project-config / project-instruction opt-out currently does not cover read-time nested instruction discovery.

   It would be useful if the same project discovery policy covered this path too, while keeping global AGENTS.md and ordinary file reads available.

   Related context: #13550 discussed an opt-out for built-in dynamic AGENTS.md loading; #36837 covers project config discovery more broadly.
6. fbaltor commented on Sep 28, 2026

   

   fbaltor

   on Sep 28, 2026

   More actions

   Adding one data point on OPENCODE_DISABLE_CLAUDE_CODE_SKILLS, from V2 2.0.18 on Linux:

   • V2 always loads ~/.claude/skills. With the variable set, the claude.ai-synced skills that Claude Code writes under ~/.claude/skills/synced/ still show up in skill.list and in the model's skill catalog.
   • A plugin can't work around this. ctx.skill.transform((editor) => ...) only sees the built-in skills (opencode, report) in editor.list(). Skills from compatibility sources are added outside the transform, so editor.remove(id) can't hide them.

   So for now there's no config key, env var or plugin hook that turns off one compatibility source. A config switch (for example, per-source toggles next to the skills array) would cover it, and so would honoring the V1 variable.

   👍React with 👍1Reacted by Evan Barbour
7. Abdo-Eid commented on Oct 11, 2026

   

   Abdo-Eid

   on Oct 11, 2026

   More actions

   Confirming this on 2.0.26 (Windows 11): OPENCODE_DISABLE_CLAUDE_CODE_SKILLS is still ignored, and the claude.ai skills the Claude desktop app syncs into ~/.claude/skills/synced/<account>/ (23 here) all appear in GET /api/skill and in the model's skill catalog. There is no config key for it either: ~/.claude is always a compatibility root while global config is on (packages/core/src/config/discovery.ts:71-76).

   One correction to the comment above: a plugin can remove them, but only if its transform runs last. Compatibility skills are added through a transform too (packages/core/src/config/plugin/compatibility.ts:72-75), but that plugin registers its transform only after it has scanned the folders, and transforms run in registration order (packages/core/src/state.ts:172-194). A transform registered in setup therefore runs first and only sees opencode and report, which matches what you saw.

   Workaround that works here: when a Claude skill is visible, register the transform again (and dispose the old one), which moves it to the end of the order. Measured in a throwaway opencode serve on 2.0.26: 29 skills, 23 of them from ~/.claude/skills, became 6. On the live service, opencode api get /api/skill then listed 7 skills, none from .claude.

   // ~/.config/opencode/plugin/no-claude-skills.ts
   import { Plugin } from "@opencode/plugin"
   
   const fromClaude = (path: unknown) => String(path ?? "").replace(/\\/g, "/").toLowerCase().includes("/.claude/skills/")
   
   export default Plugin.define({
     id: "local.no-claude-skills",
     async setup(ctx) {
       const drop = (editor: { list(): ReadonlyArray<{ id: string; path: string }>; remove(id: string): void }) => {
         for (const skill of editor.list()) if (fromClaude(skill.path)) editor.remove(skill.id)
       }
       let registration = await ctx.skill.transform(drop)
       let stopped = false
       let busy = false
   
       // Our transform ran before the compatibility one: register it again so it moves to the end.
       const check = async () => {
         if (stopped || busy) return
         busy = true
         try {
           const answer: any = await ctx.skill.list()
           const list: Array<{ path?: string }> = Array.isArray(answer) ? answer : Array.isArray(answer?.data) ? answer.data : []
           if (list.some((skill) => fromClaude(skill.path))) {
             const old = registration
             registration = await ctx.skill.transform(drop)
             await old.dispose()
           }
         } finally {
           busy = false
         }
       }
   
       void (async () => {
         for await (const event of ctx.event.subscribe() as AsyncIterable<{ type?: string }>) {
           if (stopped) break
           if (event?.type === "skill.updated") await check()
         }
       })().catch(() => {})
       setTimeout(() => void check(), 0)
   
       return async () => {
         stopped = true
         await registration.dispose()
       }
     },
   })

   This depends on registration order, so it is a workaround, not a fix. A supported switch would be better: honoring the V1 variable, or a per-source toggle in config as suggested above. A way for a plugin to have its transform run after the built-in ones would also make this kind of filter reliable.

   ❤️React with ❤️1Reacted by AbdulHamed
8. malarahfelipe commented on Oct 15, 2026

   

   malarahfelipe

   on Oct 15, 2026

   Contributor

   More actions

   Status for anyone following: #51888 restores OPENCODE_DISABLE_CLAUDE_CODE (open, mergeable, pending review). Once merged, OPENCODE_DISABLE_CLAUDE_CODE=1 gates the .claude sources in config discovery, so .claude/skills (and their file watches) stop loading while .agents sources stay.

   Scope note: the granular OPENCODE_DISABLE_CLAUDE_CODE_SKILLS / OPENCODE_DISABLE_CLAUDE_CODE_PROMPT variables are not wired by that PR. v2 only consumes .claude for skill discovery (it does not load a CLAUDE.md prompt), so _SKILLS would map to the same gate and _PROMPT would be a no-op today. If maintainers want the granular names restored too, it can be added on top.
9. malarahfelipe commented on Oct 15, 2026

   

   malarahfelipe

   on Oct 15, 2026

   Contributor

   More actions

   For the claude vars, the supported v2 switch is OPENCODE_DISABLE_CLAUDE_CODE=1 (restored by #51888) — it drops .claude/skills discovery, which is the only .claude surface v2 reads. The granular _SKILLS / _PROMPT names remain unsupported in v2: _SKILLS was never declared there, and _PROMPT is a no-op because v2 does not load a CLAUDE.md prompt.
10. malarahfelipe commented on Oct 15, 2026

    

    malarahfelipe

    on Oct 15, 2026

    Contributor

    More actions

    Correction to the note above: #55774 (superseding #51888) does keep OPENCODE_DISABLE_CLAUDE_CODE_SKILLS working — it maps both the umbrella and _SKILLS to the same claude gate at the CLI boundary, since v2 only reads .claude for skills. _PROMPT stays a no-op because v2 doesn't load a CLAUDE.md prompt.
11. rekram1-node commented on Oct 16, 2026

    

    rekram1-node

    on Oct 16, 2026

    Last edited by rekram1-node

    Collaborator

    More actions

    @malarahfelipe plz stop spamming our issues

    👍React with 👍1Reacted by Felipe Mateus Malara
12. rios0rios0

    added a commit that references this issue on Oct 17, 2026

    feat(core): restore OPENCODE_DISABLE_CLAUDE_CODE for compatibility roots

    ...

    cb2b583