anomalyco/opencode
1
0
Fork 0
mirror of https://github.com/anomalyco/opencode.git synced 2026-07-22 02:05:26 -04:00
Code Issues 5.9k Packages Projects Releases 19 Wiki Activity

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

New Issue
Open
opened 2026-02-16 18:04:40 -05:00 by yindo · 2 comments
yindo commented 2026-02-16 18:04:40 -05:00
Owner
Copy Link
Copy Source

Originally created by @ferdinandyb on GitHub (Jan 17, 2026).

Originally assigned to: @thdxr on GitHub.

Feature hasn't been suggested before.

  • I have verified this feature I'm about to request hasn't been suggested before.

Describe the enhancement you want to request

Problem

Currently, all OpenCode configuration must be in a single opencode.json file. This becomes unwieldy when managing complex setups with many providers, MCP servers, permissions, and custom settings. Users cannot easily:

  • Share partial configurations across machines (e.g., just permissions or just theme)
  • Keep sensitive configuration separate from version-controlled settings
  • Organize configuration logically by concern (providers, permissions, plugins, etc.)
  • Manage large sections of granular permissions across multiple files (e.g., 10-permissions-git.json, 11-permissions-test-tools.json, 12-permissions-deploy.json)

Proposed Solution

Add support for a config.d/ directory that allows splitting configuration into multiple files:

  • ~/.config/opencode/config.d/ for global configuration fragments
  • .opencode/config.d/ for project-specific fragments

Files would be loaded alphabetically and merged after the main config file, following the common Unix pattern (similar to /etc/sudoers.d/, /etc/apt/sources.list.d/, etc.).

Use Cases

  • Granular permissions: Split permissions by tool category (10-permissions-git.json, 11-permissions-test-tools.json, 12-permissions-deploy.json)
  • Plugin organization: Maintain 50-plugins.json for all plugin definitions
  • Sensitive data: Store API keys in a non-versioned fragment file
  • Shared configs: Symlink common fragments across projects
Originally created by @ferdinandyb on GitHub (Jan 17, 2026). Originally assigned to: @thdxr on GitHub. ### Feature hasn't been suggested before. - [x] I have verified this feature I'm about to request hasn't been suggested before. ### Describe the enhancement you want to request ### Problem Currently, all OpenCode configuration must be in a single `opencode.json` file. This becomes unwieldy when managing complex setups with many providers, MCP servers, permissions, and custom settings. Users cannot easily: - Share partial configurations across machines (e.g., just permissions or just theme) - Keep sensitive configuration separate from version-controlled settings - Organize configuration logically by concern (providers, permissions, plugins, etc.) - Manage large sections of granular permissions across multiple files (e.g., `10-permissions-git.json`, `11-permissions-test-tools.json`, `12-permissions-deploy.json`) ### Proposed Solution Add support for a `config.d/` directory that allows splitting configuration into multiple files: - `~/.config/opencode/config.d/` for global configuration fragments - `.opencode/config.d/` for project-specific fragments Files would be loaded alphabetically and merged after the main config file, following the common Unix pattern (similar to `/etc/sudoers.d/`, `/etc/apt/sources.list.d/`, etc.). ### Use Cases - **Granular permissions**: Split permissions by tool category (`10-permissions-git.json`, `11-permissions-test-tools.json`, `12-permissions-deploy.json`) - **Plugin organization**: Maintain `50-plugins.json` for all plugin definitions - **Sensitive data**: Store API keys in a non-versioned fragment file - **Shared configs**: Symlink common fragments across projects
yindo added the discussion label 2026-02-16 18:04:40 -05:00
yindo commented 2026-02-16 18:04:40 -05:00
Author
Owner
Copy Link
Copy Source

@github-actions[bot] commented on GitHub (Jan 17, 2026):

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

  • #8241: [FEATURE]: Composable configs - Proposes extending config from other sources (local paths, git repos)
  • #6347: [FEATURE]: Plugin Hook for Registering Additional Config Directories - Requests ability for plugins to register additional config directories for skills, agents, commands, and tools
  • #8533: [FEATURE]: Allow custom skills directories - Requests custom skills directories via config
  • #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).

@github-actions[bot] commented on GitHub (Jan 17, 2026): This issue might be a duplicate of existing issues. Please check: - #8241: [FEATURE]: Composable configs - Proposes extending config from other sources (local paths, git repos) - #6347: [FEATURE]: Plugin Hook for Registering Additional Config Directories - Requests ability for plugins to register additional config directories for skills, agents, commands, and tools - #8533: [FEATURE]: Allow custom skills directories - Requests custom skills directories via config - #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).
yindo commented 2026-02-16 18:04:40 -05:00
Author
Owner
Copy Link
Copy Source

@ferdinandyb commented on GitHub (Jan 30, 2026):

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"]
}
@ferdinandyb commented on GitHub (Jan 30, 2026): 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](https://raw.githubusercontent.com/ferdinandyb/dotfiles/refs/heads/master/.config/opencode/agent/code-reviewer.md) and this is my [opencode.jsonc](https://github.com/ferdinandyb/dotfiles/blob/master/.config/opencode/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"] } ```
Sign in to join this conversation.
No Branch/Tag Specified
Branches Tags
Labels
Clear labels
acp
bad
bug
discussion
docs
documentation
enhancement
extension
good first issue
growth
help-wanted
mcp
model-problem
needs:compliance
nix
opentui
perf
pull-request
Mirrored from GitHub Pull Request
 tui
web
windows
zen
No Label discussion
Milestone
No items
No Milestone
Projects
Clear projects
No project
Assignees
Clear assignees
yindo
No Assignees
1 Participants
Notifications
Due Date
No due date set.
Dependencies

No dependencies set.

Reference: anomalyco/opencode#6584
Delete Branch "%!s()"

Deleting a branch is permanent. Although the deleted branch may continue to exist for a short time before it actually gets removed, it CANNOT be undone in most cases. Continue?