[BUG] “Always allow” TUI approvals override restrictions for all agents

[rashidalnaemi]

Description

When a user chooses “Always allow” in a permission prompt, the approval is stored in a process‑wide in‑memory ruleset keyed only by permission + pattern. During evaluation, the approved rules are appended after the agent/session rules and win due to findLast, causing the approval to apply across all agents and sessions in the same OpenCode process. This overrides agent‑specific permission configurations, which is unexpected and unsafe. I believe the expected behavior is just for the specified agent to be granted that permission.

Strong suggestion
Scope “always allow” to both agent and session (not just agent). Store approvals with {agent, sessionID, permission, pattern} and only match approvals where both agent and session ID match the current request, or at least allow it as an option (Always Allow/Always Allow for this Session)

Plugins

None

OpenCode version

1.1.19

Steps to reproduce

1. Configure Plan Agent with restrictive permissions (e.g., deny write), Build with ask permissions.
2. Start a session with Build Agent and trigger a permission prompt for write.
3. Choose “Always allow”.
4. Start a session with Plan and trigger a writett.
5. Observe that the permission is auto‑approved despite Plan Agent’s restrictions.

Screenshot and/or share link

No response

Operating System

Fedora and Arch

Terminal

Ghostty and Wezterm

[github-actions]

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

• [Security Bug] Subagent permissions not enforced - configured restrictions ignored #7474: Subagent permissions not enforced - configured restrictions ignored (addresses similar permission override issues with subagents)
• [Security Issue/Bug] Plan mode restrictions bypassed when spawning sub-agents #6527: Plan mode restrictions bypassed when spawning sub-agents (security issue about restrictions being overridden through delegation)
• permission.ask plugin hook is defined but not triggered #7006: permission.ask plugin hook is defined but not triggered (relates to permission system bypasses)

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