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]: User plugins should override built-in plugins for the same provider #8566

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

Originally created by @rmk40 on GitHub (Feb 4, 2026).

Originally assigned to: @thdxr on GitHub.

When a user installs a custom plugin that targets the same auth.provider as a built-in plugin, the built-in silently wins. The only workaround is OPENCODE_DISABLE_DEFAULT_PLUGINS=1, which disables all built-in plugins.

Why this matters: If you're developing or testing a modified version of a built-in auth plugin (e.g., a fork of opencode-anthropic-auth), there's no way to have your version take priority without the nuclear option of disabling every default plugin.

Root cause: In plugin/index.ts, user plugins from config.plugin are added to the plugins array before BUILTIN entries:

const plugins = [...(config.plugin ?? [])]
if (!Flag.OPENCODE_DISABLE_DEFAULT_PLUGINS) {
  plugins.push(...BUILTIN)
}

Since ProviderAuth.state() uses fromEntries() on the resulting hooks (which is last-write-wins for duplicate keys), the built-in always overwrites the user's plugin when both target the same provider.

Proposed fix: Swap the order so built-ins load first and user plugins load after. This way fromEntries() naturally gives user plugins priority:

const plugins: string[] = []
if (!Flag.OPENCODE_DISABLE_DEFAULT_PLUGINS) {
  plugins.push(...BUILTIN)
}
plugins.push(...(config.plugin ?? []))

This is a 2-line change. It's fully backward-compatible — users without conflicting plugins see no difference. Users who do install a plugin for the same provider get the override behavior they'd expect.

Originally created by @rmk40 on GitHub (Feb 4, 2026). Originally assigned to: @thdxr on GitHub. When a user installs a custom plugin that targets the same `auth.provider` as a built-in plugin, the built-in silently wins. The only workaround is `OPENCODE_DISABLE_DEFAULT_PLUGINS=1`, which disables *all* built-in plugins. **Why this matters:** If you're developing or testing a modified version of a built-in auth plugin (e.g., a fork of `opencode-anthropic-auth`), there's no way to have your version take priority without the nuclear option of disabling every default plugin. **Root cause:** In `plugin/index.ts`, user plugins from `config.plugin` are added to the `plugins` array *before* `BUILTIN` entries: ```ts const plugins = [...(config.plugin ?? [])] if (!Flag.OPENCODE_DISABLE_DEFAULT_PLUGINS) { plugins.push(...BUILTIN) } ``` Since `ProviderAuth.state()` uses `fromEntries()` on the resulting hooks (which is last-write-wins for duplicate keys), the built-in always overwrites the user's plugin when both target the same provider. **Proposed fix:** Swap the order so built-ins load first and user plugins load after. This way `fromEntries()` naturally gives user plugins priority: ```ts const plugins: string[] = [] if (!Flag.OPENCODE_DISABLE_DEFAULT_PLUGINS) { plugins.push(...BUILTIN) } plugins.push(...(config.plugin ?? [])) ``` This is a 2-line change. It's fully backward-compatible — users without conflicting plugins see no difference. Users who do install a plugin for the same provider get the override behavior they'd expect.
yindo closed this issue 2026-02-16 18:10:17 -05:00
yindo commented 2026-02-16 18:10:17 -05:00
Author
Owner
Copy Link
Copy Source

@rmk40 commented on GitHub (Feb 5, 2026):

Closing — resolved by 9adcf524e which removed opencode-anthropic-auth from the built-in plugins. User plugins are now the only dynamic plugins, so there's no longer a conflict when installing a custom auth plugin for the same provider.

@rmk40 commented on GitHub (Feb 5, 2026): Closing — resolved by 9adcf524e which removed `opencode-anthropic-auth` from the built-in plugins. User plugins are now the only dynamic plugins, so there's no longer a conflict when installing a custom auth plugin for the same provider.
yindo commented 2026-02-16 18:10:17 -05:00
Author
Owner
Copy Link
Copy Source

@rmk40 commented on GitHub (Feb 5, 2026):

Reopening — 47f00d23b re-added opencode-anthropic-auth to BUILTIN, so the override bug is back. Rebasing PR #12224.

@rmk40 commented on GitHub (Feb 5, 2026): Reopening — `47f00d23b` re-added `opencode-anthropic-auth` to `BUILTIN`, so the override bug is back. Rebasing PR #12224.
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#8566
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?