[FEATURE]: support config.d/ directory for modular configuration #9062

Activity

1. ferdinandyb

   added

   discussionUsed for feature requests, proposals, ideas, etc. Open discussionUsed for feature requests, proposals, ideas, etc. Open discussion

   on Jan 17, 2026
2. github-actions

   assigned

   thdxr

   on Jan 17, 2026
3. github-actions commented on Jan 17, 2026

   

   github-actionsBot

   on Jan 17, 2026 – with GitHub Actions

   Contributor

   More actions

   This issue might be a duplicate of existing issues. Please check:

   • [FEATURE]: Composable configs #8241: [FEATURE]: Composable configs - Proposes extending config from other sources (local paths, git repos)
   • [FEATURE]: Plugin Hook for Registering Additional Config Directories #6347: [FEATURE]: Plugin Hook for Registering Additional Config Directories - Requests ability for plugins to register additional config directories for skills, agents, commands, and tools
   • [FEATURE]: Allow custom skills directories #8533: [FEATURE]: Allow custom skills directories - Requests custom skills directories via config
   • Reorganize and document dirs for config, agents, auth credentials, sessions #4170: Reorganize and document dirs for config, agents, auth credentials, sessions - Discusses config directory organization and structure

   Feel free to ignore if #9062 addresses your specific needs differently (such as the config.d/ pattern specifically).
4. ferdinandyb commented on Jan 30, 2026

   

   ferdinandyb

   on Jan 30, 2026

   ContributorAuthor

   More actions

   I think my PR for this problem has broken due to updates. But I've been thinking, that the config.d solution is great for breaking up opencode.json, which is already great. But it does not allow sharing configuration options between agents.

   Case in point this is one of my agents and this is my opencode.jsonc. My config philosophy is that opencode should be allowed to do anything that is more-or-less read only and asks for anything else. Obviously, I have a growing list of standard unix tools in the allow list, that I would like to share with almost all of my agents, since in general there is no problems with them reading stuff.

   The biggest problem here is that this actually requires that agents also merge some other files. So I could imagine that we go forward with config.d which is loaded completely by the main agent, but that sub-agents reference them.

   Hmm, in that case it would probably be better if the configuration in general got an extra option, which is a list, where you can list other jsonc files that are merged with the current config (probably supporting glob would be great). So your main config could say something like

   {
   mergeconfigs = ["config.d/*"]
   }
   

   while a subagent could go

   {
   mergeconfigs = ["config.d/unixtools.jsonc", "config.d/foo.jsonc"]
   }
   
5. 3x3cut0r commented on Feb 25, 2026

   

   3x3cut0r

   on Feb 25, 2026

   More actions

   I am also in favor of conf.d logic. Why?
   For security reasons alone.
   Although I generally believe that agents should be allowed to read everything, there are exceptions. For example, *.env, *credential, or even tool calls such as "docker inspect *". And these can also be folder/project specific. Security confs could be shared separately. This is not currwntly feasible.
6. aspiers commented on Mar 4, 2026

   

   aspiers

   on Mar 4, 2026

   Contributor

   More actions

   Yes please, this is a much-needed feature!

   For all the same reasons it's such a popular pattern elsewhere, this would be very helpful in OpenCode too. There are multiple use cases both for global and per-project config, e.g.

   • Have one main config file tracked in git, then allow local per-machine overrides which can be git-ignored:
     • Keep MCP API tokens out of git
     • Override default bash permission of ask with allow on a sandbox machine
     • Install an extra plugin only on one machine
   • Allow global config to be constructed from multiple git repos via GNU Stow
   • Avoid massive config files
7. 3x3cut0r commented on Mar 7, 2026

   

   3x3cut0r

   on Mar 7, 2026

   More actions

   I have created a pull request to solve this issue:
   #16525
8. 3x3cut0r commented on Mar 16, 2026

   

   3x3cut0r

   on Mar 16, 2026

   More actions

   How long does it usually take for PRs to be at least reviewed? Or how can I see if this is on scope or being discussed?
9. rcdailey commented on Mar 27, 2026

   

   rcdailey

   on Mar 27, 2026

   More actions

   I have a slightly different angle on this. I'm managing my OpenCode config through chezmoi, and my global config (~/.config/opencode/) is heavily tailored to software development: coding-specific agents, skills, commands, and AGENTS.md directives. But I also want to use OpenCode for completely unrelated tasks (legal research, writing, etc.) where none of that coding context applies.

   OPENCODE_CONFIG_DIR supplements the global config dir but doesn't replace it, so there's no clean way to swap contexts today. The config.d/ proposal could solve this if modules are structured as self-contained directories rather than just jsonc fragments:

   ~/.config/opencode/
     opencode.jsonc              # core: providers, model, permissions, theme
     AGENTS.md                   # universal principles (voice, style)
     config.d/
       coding/                   # activate for dev work
         opencode.jsonc
         AGENTS.md
         agents/
         skills/
         commands/
       legal/                    # activate for legal work
         opencode.jsonc
         AGENTS.md
         agents/
         skills/
         commands/
   

   The core config stays universal. Each config.d/ subdirectory is a complete module with its own agents, skills, commands, and config overrides. You activate whichever module fits the task.

   This needs some form of selective activation (only load specific config.d/ entries, not all of them). But it fits naturally with the composability model this issue is proposing, and it solves a real problem that OPENCODE_CONFIG_DIR can't handle today.
10. ferdinandyb commented on Mar 27, 2026

    

    ferdinandyb

    on Mar 27, 2026

    ContributorAuthor

    More actions

    Hey @thdxr I assume you guys are mighty busy, but this seems to be the type of issue where input from the maintainers' side would be appreciates on where you would like to go with this. I sort of assume most people with meticulous dotfiles will be gravitating towards opencode so probably worth doing something well aligned with your plans.

    That being said, there were two PR-s already trying to address this, and if I remember correctly @ariane-emory also had a branch somewhere with a different take on this. Have you put any thought into this or is this not the right time to be talking about a more controllable configuration system?
11. thdxr

    removed

    discussionUsed for feature requests, proposals, ideas, etc. Open discussionUsed for feature requests, proposals, ideas, etc. Open discussion

    on May 3, 2026
12. github-actions commented on Jul 6, 2026

    

    github-actionsBot

    on Jul 6, 2026 – with GitHub Actions

    Contributor

    More actions

    To stay organized issues are automatically closed after 60 days of no activity. If the issue is still relevant please open a new one.
13. github-actions

    closed this as not plannedon Jul 6, 2026