anomalyco/opencode
1
0
Fork 0
mirror of https://github.com/anomalyco/opencode.git synced 2026-07-21 17:56:33 -04:00
Code Issues 5.9k Packages Projects Releases 19 Wiki Activity

Feature Request: Plugin Preference Tabs - Extend SDK for Native Desktop Settings Integration #8154

New Issue
Open
opened 2026-02-16 18:09:17 -05:00 by yindo · 5 comments
yindo commented 2026-02-16 18:09:17 -05:00
Owner
Copy Link
Copy Source

Originally created by @mwyant on GitHub (Jan 31, 2026).

Originally assigned to: @adamdotdevin on GitHub.

Overview

AI-authored feature request submitted by Mike Wyant Jr (@mwyant)

This feature request proposes extending the Opencode Desktop SDK to allow plugins to register their own preference tabs/windows in the native Desktop settings interface, enabling plugins to expose configurable settings through the GUI rather than requiring manual file editing.

Problem Statement

Currently, Opencode plugins face several limitations regarding configuration:

  1. No Native Settings Integration: Plugins cannot add entries to the Desktop settings menu
  2. Manual Configuration Required: Users must edit configuration files directly
  3. Limited Discoverability: Plugin settings are hidden and not easily accessible
  4. No Standardization: Each plugin handles configuration differently
  5. Poor User Experience: No validation, help text, or dynamic options for plugin settings

Example Case: The small_model configuration exists in opencode.jsonc but can only be set via file editing, with no GUI access or validation of model availability.

Proposed Solution

1. New Plugin SDK Hook: preferences

Extend the plugin SDK with a new preferences hook that allows plugins to register their settings:

interface PreferencesHook {
  // Register a preference tab
  register: (input: PreferenceRegistration) => Promise<void>;
  
  // Handle preference changes
  change?: (input: PreferenceChange) => Promise<void>;
  
  // Validate preference values
  validate?: (input: PreferenceValidation) => Promise<ValidationResult>;
}

interface PreferenceRegistration {
  id: string;                    // Unique identifier
  title: string;                 // Display name for tab
  icon?: string;                 // Icon identifier
  requiresRestart?: boolean;     // Whether changes need restart
  schema: PreferenceSchema;       // Field definitions
  defaults: Record<string, any>;  // Default values
  ui?: UIPreferences;            // UI rendering hints
}

2. Desktop Settings Extension

Extend the Desktop application to:

  • Dynamic Tab Registration: Allow plugins to add tabs to settings window
  • Auto-Generated UI: Render forms from preference schemas
  • Real-time Validation: Live validation with error messages
  • Provider Integration: Dynamic options from model providers
  • Restart Handling: Detect and prompt for restart when needed

3. Preference Schema System

Define a comprehensive schema system for different field types:

interface PreferenceSchema {
  [key: string]: {
    type: 'string' | 'number' | 'boolean' | 'select' | 'multiselect' | 'file' | 'directory';
    description?: string;
    default?: any;
    validation?: ValidationRule;
    options?: Array<{label: string; value: any}>;  // For selects
    provider?: string;                             // Dynamic options from providers
    help?: string;                                  // Help text for users
  };
}

Implementation Plan

Phase 1: Core SDK Extension

  • Add preferences hook to plugin SDK
  • Implement preference registry in Desktop
  • Create basic UI extension points
  • Integrate with existing configuration system

Phase 2: Test Case Implementation

Implement the small_model configuration as the test case:

  • Plugin that registers a "Small Model" preference tab
  • Model selection dropdown with provider integration
  • Validation of model availability
  • Restart notification on changes

Phase 3: Documentation & Examples

  • Plugin development guide for preferences
  • Example implementations
  • API documentation
  • Migration guide for existing plugins

Benefits

  1. Improved User Experience: Native GUI access to plugin settings
  2. Better Discoverability: Plugin settings appear in familiar settings interface
  3. Standardization: Consistent configuration patterns across plugins
  4. Validation: Real-time validation prevents configuration errors
  5. Dynamic Options: Plugins can provide context-aware settings
  6. Professional Integration: Matches Desktop app design patterns

Technical Considerations

Backward Compatibility

  • Existing plugins continue to work unchanged
  • Preference hook is optional and additive
  • Configuration system remains compatible

