parent folder config scope

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

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

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

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

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

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:

~/.config/opencode/opencode.jsonc (global)
~/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:

It overrides rather than merges
It requires manual invocation every time
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

That would be amazing !

@thdxr

@thdxr Is there anything we can do to have this PR accepted ?

feat(config): add configBoundary option for parent config traversal

Automated: closing question issues.

GitHub Issues are for bug reports and feature requests only — questions / support are no longer tracked here.

For help & questions: https://discord.gg/opencode
Billing issues with Opencode Go / Zen: help@anoma.ly

If this is a bug or feature request, please open a new issue with the appropriate template.

Navigation Menu

Repository navigation

parent folder config scope #10707

Question

Use Case: Multi-Client Consultant Structure

Secondary Concern: Instruction Files

Summary

Metadata

Assignees

Labels

Type

Projects

Milestone

Relationships

Development

parent folder config scope #10707

Description

Question

Activity

github-actions commented on Jan 26, 2026

cravenceiling commented on Jan 26, 2026

Flare576 commented on Feb 9, 2026

Use Case: Multi-Client Consultant Structure

Secondary Concern: Instruction Files

Summary

yoobi commented on Feb 24, 2026

yoobi commented on Mar 17, 2026

rekram1-node commented on Jun 23, 2026

Metadata

Metadata

Assignees

Labels

Type

Projects

Milestone

Relationships

Development

Issue actions