Skip to content

[QUESTION] Should .opencode/opencode.jsonc should be removed and gitignored? #4565

Closed

Description

@ben-vargas

Question

When the community clones and reviews/works on opencode, the .opencode/opencode.jsonc overrides the plugins instantiated in ~/.config/opencode/opencode.json or jsonc file - I think this should be in .gitignore?

I'm not sure it is a great practice as it's a 3rd party npm package and runs non-SST code and not declared as a dependency (i.e. hard to know it ran and why).

I've contributed to and helped create that plugin, so I do support it... but question it loading by default and surprising devs running opencode from the cloned source dir.

It just caused a headache overriding my own defined plugins until I dug in to figure out why my defined plugins weren't loading... thought I'd raise this as a question/consideration.

Activity

  1. changed the title [-]Should .opencode/opencode.jsonc should be removed and gitignored?[/-] [+][QUESTION] Should .opencode/opencode.jsonc should be removed and gitignored?[/+] on Nov 21, 2025
  2. rekram1-node commented on Nov 21, 2025

    @rekram1-node
    Collaborator

    @ben-vargas I think the main thing is that plugins should merge together rather than override I think that's the best fix.

    I think Dax has it listed as a dep because it is a well implemented plugin and I think he uses it himself sometimes to test things

  3. ben-vargas commented on Nov 21, 2025

    @ben-vargas
    ContributorAuthor

    @rekram1-node - Yeah, I agree it's a well implemented plugin. A merge of plugin array would probably be ideal rather than override, I just couldn't figure out why a plugin I use enabling Google/Gemini OAuth suddenly stopped working until I did some digging.

    I personally git clone the plugins and run them locally so I can control updates and don't open up exposure to npm hijacking (better control over code executing on my system). I use a fork of the codex oauth plugin in question and modified fork of the google/gemini oauth (improved 429 retry handling).

    Probably at minimum de-duplication would need to occur between the the project level and user level config files, but I'd still probably end up with duplicate/problematic plugin loads because of my local clones vs npm load.

    I won't pretend to know the right answer here, or even that you guys should do anything on this - I just stumbled on it and thought I'd raise if for discussion.

    Thanks for responding!

  4. rekram1-node commented on Nov 21, 2025

    @rekram1-node
    Collaborator

    no problem

  5. added a commit that references this issue on Nov 25, 2025
    4273fa9
  6. added a commit that references this issue on May 5, 2026
    d42b1ba
  7. added a commit that references this issue on Jun 14, 2026
    53f47d2
  8. added a commit that references this issue on Jul 31, 2026
    74830e4
  9. added a commit that references this issue on Sep 6, 2026
    551dcd1
Sign up for free to join this conversation on GitHub. Already have an account? Sign in to comment

Metadata

Metadata

Assignees

No one assigned

    Labels

    No labels
    No labels

    Type

    No type

    Projects

    No projects

      Milestone

      No milestone

      Relationships

      None yet

      Development

      No branches or pull requests

      Issue actions