Security & Validation

  • Schema-based validation prevents malformed configurations
  • Plugin isolation prevents cross-plugin interference
  • Configuration atomicity prevents corruption

Performance

  • Lazy loading of preference tabs
  • Efficient schema validation
  • Minimal overhead for plugins without preferences

Use Cases Beyond Test Case

  1. Model Configuration: Temperature, max tokens, provider settings
  2. Theme & UI: Custom themes, font settings, layout preferences
  3. Integration Settings: API keys, endpoints, timeouts
  4. Behavioral Settings: Auto-save behavior, notification preferences
  5. Development Tools: Debug settings, logging levels, feature flags

Success Metrics

  • Plugin preference tabs appear in Desktop settings
  • Small model selection works with validation
  • Model provider integration functions correctly
  • Configuration persistence and restart handling
  • At least 3 community plugins adopt the new system

Implementation Timeline

  • Phase 1: 2-3 weeks (SDK foundation)
  • Phase 2: 1-2 weeks (Test case implementation)
  • Phase 3: 1 week (Documentation & examples)

Call to Action

This enhancement would significantly improve the plugin ecosystem by providing a standardized, user-friendly way for plugins to expose configurable settings. The small_model configuration serves as an immediate, practical example that would benefit users while demonstrating the system's value.

Please consider this feature request for inclusion in an upcoming release. I'm available to provide use case guidance for UX/UI dev, or can contribute to the development effort via LLM tools. NOTE: I'm an old SysAdmin/DevOps guy, not a coder, so don't trust my code. lol

Technical Details for Implementation Team:

  • Repository: anomalyco/opencode
  • Focus Area: packages/desktop/ and plugin SDK
  • Configuration Integration: Existing opencode.jsonc system
  • UI Framework: Current Desktop app technology stack
  • Test Case: small_model field configuration with provider integration

Thank you for considering this enhancement to the Opencode platform!

