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

parent folder config scope #7649

New Issue
Open
opened 2026-02-16 18:07:49 -05:00 by yindo · 3 comments
yindo commented 2026-02-16 18:07:49 -05:00
Owner
Copy Link
Copy Source

Originally created by @rafaeldev on GitHub (Jan 26, 2026).

Originally assigned to: @thdxr on GitHub.

Question

Is it possible use a upper config folder with project config together?

My company have:

all_project
├── project_1
│   └── opencode.json
├── project_2
│   └── opencode.json 
└── opencode.json

The project 1 and project 2 have their opencode.json config file and inherit from all_project parent folder

I have some mcp configs about in company context, like trello and don't want repeat same config to each project and don't make sense add it to global

Originally created by @rafaeldev on GitHub (Jan 26, 2026). Originally assigned to: @thdxr on GitHub. ### Question Is it possible use a upper config folder with project config together? My company have: ``` all_project ├── project_1 │ └── opencode.json ├── project_2 │ └── opencode.json └── opencode.json ``` The project 1 and project 2 have their `opencode.json` config file and inherit from `all_project` parent folder I have some mcp configs about in company context, like trello and don't want repeat same config to each project and don't make sense add it to global
yindo commented 2026-02-16 18:07:49 -05:00
Author
Owner
Copy Link
Copy Source

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

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

  • #10025: [FEATURE]: add OPENCODE_NO_PARENT_CONFIG to disable parent directory config inheritance (directly related to parent config behavior)
  • #6479: opencode reads agents.md from parent directories (shows OpenCode already supports searching parent directories)
  • #4054: MCP Servers are not available if config is per project (shows issues with project-level configs)
  • #10544: opencode github run does not respect the root level config (shows config scope issues)
  • #6984: Config autoupdate only respected at global path (shows some options only work at global level)
  • #10133: [FEATURE]:Unified configuration structure (related request for better config management)

Feel free to ignore if none of these address your specific case.

@github-actions[bot] commented on GitHub (Jan 26, 2026): This issue might be a duplicate of existing issues. Please check: - #10025: [FEATURE]: add `OPENCODE_NO_PARENT_CONFIG` to disable parent directory config inheritance (directly related to parent config behavior) - #6479: opencode reads agents.md from parent directories (shows OpenCode already supports searching parent directories) - #4054: MCP Servers are not available if config is per project (shows issues with project-level configs) - #10544: opencode github run does not respect the root level config (shows config scope issues) - #6984: Config autoupdate only respected at global path (shows some options only work at global level) - #10133: [FEATURE]:Unified configuration structure (related request for better config management) Feel free to ignore if none of these address your specific case.
yindo commented 2026-02-16 18:07:49 -05:00
Author
Owner
Copy Link
Copy Source

@cravenceiling commented on GitHub (Jan 26, 2026):

I think you could do something like:

OPENCODE_CONFIG=../opencode.json opencode

inside of project_1 or project_2 of course.

You can check the final config using:

OPENCODE_CONFIG=../opencode.json opencode debug config
@cravenceiling commented on GitHub (Jan 26, 2026): I think you could do something like: ```bash OPENCODE_CONFIG=../opencode.json opencode ``` inside of `project_1` or `project_2` of course. You can check the final config using: ```bash OPENCODE_CONFIG=../opencode.json opencode debug config ```
yindo commented 2026-02-16 18:07:49 -05:00
Author
Owner
Copy Link
Copy Source

@Flare576 commented on GitHub (Feb 9, 2026):

Use Case: Multi-Client Consultant Structure

I have the exact same need. My directory structure:

~/.config/opencode/
├── opencode.jsonc        # Global: core providers, personal Slack MCP
└── AGENTS.md             # Global: base working preferences

~/Projects/
├── ClientA/
│   ├── opencode.jsonc    # ClientA: Slack MCP, Atlassian MCP, model overrides
│   ├── AGENTS.md         # "Flare's Role at ClientA"
│   ├── project-one/      # ← git repo
│   │   └── opencode.jsonc
│   └── project-two/      # ← git repo
│       └── opencode.jsonc
├── ClientB/
│   ├── opencode.jsonc    # ClientB: different Slack workspace, different Atlassian
│   ├── AGENTS.md         # "Flare's Role at ClientB"
│   └── some-project/     # ← git repo
└── Personal/
    ├── opencode.jsonc    # Personal: no client MCPs, different model mix
    └── ei/               # ← git repo

