anomalyco/opencode
1
0
Fork 0
mirror of https://github.com/anomalyco/opencode.git synced 2026-07-22 10:15:31 -04:00
Code Issues 5.9k Packages Projects Releases 19 Wiki Activity

Feature Request: Add Prefix Requirements for Permission Prompts #1670

New Issue
Closed
opened 2026-02-16 17:32:05 -05:00 by yindo · 2 comments
yindo commented 2026-02-16 17:32:05 -05:00
Owner
Copy Link
Copy Source

Originally created by @ndrwstn on GitHub (Sep 9, 2025).

Originally assigned to: @adamdotdevin on GitHub.

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.

Originally created by @ndrwstn on GitHub (Sep 9, 2025). Originally assigned to: @adamdotdevin on GitHub. # 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 ```json { "$schema": "https://opencode.ai/config.json", "permission": { "edit": "ask", "bash": "ask", "requirePrefix": { "enabled": true, "acceptOnce": "yes", "acceptAlways": "yes always", "reject": "no" } } } ``` ### Alternative Simpler Configuration ```json { "$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.
yindo closed this issue 2026-02-16 17:32:05 -05:00
yindo commented 2026-02-16 17:32:06 -05:00
Author
Owner
Copy Link
Copy Source

@github-actions[bot] commented on GitHub (Sep 9, 2025):

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

  • #1813: Similar concern about permission safety - requests a toggle between ask/allow modes to prevent accidental permissions
  • #2264: Related to permission handling - requests persisting permission requests across sessions
  • #2039: Related permission enhancement - requests finer-grained file permissions

Feel free to ignore if none of these address your specific case.

@github-actions[bot] commented on GitHub (Sep 9, 2025): This issue might be a duplicate of existing issues. Please check: - #1813: Similar concern about permission safety - requests a toggle between ask/allow modes to prevent accidental permissions - #2264: Related to permission handling - requests persisting permission requests across sessions - #2039: Related permission enhancement - requests finer-grained file permissions Feel free to ignore if none of these address your specific case.
yindo commented 2026-02-16 17:32:06 -05:00
Author
Owner
Copy Link
Copy Source

@ndrwstn commented on GitHub (Nov 21, 2025):

I literally opened a duplicate feature request for this issue #3455. That one is newer and has an additional (and more important issue).

@ndrwstn commented on GitHub (Nov 21, 2025): I literally opened a duplicate feature request for this issue #3455. That one is newer and has an additional (and more important issue).
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#1670
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?