Originally created by @mwyant on GitHub (Jan 31, 2026). Originally assigned to: @adamdotdevin on GitHub. ## Overview **AI-authored feature request submitted by Mike Wyant Jr (@mwyant)** This feature request proposes extending the Opencode Desktop SDK to allow plugins to register their own preference tabs/windows in the native Desktop settings interface, enabling plugins to expose configurable settings through the GUI rather than requiring manual file editing. ## Problem Statement Currently, Opencode plugins face several limitations regarding configuration: 1. **No Native Settings Integration**: Plugins cannot add entries to the Desktop settings menu 2. **Manual Configuration Required**: Users must edit configuration files directly 3. **Limited Discoverability**: Plugin settings are hidden and not easily accessible 4. **No Standardization**: Each plugin handles configuration differently 5. **Poor User Experience**: No validation, help text, or dynamic options for plugin settings **Example Case**: The `small_model` configuration exists in `opencode.jsonc` but can only be set via file editing, with no GUI access or validation of model availability. ## Proposed Solution ### 1. New Plugin SDK Hook: `preferences` Extend the plugin SDK with a new `preferences` hook that allows plugins to register their settings: ```typescript interface PreferencesHook { // Register a preference tab register: (input: PreferenceRegistration) => Promise<void>; // Handle preference changes change?: (input: PreferenceChange) => Promise<void>; // Validate preference values validate?: (input: PreferenceValidation) => Promise<ValidationResult>; } interface PreferenceRegistration { id: string; // Unique identifier title: string; // Display name for tab icon?: string; // Icon identifier requiresRestart?: boolean; // Whether changes need restart schema: PreferenceSchema; // Field definitions defaults: Record<string, any>; // Default values ui?: UIPreferences; // UI rendering hints } ``` ### 2. Desktop Settings Extension Extend the Desktop application to: - **Dynamic Tab Registration**: Allow plugins to add tabs to settings window - **Auto-Generated UI**: Render forms from preference schemas - **Real-time Validation**: Live validation with error messages - **Provider Integration**: Dynamic options from model providers - **Restart Handling**: Detect and prompt for restart when needed ### 3. Preference Schema System Define a comprehensive schema system for different field types: ```typescript interface PreferenceSchema { [key: string]: { type: 'string' | 'number' | 'boolean' | 'select' | 'multiselect' | 'file' | 'directory'; description?: string; default?: any; validation?: ValidationRule; options?: Array<{label: string; value: any}>; // For selects provider?: string; // Dynamic options from providers help?: string; // Help text for users }; } ``` ## Implementation Plan ### Phase 1: Core SDK Extension - Add `preferences` hook to plugin SDK - Implement preference registry in Desktop - Create basic UI extension points - Integrate with existing configuration system ### Phase 2: Test Case Implementation Implement the `small_model` configuration as the test case: - Plugin that registers a "Small Model" preference tab - Model selection dropdown with provider integration - Validation of model availability - Restart notification on changes ### Phase 3: Documentation & Examples - Plugin development guide for preferences - Example implementations - API documentation - Migration guide for existing plugins ## Benefits 1. **Improved User Experience**: Native GUI access to plugin settings 2. **Better Discoverability**: Plugin settings appear in familiar settings interface 3. **Standardization**: Consistent configuration patterns across plugins 4. **Validation**: Real-time validation prevents configuration errors 5. **Dynamic Options**: Plugins can provide context-aware settings 6. **Professional Integration**: Matches Desktop app design patterns ## Technical Considerations ### Backward Compatibility - Existing plugins continue to work unchanged - Preference hook is optional and additive - Configuration system remains compatible ### Security & Validation - Schema-based validation prevents malformed configurations - Plugin isolation prevents cross-plugin interference - Configuration atomicity prevents corruption ### Performance - Lazy loading of preference tabs - Efficient schema validation - Minimal overhead for plugins without preferences ## Use Cases Beyond Test Case 1. **Model Configuration**: Temperature, max tokens, provider settings 2. **Theme & UI**: Custom themes, font settings, layout preferences 3. **Integration Settings**: API keys, endpoints, timeouts 4. **Behavioral Settings**: Auto-save behavior, notification preferences 5. **Development Tools**: Debug settings, logging levels, feature flags ## Success Metrics - [ ] Plugin preference tabs appear in Desktop settings - [ ] Small model selection works with validation - [ ] Model provider integration functions correctly - [ ] Configuration persistence and restart handling - [ ] At least 3 community plugins adopt the new system ## Implementation Timeline - **Phase 1**: 2-3 weeks (SDK foundation) - **Phase 2**: 1-2 weeks (Test case implementation) - **Phase 3**: 1 week (Documentation & examples) ## Call to Action This enhancement would significantly improve the plugin ecosystem by providing a standardized, user-friendly way for plugins to expose configurable settings. The small_model configuration serves as an immediate, practical example that would benefit users while demonstrating the system's value. Please consider this feature request for inclusion in an upcoming release. I'm available to provide use case guidance for UX/UI dev, or can contribute to the development effort via LLM tools. NOTE: I'm an old SysAdmin/DevOps guy, not a coder, so don't trust my code. lol --- **Technical Details for Implementation Team:** - Repository: `anomalyco/opencode` - Focus Area: `packages/desktop/` and plugin SDK - Configuration Integration: Existing `opencode.jsonc` system - UI Framework: Current Desktop app technology stack - Test Case: `small_model` field configuration with provider integration Thank you for considering this enhancement to the Opencode platform!
yindo added the web label 2026-02-16 18:09:17 -05:00
yindo commented 2026-02-16 18:09:17 -05:00
Author
Owner
Copy Link
Copy Source

@github-actions[bot] commented on GitHub (Jan 31, 2026):

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

  • #4393: [FEATURE]: Allow plugins to have their own configuration - Foundational request for plugin configuration support
  • #8320: [FEATURE]: Manage plugins like providers in configuration - Request for project-level plugin configuration overrides
  • #10899: [FEATURE]: Optimize hot reloading for configuration changes - Related to dynamic settings without restart requirement
  • #6521: [FEATURE]: Window System as Foundation for UI Plugin Ecosystem - Related effort for plugin UI extensibility in the desktop environment

Feel free to ignore if your specific use case requires additional features beyond these existing requests.

@github-actions[bot] commented on GitHub (Jan 31, 2026): This issue might be a duplicate of existing issues. Please check: - #4393: [FEATURE]: Allow plugins to have their own configuration - Foundational request for plugin configuration support - #8320: [FEATURE]: Manage plugins like providers in configuration - Request for project-level plugin configuration overrides - #10899: [FEATURE]: Optimize hot reloading for configuration changes - Related to dynamic settings without restart requirement - #6521: [FEATURE]: Window System as Foundation for UI Plugin Ecosystem - Related effort for plugin UI extensibility in the desktop environment Feel free to ignore if your specific use case requires additional features beyond these existing requests.
yindo commented 2026-02-16 18:09:17 -05:00
Author
Owner
Copy Link
Copy Source

