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

feat: add renderAsAssistant field for user messages to enable plugin content display #8219

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

Originally created by @sdip15fa on GitHub (Feb 1, 2026).

Originally assigned to: @thdxr on GitHub.

Description

Plugins need the ability to display generated content (like plans, summaries, or reports) with assistant styling before requesting user approval or action. Currently, plugins can only send regular user messages, which don't have the same visual presentation as assistant messages.

Use Case

The plan-mode plugin is the primary use case:

  1. Plugin generates an implementation plan
  2. Plugin needs to display the plan beautifully to the user
  3. Plugin needs to request approval via built-in plan_exit tool
  4. User reviews formatted plan and approves/rejects

Without this feature, plan display looks like a regular user message instead of a nicely formatted assistant response.

Proposed Solution

Add an optional renderAsAssistant: boolean field to user messages that tells the UI to render them with assistant styling.

Implementation

Backend:

  • Add renderAsAssistant to UserMessage schema in message-v2.ts
  • Pass field through in prompt.ts
  • Regenerate SDK types

Frontend:

  • Update Message component in message-part.tsx to check field
  • When renderAsAssistant: true, use AssistantMessageDisplay instead of user styling
  • Update TUI component similarly

API Example

// In plugin code
await context.addUserMessage({
  content: "# Implementation Plan\n\n...",
  renderAsAssistant: true  // ← Display with assistant styling
});

Benefits

  1. Better UX - Plugins can present content beautifully
  2. Clear separation - Display vs. approval are separate concerns
  3. Flexible - Works for any plugin that needs formatted output
  4. Backward compatible - Field is optional, defaults to normal user message

Alternatives Considered

  1. Let plugins send assistant messages - This would pollute conversation history and confuse turn-taking
  2. Custom styling field - Over-engineered; we just need existing assistant styling
  3. Built-in plan display tool - Too specific; this is a general plugin capability

Integration

Works with experimental plan mode flag (OPENCODE_EXPERIMENTAL_PLAN_MODE=true) which provides:

  • plan_exit built-in tool (shows Yes/No buttons, handles agent switching)
  • Plan-mode plugin (uses renderAsAssistant for display)

Requirements

  • Add renderAsAssistant field to user message schema
  • Update UI components to respect the field
  • Regenerate SDK types
  • Maintain backward compatibility
  • No breaking changes
Originally created by @sdip15fa on GitHub (Feb 1, 2026). Originally assigned to: @thdxr on GitHub. ## Description Plugins need the ability to display generated content (like plans, summaries, or reports) with assistant styling before requesting user approval or action. Currently, plugins can only send regular user messages, which don't have the same visual presentation as assistant messages. ## Use Case The **plan-mode plugin** is the primary use case: 1. Plugin generates an implementation plan 2. Plugin needs to **display** the plan beautifully to the user 3. Plugin needs to **request approval** via built-in `plan_exit` tool 4. User reviews formatted plan and approves/rejects Without this feature, plan display looks like a regular user message instead of a nicely formatted assistant response. ## Proposed Solution Add an optional `renderAsAssistant: boolean` field to user messages that tells the UI to render them with assistant styling. ### Implementation **Backend:** - Add `renderAsAssistant` to `UserMessage` schema in `message-v2.ts` - Pass field through in `prompt.ts` - Regenerate SDK types **Frontend:** - Update `Message` component in `message-part.tsx` to check field - When `renderAsAssistant: true`, use `AssistantMessageDisplay` instead of user styling - Update TUI component similarly ### API Example ```typescript // In plugin code await context.addUserMessage({ content: "# Implementation Plan\n\n...", renderAsAssistant: true // ← Display with assistant styling }); ``` ## Benefits 1. **Better UX** - Plugins can present content beautifully 2. **Clear separation** - Display vs. approval are separate concerns 3. **Flexible** - Works for any plugin that needs formatted output 4. **Backward compatible** - Field is optional, defaults to normal user message ## Alternatives Considered 1. **Let plugins send assistant messages** - This would pollute conversation history and confuse turn-taking 2. **Custom styling field** - Over-engineered; we just need existing assistant styling 3. **Built-in plan display tool** - Too specific; this is a general plugin capability ## Integration Works with experimental plan mode flag (`OPENCODE_EXPERIMENTAL_PLAN_MODE=true`) which provides: - `plan_exit` built-in tool (shows Yes/No buttons, handles agent switching) - Plan-mode plugin (uses `renderAsAssistant` for display) ## Requirements - [ ] Add `renderAsAssistant` field to user message schema - [ ] Update UI components to respect the field - [ ] Regenerate SDK types - [ ] Maintain backward compatibility - [ ] No breaking changes
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#8219
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?