anomalyco / anomalyco/opencode

permissions: V2 “Always allow” silently overrides configured “ask” across future project sessions

Open
#48,456 2 comments 1 reaction 1 assignee View on GitHub

@nexxeln is already working on this.

Since Sep 11, 2026.

2.0
Dominant language
TypeScript
Stars
209k
Forks
27.5k
PR merge metrics
PR metrics pending

Description

Description

In OpenCode V2, selecting Always allow creates a persistent, project-scoped permission in SQLite. That permission takes precedence over an explicit ask rule in configuration and applies to future sessions, including subagents using the same project.
This makes the effective permission policy impossible to determine from the global and project configuration files alone. A user can configure SSH to require approval, then discover that an approval saved days or weeks earlier allows new sessions to execute SSH without prompting.

Additional Context
V1 and V2 have materially different approval lifetimes
In V1 1.18.22, approvals were stored in an in-memory approved array. They were scoped to a running directory instance, rather than strictly to an individual conversation, but were not persisted to disk.
In the inspected V2 implementation:

  • saved approvals are loaded by project_id;
  • saved allow rules are appended after configured rules;
  • consequently, a saved allow takes precedence over configured ask;
  • Always allow writes the approval to SQLite.
    Configured deny is checked separately and remains enforced. This report concerns the loss of the expected approval boundary provided by ask.
Plugins

No response

OpenCode version

0.0.0-beta-19425

Steps to reproduce

The following scenario is supported by the observed session history and the V2 implementation. A fresh end-to-end reproduction was not performed.

  1. Configure SSH to require approval globally:
{
  "permissions": [
    {
      "action": "shell",
      "resource": "ssh *",
      "effect": "ask"
    }
  ]
}
  1. In a project session, approve an SSH permission request using Always allow.
  2. End that session.
  3. Start a new session in the same project, without adding an allow rule to either the global or project configuration.
  4. Have the agent perform an action that invokes SSH.
    The saved project permission allows SSH without a new approval prompt. Because the permission is stored in SQLite, its lifetime also extends beyond process restarts.
    Expected Behavior
    An explicit ask rule should remain a reliable approval boundary across new sessions.
    Temporary approval and persistent policy changes should be clearly separated:
  • Allow once approves one request.
  • Allow for this session approves matching requests within the current session.
  • Persistent project exceptions are explicitly configured in the project’s opencode.json.
    I deliberately use global configuration for defaults and project configuration for exceptions. I should not need to remember an old UI approval stored separately in a database to understand why my configured ask no longer prompts.
    Actual Behavior
    During an investigation of a server disk-usage alert, OpenCode made 15 SSH calls without requesting fresh approval:
  • 14 from a subagent;
  • one directly from the primary agent.
    The configuration contained shell / ssh * / ask.
    A saved permission record existed for the same project:
    action: shell resource: ssh * created: 2026-09-01
    The SSH calls occurred in a new session on 2026-09-11.
    The saved record and successful SSH execution were confirmed in local storage. The original interaction that created the saved approval was not recovered.
Screenshot and/or share link

No response

Operating System

macOS / Darwin 25.6.0, arm64

Terminal

ghostty/tmux (TERM=tmux-256color)

Contributor guide

Open the contributing guide

First steps

  1. Read the whole issue, then the project's contributing guide.
  2. Comment on the issue to say you are picking it up — it saves two people doing the same work.
  3. Fork the repository and make your change on a branch.
  4. Open a pull request that references the issue number.

Assessment

This issue has not been assessed yet.

Get new issues in your inbox

A short digest of beginner-friendly GitHub issues.