Feature hasn't been suggested before.
Describe the enhancement you want to request
Summary
I'd like to propose a small set of generic TUI host extension points that would allow advanced addons to work against official OpenCode builds without requiring a local host patch.
This is not a request to merge a specific product feature.
The goal is to upstream a few host-level hooks so plugins can:
- intercept prompt submission
- react to exact multi-step keybindings
- render notices in the native session view
- project a logical session/transcript policy over the native
session route
- influence how the native session switcher resolves the current/target session
The default UX should remain unchanged when no plugin uses these hooks.
Why this matters
Today, some advanced TUI features are only feasible by shipping:
- a plugin
- plus a local patch over the host/core
That is workable for experimentation, but not ideal for:
- official releases
- binary installs
- upgrades
- long-term maintenance
- independently distributed addons
A small set of generic host hooks would let these addons work as real plugins instead of local patches.
Non-goals
This proposal is not asking to upstream:
- a specific background-tasks feature
- any plugin-specific KV shape
- any runtime/server behavior
- any hardcoded feature logic in core
The intention is to keep core generic and let plugins own feature-specific policy.
Proposed host hooks
1. Exact multi-stroke keybinding sequences
Examples:
ctrl+b ctrl+bctrl+f ctrl+f
This is broadly useful beyond any single addon.
2. Prompt submit interception
A host hook that allows a plugin to intercept or override prompt submission while preserving native prompt rendering.
Conceptual need:
- native prompt remains the host UI
- plugin can decide how the submission is routed
This capability exists in local experimentation and seems broadly reusable.
3. Session notice slot
A generic insertion point inside the native session view for banners/notices/hints.
Examples of generic uses:
- inspection notices
- mode banners
- contextual session hints
This avoids hardcoding feature-specific copy into core.
4. Session projection adapter
A plugin hook to provide a partial projection policy for the native session view, with native fallback when no adapter is registered.
Conceptual responsibilities:
- resolve active session id
- resolve visible messages
- resolve prompt visibility
- resolve permission/question routing
- surface inspection state
Important:
- core still renders the native
session view
- plugin only provides policy
- default behavior remains unchanged
5. Session list adapter
A plugin hook to provide a partial projection policy for the native session switcher/list.
Conceptual responsibilities:
- resolve current highlighted session
- resolve navigation target before switching
- optional pre-navigation cleanup hook
Important:
- this avoids fragile command shadowing
- native session list remains the host UI
6. Busy-input policy hook
There is also a need to let plugins express that a session may be technically busy while the prompt should still remain logically usable.
A simple boolean works, but this may deserve a more generic shape than allowSubmitWhenBusy.
Open question:
- keep a boolean?
- or expose a more general input/busy strategy?
Design principles
Any accepted API should be:
- generic
- optional
- sync
- deterministic
- side-effect free in the projection layer
- safe when unused
- fallback-compatible with native behavior
Also:
- no runtime/server changes
- no default UX regressions
- no feature-specific logic in core
Suggested rollout order
I would recommend evaluating these in small chunks instead of a single large change:
- multi-stroke keybinding sequences
- prompt submit interception
- session notice slot
- busy-input policy hook
- session projection adapter
- session list adapter
This keeps each change easier to review independently.
Why not just override whole views in plugins?
Because replacing the entire native session route or duplicating native UI components tends to create:
- drift
- duplicated rendering logic
- fragile maintenance
- weaker UX consistency
The proposal here is intentionally narrower:
- native views stay native
- plugins only inject policy and small UI fragments
Practical motivation
There is already a real addon experiment that has validated this architecture:
- plugin-owned feature logic
- host patch only for missing extension points
- no runtime/server changes
- native session UX preserved
That experiment strongly suggests the remaining blocker is host hook availability, not feature design.
Success criteria
A successful outcome would be:
- advanced plugins can work against official OpenCode builds
- no local host patch needed for supported versions
- native TUI behavior remains unchanged for users who don't use these plugins
- core becomes more extensible without becoming feature-specific
Open question for maintainers
Would you prefer discussing these as:
- one RFC issue first and then small PRs, or
- direct small PRs starting from the least controversial hooks (keybind sequences / prompt interception / session notice)?
Feature hasn't been suggested before.
Describe the enhancement you want to request
Summary
I'd like to propose a small set of generic TUI host extension points that would allow advanced addons to work against official OpenCode builds without requiring a local host patch.
This is not a request to merge a specific product feature.
The goal is to upstream a few host-level hooks so plugins can:
sessionrouteThe default UX should remain unchanged when no plugin uses these hooks.
Why this matters
Today, some advanced TUI features are only feasible by shipping:
That is workable for experimentation, but not ideal for:
A small set of generic host hooks would let these addons work as real plugins instead of local patches.
Non-goals
This proposal is not asking to upstream:
The intention is to keep core generic and let plugins own feature-specific policy.
Proposed host hooks
1. Exact multi-stroke keybinding sequences
Examples:
ctrl+b ctrl+bctrl+f ctrl+fThis is broadly useful beyond any single addon.
2. Prompt submit interception
A host hook that allows a plugin to intercept or override prompt submission while preserving native prompt rendering.
Conceptual need:
This capability exists in local experimentation and seems broadly reusable.
3. Session notice slot
A generic insertion point inside the native session view for banners/notices/hints.
Examples of generic uses:
This avoids hardcoding feature-specific copy into core.
4. Session projection adapter
A plugin hook to provide a partial projection policy for the native
sessionview, with native fallback when no adapter is registered.Conceptual responsibilities:
Important:
sessionview5. Session list adapter
A plugin hook to provide a partial projection policy for the native session switcher/list.
Conceptual responsibilities:
Important:
6. Busy-input policy hook
There is also a need to let plugins express that a session may be technically busy while the prompt should still remain logically usable.
A simple boolean works, but this may deserve a more generic shape than
allowSubmitWhenBusy.Open question:
Design principles
Any accepted API should be:
Also:
Suggested rollout order
I would recommend evaluating these in small chunks instead of a single large change:
This keeps each change easier to review independently.
Why not just override whole views in plugins?
Because replacing the entire native
sessionroute or duplicating native UI components tends to create:The proposal here is intentionally narrower:
Practical motivation
There is already a real addon experiment that has validated this architecture:
That experiment strongly suggests the remaining blocker is host hook availability, not feature design.
Success criteria
A successful outcome would be:
Open question for maintainers
Would you prefer discussing these as: