Repository navigation
Closed
Labels
discussionUsed for feature requests, proposals, ideas, etc. Open discussionUsed for feature requests, proposals, ideas, etc. Open discussion
Description
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
I’d like profiles for full configuration sets, not just auth. Specifically, I have multiple oh-my-opencode configs that I currently swap manually, and I want to switch between them as profiles.
What I want 
- Named profiles (e.g. Personal, Work, Client‑A, Client‑B) that each define:
- Active configuration files / directories.
- Enabled plugins / subagents / tools.
- Default models and providers.
- Per‑profile environment (env vars, project roots, workspace layout).
- A fast way to switch profiles:
- From the UI (visible selector).
- Via a command / keybinding.
- A clear indicator of the current profile so I don’t accidentally run the wrong config.
Why this is useful 
-
Different contexts (personal, work, different clients) need very different configurations and constraints.
-
Today, I have to:
- Manually swap configuration folders / files.
- Restart or reload things to pick up the new setup.
- Remember which config is currently active, which is error‑prone.
-
Profiles would:
- Make context switching fast and safe.
- Keep work and personal / client setups clearly separated.
- Encourage focused, minimal configs instead of one huge, overloaded configuration.
Example use case 
- One profile for personal hacking (my own tools, models, repos).
- One profile per client / employer (their tools, providers, repos, security rules).
- For example, I currently maintain multiple configurations (including
oh-my-opencode‑based setups) and have to juggle them manually; profiles would let me encode these as first‑class switches inside OpenCode itself.
Possible implementation 
- Introduce a Profile abstraction that:
- Points to a config root and optional overrides (models, tools, env).
- Is persisted and selectable from the UI and command palette.
- Reload active configuration when the profile changes, without needing manual file juggling.
Reacted by Kelvin Rosado, Hudson Bruno, Sreeram Balamurugan, Kwami Agbodji, Ignacio Ruiz Luque and Kingkor Roy Tirtho
Metadata
Metadata
Assignees
Labels
discussionUsed for feature requests, proposals, ideas, etc. Open discussionUsed for feature requests, proposals, ideas, etc. Open discussion
Activity
github-actions commentedon Feb 7, 2026
This issue might be a duplicate of or closely related to existing issues. Please check:
Feel free to ignore if your specific use case for per-context configuration profiles isn't addressed by these issues.
kagbodji commentedon Feb 16, 2026
would love something like this as well. I'd add to the list of requirements the ability to configure the theme per profile as well. It makes it easy to quickly visually distinguish a work profile from a personal profile. A flag likeopencode --profile $HOME/.config/opencode/personal.json --model claude-opus-4-6would be rad, since the config file already contains many of the configurations needed per profile.I've found a way to do this using
OPENCODE_CONFIG_DIRwith shell aliases. For example, I have aliasesalias oc-personal='OPENCODE_CONFIG_DIR=$HOME/.config/opencode-profiles/personal opencodealias oc-work='OPENCODE_CONFIG_DIR=$HOME/.config/opencode-profiles/work opencodeI have a default
~HOME/.config/opencode/opencode.jsonconfig which sets up providers, shared MCPs, etc. In the$HOME/.config/opencode-profiles/{personal,work}directories, I have opencode.json with specific configurations for the respective profiles. This works for my use cases because opencode configs are additive, so it first reads the default config, then merges that with the profile configs, overwriting any dupes. This gives me what I want, which is different themes and providers for personal/work. I suppose it would address things like different skills and such also if needed by creating those configs in the personal/work dirs (haven't tested b/c it's not something I currently need).bsreeram08 commentedon Feb 17, 2026
Thanks you so much.
Disservin commentedon Aug 14, 2026
This isn't working for separate auth because the auth info is saved in
~/.local/share/opencode/auth.json