Current behavior: When I run opencode in ~/Projects/ClientA/project-one/, it only loads:

  1. ~/.config/opencode/opencode.jsonc (global)
  2. ~/Projects/ClientA/project-one/opencode.jsonc (git root)

It skips ~/Projects/ClientA/opencode.jsonc entirely because findUp stops at the git boundary.

What I need: The ability to define client-level MCPs and context once, inherited by all projects under that client, without duplicating config into every git repo.

The workaround of OPENCODE_CONFIG=../opencode.jsonc doesn't help because:

  1. It overrides rather than merges
  2. It requires manual invocation every time
  3. It doesn't support multiple levels of hierarchy

Secondary Concern: Instruction Files

Related to config hierarchy, I'd want instruction files (AGENTS.md) to follow the same pattern. Currently I can work around this with the instructions config field:

// In ~/Projects/ClientA/opencode.jsonc
{
  "instructions": ["~/Projects/ClientA/AGENTS.md"],
  "mcp": { /* client-specific MCPs */ }
}

If config hierarchy worked, this would "just work" - each level's config would add its own AGENTS.md via the instructions array, and since instructions arrays concatenate (per mergeConfigConcatArrays), all levels would be included.

One implementation note: If this feature lands, relative paths in instructions (like "./AGENTS.md") would need to be resolved relative to the config file's location before merging, not relative to CWD. Otherwise users would need to use absolute paths at each level.

Summary

Would love to see findUp optionally continue beyond git boundaries, walking up the filesystem until it hits $HOME or a configurable stop point. This would enable:

  • Client/org-level MCP configurations
  • Tiered instruction contexts
  • Reduced duplication across related projects
@Flare576 commented on GitHub (Feb 9, 2026): ### Use Case: Multi-Client Consultant Structure I have the exact same need. My directory structure: ``` ~/.config/opencode/ ├── opencode.jsonc # Global: core providers, personal Slack MCP └── AGENTS.md # Global: base working preferences ~/Projects/ ├── ClientA/ │ ├── opencode.jsonc # ClientA: Slack MCP, Atlassian MCP, model overrides │ ├── AGENTS.md # "Flare's Role at ClientA" │ ├── project-one/ # ← git repo │ │ └── opencode.jsonc │ └── project-two/ # ← git repo │ └── opencode.jsonc ├── ClientB/ │ ├── opencode.jsonc # ClientB: different Slack workspace, different Atlassian │ ├── AGENTS.md # "Flare's Role at ClientB" │ └── some-project/ # ← git repo └── Personal/ ├── opencode.jsonc # Personal: no client MCPs, different model mix └── ei/ # ← git repo ``` **Current behavior**: When I run `opencode` in `~/Projects/ClientA/project-one/`, it only loads: 1. `~/.config/opencode/opencode.jsonc` (global) 2. `~/Projects/ClientA/project-one/opencode.jsonc` (git root) It skips `~/Projects/ClientA/opencode.jsonc` entirely because `findUp` stops at the git boundary. **What I need**: The ability to define client-level MCPs and context once, inherited by all projects under that client, without duplicating config into every git repo. The workaround of `OPENCODE_CONFIG=../opencode.jsonc` doesn't help because: 1. It overrides rather than merges 2. It requires manual invocation every time 3. It doesn't support multiple levels of hierarchy --- ### Secondary Concern: Instruction Files Related to config hierarchy, I'd want instruction files (`AGENTS.md`) to follow the same pattern. Currently I can work around this with the `instructions` config field: ```jsonc // In ~/Projects/ClientA/opencode.jsonc { "instructions": ["~/Projects/ClientA/AGENTS.md"], "mcp": { /* client-specific MCPs */ } } ``` If config hierarchy worked, this would "just work" - each level's config would add its own `AGENTS.md` via the `instructions` array, and since `instructions` arrays concatenate (per `mergeConfigConcatArrays`), all levels would be included. **One implementation note**: If this feature lands, relative paths in `instructions` (like `"./AGENTS.md"`) would need to be resolved relative to the config file's location before merging, not relative to CWD. Otherwise users would need to use absolute paths at each level. --- ### Summary Would love to see `findUp` optionally continue beyond git boundaries, walking up the filesystem until it hits `$HOME` or a configurable stop point. This would enable: - Client/org-level MCP configurations - Tiered instruction contexts - Reduced duplication across related projects
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
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#7649
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?