@mwyant commented on GitHub (Jan 31, 2026):

Addendum: Issue Review and Relationship to Existing Requests

After a comprehensive review of existing issues in the Opencode repository, this feature request stands as a unique and comprehensive solution that addresses multiple related concerns through a systematic approach.

Related Issues Analysis

Issue #8609: "Misleading documentation or incorrect behaviour about small_model"

  • Current Problem: Users cannot configure small_model through Desktop GUI, leading to unexpected provider usage and privacy concerns
  • Our Solution: Direct GUI access with model provider integration would resolve these configuration and transparency issues

Issue #10899: "Optimize hot reloading for configuration changes - all modifications require app restart to take effect"

  • Current Problem: All configuration changes require application restart
  • Our Solution: While our primary design includes restart handling for safety, we propose incorporating dynamic refresh capabilities as an enhancement

Advantages Over Piecemeal Solutions

  1. Foundation vs. Symptom Fix: This proposal addresses the root architectural limitation (no plugin GUI integration) rather than individual configuration issues

  2. Cross-Platform Benefits: The SDK extensions proposed here would benefit both Desktop and TUI environments, creating consistent configuration experiences across all Opencode interfaces

  3. Scalable Architecture: Establishes patterns that can be reused for future configuration needs beyond small_model

Enhanced Implementation Consideration

Dynamic Refresh Integration:
We recommend incorporating the hot-reloading concepts from issue #10899 as a follow-up enhancement to our proposed preferences system. Specifically:

  • Implement configuration change detection and hot-reload for settings that don't require full application restart
  • Maintain safety mechanisms for critical configuration changes
  • Provide user feedback indicating which changes require restart vs. which take effect immediately

Cross-Platform Consistency

The proposed SDK extensions should be designed with TUI compatibility in mind:

  • Preference schemas should render appropriately in both GUI and terminal environments
  • Configuration validation and management logic should be shared between Desktop and TUI
  • API consistency across all Opencode clients

Conclusion

This feature request represents the most comprehensive solution to the plugin configuration challenge, addressing multiple existing issues through a single, well-architected enhancement that benefits the entire Opencode ecosystem across all platforms.

@mwyant commented on GitHub (Jan 31, 2026): ## Addendum: Issue Review and Relationship to Existing Requests After a comprehensive review of existing issues in the Opencode repository, this feature request stands as a **unique and comprehensive solution** that addresses multiple related concerns through a systematic approach. ### Related Issues Analysis **Issue #8609**: "Misleading documentation or incorrect behaviour about small_model" - **Current Problem**: Users cannot configure small_model through Desktop GUI, leading to unexpected provider usage and privacy concerns - **Our Solution**: Direct GUI access with model provider integration would resolve these configuration and transparency issues **Issue #10899**: "Optimize hot reloading for configuration changes - all modifications require app restart to take effect" - **Current Problem**: All configuration changes require application restart - **Our Solution**: While our primary design includes restart handling for safety, we propose incorporating dynamic refresh capabilities as an enhancement ### Advantages Over Piecemeal Solutions 1. **Foundation vs. Symptom Fix**: This proposal addresses the root architectural limitation (no plugin GUI integration) rather than individual configuration issues 2. **Cross-Platform Benefits**: The SDK extensions proposed here would benefit **both Desktop and TUI environments**, creating consistent configuration experiences across all Opencode interfaces 3. **Scalable Architecture**: Establishes patterns that can be reused for future configuration needs beyond small_model ### Enhanced Implementation Consideration **Dynamic Refresh Integration**: We recommend incorporating the hot-reloading concepts from issue #10899 as a follow-up enhancement to our proposed preferences system. Specifically: - Implement configuration change detection and hot-reload for settings that don't require full application restart - Maintain safety mechanisms for critical configuration changes - Provide user feedback indicating which changes require restart vs. which take effect immediately ### Cross-Platform Consistency The proposed SDK extensions should be designed with **TUI compatibility** in mind: - Preference schemas should render appropriately in both GUI and terminal environments - Configuration validation and management logic should be shared between Desktop and TUI - API consistency across all Opencode clients ### Conclusion This feature request represents the most comprehensive solution to the plugin configuration challenge, addressing multiple existing issues through a single, well-architected enhancement that benefits the entire Opencode ecosystem across all platforms.
yindo commented 2026-02-16 18:09:17 -05:00
Author
Owner
Copy Link
Copy Source

