feat(opencode): add /yolo toggle for auto-approving permissions

[salema97]

Issue for this PR

Closes #

Type of change

• New feature

What does this PR do?

Adds a new /yolo slash command in the TUI session that toggles auto-approval of all permission requests without prompting the user. This is useful for power users who want to skip repetitive permission dialogs during a session while keeping the permission system intact.

The implementation uses the existing KV store to persist the toggle state across the session, and auto-replies to permission.asked events when the mode is active.

Changes:

• TUI session commands: new /yolo slash command in the command palette (toggles on/off)
• KV store: persists yolo_mode state across the session
• TUI footer: shows YOLO indicator in warning color when active
• TUI sidebar: shows YOLO MODE badge above the version footer
• TUI sync: auto-replies permissions with reply: "once" when kv.get('yolo_mode') is true

How did you verify your code works?

• Verified the /yolo command appears in the session command palette
• Verified toggling updates the KV store and shows the correct toast message
• Verified the footer and sidebar indicators render conditionally based on KV state
• Verified the sync handler auto-replies permission events when the mode is enabled

Screenshots / recordings

N/A — TUI terminal UI, no graphical screenshots.

Checklist

• I have tested my changes locally
• I have not included unrelated changes in this PR

[github-actions]

The following comment was made by an LLM, it may be inaccurate:

Potential Duplicate Found:

• PR feat(opencode): add /yolo toggle and per-agent thinking control #27851: feat(opencode): add /yolo toggle and per-agent thinking control
  • feat(opencode): add /yolo toggle and per-agent thinking control #27851

Why it may be related: This PR also implements a /yolo toggle feature. While PR #27851 appears to add both /yolo toggle AND per-agent thinking control (broader scope), there's a clear overlap with the /yolo toggle functionality. Both PRs likely implement similar command handling and KV store persistence for the yolo mode state. Consider checking if these PRs are addressing overlapping functionality or if they can be consolidated.