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

[FEATURE]: configuration profiles (per‑context setups) #8781

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

Originally created by @bsreeram08 on GitHub (Feb 7, 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

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:
    1. Active configuration files / directories.
    2. Enabled plugins / subagents / tools.
    3. Default models and providers.
    4. Per‑profile environment (env vars, project roots, workspace layout).
  • A fast way to switch profiles:
    1. From the UI (visible selector).
    2. 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:

    1. Manually swap configuration folders / files.
    2. Restart or reload things to pick up the new setup.
    3. Remember which config is currently active, which is error‑prone.

  • Profiles would:

    1. Make context switching fast and safe.
    2. Keep work and personal / client setups clearly separated.
    3. 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.
Originally created by @bsreeram08 on GitHub (Feb 7, 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 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: 1. Active configuration files / directories. 2. Enabled plugins / subagents / tools. 3. Default models and providers. 4. Per‑profile environment (env vars, project roots, workspace layout). - A fast way to switch profiles: 1. From the UI (visible selector). 2. 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: 1. Manually swap configuration folders / files. 2. Restart or reload things to pick up the new setup. 3. Remember which config is currently active, which is error‑prone. - Profiles would: 1. Make context switching fast and safe. 2. Keep work and personal / client setups clearly separated. 3. 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.
yindo added the discussion label 2026-02-16 18:10:50 -05:00
yindo commented 2026-02-16 18:10:50 -05:00
Author
Owner
Copy Link
Copy Source

@github-actions[bot] commented on GitHub (Feb 7, 2026):

This issue might be a duplicate of or closely related to existing issues. Please check:

  • #5391: [FEATURE]: multiple auth profiles per provider — requests the ability to have multiple profiles per provider
  • #10133: [FEATURE]: Unified configuration structure — proposes unifying the configuration file structure
  • #12498: [FEATURE]: Config-driven agent system — broader configuration management with full modular control

Feel free to ignore if your specific use case for per-context configuration profiles isn't addressed by these issues.

@github-actions[bot] commented on GitHub (Feb 7, 2026): This issue might be a duplicate of or closely related to existing issues. Please check: - #5391: [FEATURE]: multiple auth profiles per provider — requests the ability to have multiple profiles per provider - #10133: [FEATURE]: Unified configuration structure — proposes unifying the configuration file structure - #12498: [FEATURE]: Config-driven agent system — broader configuration management with full modular control Feel free to ignore if your specific use case for per-context configuration profiles isn't addressed by these issues.
yindo commented 2026-02-16 18:10:50 -05:00
Author
Owner
Copy Link
Copy Source

@kagbodji commented on GitHub (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 like opencode --profile $HOME/.config/opencode/personal.json --model claude-opus-4-6 would 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_DIR with shell aliases. For example, I have aliases

  • alias oc-personal='OPENCODE_CONFIG_DIR=$HOME/.config/opencode-profiles/personal opencode
  • alias oc-work='OPENCODE_CONFIG_DIR=$HOME/.config/opencode-profiles/work opencode

I have a default ~HOME/.config/opencode/opencode.json config 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).

@kagbodji commented on GitHub (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 like `opencode --profile $HOME/.config/opencode/personal.json --model claude-opus-4-6` would 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_DIR` with shell aliases. For example, I have aliases - `alias oc-personal='OPENCODE_CONFIG_DIR=$HOME/.config/opencode-profiles/personal opencode` - `alias oc-work='OPENCODE_CONFIG_DIR=$HOME/.config/opencode-profiles/work opencode` I have a default `~HOME/.config/opencode/opencode.json` config 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).
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#8781
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?