@mwyant commented on GitHub (Jan 31, 2026):

Phase 1 Complete: Plugin Preference SDK Foundation

✅ Core SDK foundation implemented (Phase 1)

This comment updates the previous automated status post with corrected details and links. Phase 1 delivers the SDK pieces required for plugins to register preference tabs and expose configurable settings to the Desktop (and other clients).

PR (implementation): https://github.com/anomalyco/opencode/pull/11507

Files added (location)

  • packages/opencode/src/plugin/preferences/types.ts — core interfaces and Zod schemas
  • packages/opencode/src/plugin/preferences/registry.ts — in-memory registry and lifecycle handlers
  • packages/opencode/src/plugin/preferences/index.ts — module exports

Key features implemented

  1. Schema system supporting string, number, boolean, select, multiselect, file, directory
  2. Validation rules: pattern matching, min/max, length checks, and custom validators
  3. Provider integration: ability to surface dynamic option lists (e.g. model provider)
  4. UI hints: grouping, ordering, and width preferences to guide Desktop/TUI rendering
  5. Type safety: Zod schemas ensure plugin registrations are validated at runtime

Architecture benefits

  • Backward compatible: existing plugins remain unaffected unless they opt into the new preferences hook
  • Extensible: new preference types and validation rules can be added easily
  • Cross-platform: foundation works for Desktop, TUI, and web clients (shared schema + registry)
  • Performance-aware: registry is lightweight and validation is performed lazily where possible

Next steps (Phase 2+)

  1. Desktop UI integration: render registered schemas as native preference tabs
  2. small_model test plugin: demonstrate model selection, validation, and restart handling
  3. Hot-reload: integrate with issue #10899 to support dynamic refresh of safe settings
  4. Documentation + examples for plugin authors

If you want, I can now proceed with Phase 2 (UI integration) or add unit tests / docs for the SDK pieces first.

@mwyant commented on GitHub (Jan 31, 2026): ## Phase 1 Complete: Plugin Preference SDK Foundation ✅ **Core SDK foundation implemented (Phase 1)** This comment updates the previous automated status post with corrected details and links. Phase 1 delivers the SDK pieces required for plugins to register preference tabs and expose configurable settings to the Desktop (and other clients). PR (implementation): https://github.com/anomalyco/opencode/pull/11507 ### Files added (location) - `packages/opencode/src/plugin/preferences/types.ts` — core interfaces and Zod schemas - `packages/opencode/src/plugin/preferences/registry.ts` — in-memory registry and lifecycle handlers - `packages/opencode/src/plugin/preferences/index.ts` — module exports ### Key features implemented 1. Schema system supporting `string`, `number`, `boolean`, `select`, `multiselect`, `file`, `directory` 2. Validation rules: pattern matching, min/max, length checks, and custom validators 3. Provider integration: ability to surface dynamic option lists (e.g. model provider) 4. UI hints: grouping, ordering, and width preferences to guide Desktop/TUI rendering 5. Type safety: Zod schemas ensure plugin registrations are validated at runtime ### Architecture benefits - Backward compatible: existing plugins remain unaffected unless they opt into the new `preferences` hook - Extensible: new preference types and validation rules can be added easily - Cross-platform: foundation works for Desktop, TUI, and web clients (shared schema + registry) - Performance-aware: registry is lightweight and validation is performed lazily where possible ### Next steps (Phase 2+) 1. Desktop UI integration: render registered schemas as native preference tabs 2. small_model test plugin: demonstrate model selection, validation, and restart handling 3. Hot-reload: integrate with issue #10899 to support dynamic refresh of safe settings 4. Documentation + examples for plugin authors If you want, I can now proceed with Phase 2 (UI integration) or add unit tests / docs for the SDK pieces first.
yindo commented 2026-02-16 18:09:17 -05:00
Author
Owner
Copy Link
Copy Source

@mwyant commented on GitHub (Jan 31, 2026):

Thanks — I reviewed the issues suggested by the automation and assessed their relationship to this request:

