Skip to content

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

Closed

Description

@bsreeram08

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.

Activity

  1. added
    discussionUsed for feature requests, proposals, ideas, etc. Open discussion
    on Feb 7, 2026
  2. github-actions commented on Feb 7, 2026

    @github-actions
    Contributor

    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.

  3. kagbodji commented on Feb 16, 2026

    @kagbodji

    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).

  4. bsreeram08 commented on Feb 17, 2026

    @bsreeram08
    Author

    Thanks you so much.

  5. Disservin commented on Aug 14, 2026

    @Disservin

    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).

    This isn't working for separate auth because the auth info is saved in ~/.local/share/opencode/auth.json

Sign up for free to join this conversation on GitHub. Already have an account? Sign in to comment

Metadata

Metadata

Assignees

Labels

discussionUsed for feature requests, proposals, ideas, etc. Open discussion

Type

No type

Projects

No projects

    Milestone

    No milestone

    Relationships

    None yet

    Development

    No branches or pull requests

    Issue actions