Feature Request: Add Prefix Requirements for Permission Prompts

Summary

Add configuration options to require text prefixes for permission responses (accept/reject/accept always) to prevent accidental approvals of sensitive operations.

Problem

Currently, OpenCode's permission system uses single keystrokes for responses:

• Enter - Accept once
• a - Accept always
• Esc - Reject

This creates a safety risk where users can accidentally press "a" and grant permanent permission for sensitive operations like git push, rm -rf, or file modifications. The single-keystroke approach prioritizes speed over safety, which may not be appropriate for all use cases.

Proposed Solution

Add a new configuration option permission.requirePrefix that allows users to require typed confirmation for permission responses:

Configuration Schema

{
  "$schema": "https://opencode.ai/config.json",
  "permission": {
    "edit": "ask",
    "bash": "ask",
    "requirePrefix": {
      "enabled": true,
      "acceptOnce": "yes",
      "acceptAlways": "yes always",
      "reject": "no"
    }
  }
}

Alternative Simpler Configuration

{
  "$schema": "https://opencode.ai/config.json",
  "permission": {
    "edit": "ask",
    "bash": "ask",
    "requirePrefix": true // Uses default prefixes: "yes", "yes always", "no"
  }
}

Behavior Changes

When requirePrefix is enabled:

1. Permission prompts show text input field instead of accepting single keystrokes
2. Users must type the full prefix (e.g., "yes always") and press Enter
3. Invalid input shows error message and prompts again
4. Partial matches are rejected to prevent typos from being accepted
5. Case-insensitive matching for better UX
6. Timeout option could auto-reject after X seconds of inactivity

UI Mockup

Current:

Allow opencode to run: git push origin main
enter accept   a accept always   esc reject

With Prefix Required:

Allow opencode to run: git push origin main
Type 'yes' to accept once, 'yes always' to accept always, or 'no' to reject:
> _

Use Cases

1. Production environments where accidental "accept always" could be catastrophic
2. Team environments where junior developers need extra safety guardrails
3. Compliance requirements that mandate explicit confirmation for certain operations
4. CI/CD pipelines where human oversight is required for deployment commands

Implementation Considerations

Files to Modify

1. Configuration Schema (packages/opencode/src/config/config.ts)

   • Add requirePrefix option to permission schema
   • Add validation for prefix strings

2. TUI Permission Handling (packages/tui/internal/tui/tui.go)

   • Replace single-key handling with text input mode
   • Add prefix validation logic

3. Permission UI (packages/tui/internal/components/chat/message.go)

   • Update permission prompt display
   • Add text input field for prefix entry

4. Type Definitions (packages/sdk/go/config.go)

   • Add Go types for new configuration options

Backward Compatibility

• Default behavior unchanged - prefix requirements are opt-in
• Existing configurations continue working without modification
• Graceful fallback if prefix configuration is malformed

Security Benefits

• Prevents accidental "accept always" responses
• Forces deliberate decision-making for sensitive operations
• Audit trail improvement - typed responses are more intentional
• Configurable per-environment - strict in prod, relaxed in dev

Alternatives Considered

1. Confirmation dialog - "Are you sure?" prompt after "accept always"

   • Less flexible than prefix system
   • Still allows accidental double-confirmation

2. Delay before "accept always" - require holding key for 3 seconds

   • Poor UX for legitimate use cases
   • Doesn't prevent accidental presses

3. Remove "accept always" entirely

   • Too restrictive for power users
   • Breaks existing workflows

Related Issues

This addresses the broader security concern of making OpenCode safer for production use while maintaining its developer-friendly nature.

Implementation Priority

Medium-High - This is a safety feature that would benefit enterprise users and teams working with sensitive codebases, but doesn't break existing functionality.

Would you like me to submit this issue to the OpenCode repository? I'm so lazy, sorry.