After review:

  • #10899 (hot-reload for config changes) is related (we explicitly reference it in the addendum) and should be cross-linked; it focuses on dynamic refresh whereas this request adds the SDK API and UI surface for plugin settings.
  • #8609 (small_model behaviour) is a concrete bug/UX example that motivates this work; fixing that issue alone is insufficient because it does not provide a reusable SDK/UI for other plugins.
  • #4393 / #8320 / #6521 appear to be earlier requests related to plugin/config management or UI foundations — they are related but not direct duplicates of this proposal.

Recommendation:

  1. Keep this issue open as the canonical request for plugin preference tabs / SDK extension. It is intentionally broad and prescriptive (includes interface design, schema, Desktop integration, and a test case).
  2. Mark #10899 and #8609 as related/blocked-by this issue (or add cross-links) rather than marking them duplicates — our PR (https://github.com/anomalyco/opencode/pull/11507) implements Phase 1 of the SDK foundation needed to resolve them more cleanly.
  3. If the maintainers prefer a single umbrella issue, we can merge related issue threads into this one, but given the different scopes (hot-reload vs. UI vs. small_model bug), leaving them separate with cross-links provides clearer tracking.

I can update the issue labels and references if you want. Otherwise I will continue with Phase 2 (Desktop UI) once you confirm the preferred approach.

@mwyant commented on GitHub (Jan 31, 2026): Thanks — I reviewed the issues suggested by the automation and assessed their relationship to this request: - Automated list included: #4393, #8320, #10899, #6521. After review: - #10899 (hot-reload for config changes) is *related* (we explicitly reference it in the addendum) and should be cross-linked; it focuses on dynamic refresh whereas this request adds the SDK API and UI surface for plugin settings. - #8609 (small_model behaviour) is a concrete bug/UX example that motivates this work; fixing that issue alone is insufficient because it does not provide a reusable SDK/UI for other plugins. - #4393 / #8320 / #6521 appear to be earlier requests related to plugin/config management or UI foundations — they are *related* but not direct duplicates of this proposal. Recommendation: 1. Keep this issue open as the canonical request for plugin preference tabs / SDK extension. It is intentionally broad and prescriptive (includes interface design, schema, Desktop integration, and a test case). 2. Mark #10899 and #8609 as related/blocked-by this issue (or add cross-links) rather than marking them duplicates — our PR (https://github.com/anomalyco/opencode/pull/11507) implements Phase 1 of the SDK foundation needed to resolve them more cleanly. 3. If the maintainers prefer a single umbrella issue, we can merge related issue threads into this one, but given the different scopes (hot-reload vs. UI vs. small_model bug), leaving them separate with cross-links provides clearer tracking. I can update the issue labels and references if you want. Otherwise I will continue with Phase 2 (Desktop UI) once you confirm the preferred approach.
yindo commented 2026-02-16 18:09:17 -05:00
Author
Owner
Copy Link
Copy Source

@mwyant commented on GitHub (Jan 31, 2026):

Update: progress, docs, tests, and next steps

Thanks everyone — quick update on where we are and the plan forward. TL;DR: Phase 1 (SDK) is implemented, Phase 2 server + minimal UI wiring is in the branch, unit tests added, and docs updated. Feedback welcome.

What I shipped (branch: mwyant/feature/plugin-preference-tabs-upstream):

  • Phase 1 (SDK): preference types, Zod schemas, and an in-memory registry (PR: https://github.com/anomalyco/opencode/pull/11507)
  • Phase 2 (server + UI skeleton): Hono routes mounted at /preferences and a minimal SolidJS Settings tab that lists plugin tabs and calls validate/apply endpoints
  • Adapter persistence: changes are persisted to project opencode.jsonc under plugin_preferences.<pluginId>.<key>
  • Example plugin: packages/plugin/examples/small-model-plugin.ts (register + validate + change handlers)
  • Tests: unit tests for the PreferenceRegistry (packages/opencode/test/preferences.registry.test.ts) — passing locally
  • Docs: packages/opencode/docs/plugin-preferences.md updated with next steps, vision, and local testing notes
  • Proofreader agent: tools/proofreader.js + agents/proofreader.md to avoid literal escaped-newline issues in automated comments

Quick runtime note

  • Server: I started the backend locally to exercise routes. Initial server startup failed with a missing JSX runtime (react/jsx-dev-runtime) — I added react to the opencode package to resolve that. The server now starts (listening at http://127.0.0.1:4096 for local runs). If your instance requires auth, you may see "Unauthorized" until run with the right flags.

Next steps (proposed & planned)

  1. Adapter tests: add tests that exercise applyPreferenceChange writing to opencode.jsonc in a temp project directory (I can add these next).
  2. UI: improve field rendering (multiselect, file/directory), show clear restart vs immediate-change UX, polish styles and i18n.
  3. small_model PoC: populate the select from provider discovery, add an integration test that performs the roundtrip (register -> list -> validate -> apply -> config updated).
  4. Hot-reload: integrate the dynamic refresh capability (issue #10899) so safe changes apply without restart.
  5. Docs & examples: expand the plugin author guide and add more examples.

Questions for maintainers & reviewers

  • Do you prefer namespaced persistence (plugin_preferences.<pluginId>.<key>) or mapping certain plugin preferences directly to top-level config keys (e.g., small_model)? I recommend namespaced by default to avoid collisions and offer a migration helper for cases that want flat fields.
  • API surface: should we expose the validate endpoint per-field or validate whole-tab payloads at once? Current approach validates per-field sequentially (simple & incrementally friendly).

Request: please review PR #11507 and the Phase 2 files on the branch. I'm ready to iterate per reviewer feedback. If folks prefer, I can open a draft PR specifically for Phase 2 UI work to keep review focused.

Thanks — looking forward to feedback and willing to adjust priorities.

@mwyant commented on GitHub (Jan 31, 2026): Update: progress, docs, tests, and next steps Thanks everyone — quick update on where we are and the plan forward. TL;DR: Phase 1 (SDK) is implemented, Phase 2 server + minimal UI wiring is in the branch, unit tests added, and docs updated. Feedback welcome. What I shipped (branch: `mwyant/feature/plugin-preference-tabs-upstream`): - Phase 1 (SDK): preference types, Zod schemas, and an in-memory registry (PR: https://github.com/anomalyco/opencode/pull/11507) - Phase 2 (server + UI skeleton): Hono routes mounted at `/preferences` and a minimal SolidJS Settings tab that lists plugin tabs and calls validate/apply endpoints - Adapter persistence: changes are persisted to project `opencode.jsonc` under `plugin_preferences.<pluginId>.<key>` - Example plugin: `packages/plugin/examples/small-model-plugin.ts` (register + validate + change handlers) - Tests: unit tests for the PreferenceRegistry (`packages/opencode/test/preferences.registry.test.ts`) — passing locally - Docs: `packages/opencode/docs/plugin-preferences.md` updated with next steps, vision, and local testing notes - Proofreader agent: `tools/proofreader.js` + `agents/proofreader.md` to avoid literal escaped-newline issues in automated comments Quick runtime note - Server: I started the backend locally to exercise routes. Initial server startup failed with a missing JSX runtime (`react/jsx-dev-runtime`) — I added `react` to the opencode package to resolve that. The server now starts (listening at http://127.0.0.1:4096 for local runs). If your instance requires auth, you may see "Unauthorized" until run with the right flags. Next steps (proposed & planned) 1) Adapter tests: add tests that exercise `applyPreferenceChange` writing to `opencode.jsonc` in a temp project directory (I can add these next). 2) UI: improve field rendering (multiselect, file/directory), show clear restart vs immediate-change UX, polish styles and i18n. 3) small_model PoC: populate the select from provider discovery, add an integration test that performs the roundtrip (register -> list -> validate -> apply -> config updated). 4) Hot-reload: integrate the dynamic refresh capability (issue #10899) so safe changes apply without restart. 5) Docs & examples: expand the plugin author guide and add more examples. Questions for maintainers & reviewers - Do you prefer namespaced persistence (`plugin_preferences.<pluginId>.<key>`) or mapping certain plugin preferences directly to top-level config keys (e.g., `small_model`)? I recommend namespaced by default to avoid collisions and offer a migration helper for cases that want flat fields. - API surface: should we expose the `validate` endpoint per-field or validate whole-tab payloads at once? Current approach validates per-field sequentially (simple & incrementally friendly). Request: please review PR #11507 and the Phase 2 files on the branch. I'm ready to iterate per reviewer feedback. If folks prefer, I can open a draft PR specifically for Phase 2 UI work to keep review focused. Thanks — looking forward to feedback and willing to adjust priorities.
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 web
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#8154
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?