Desktop Auto-accept permissions toggle does not stop permission prompts #47096

Activity

1. github-actions

   assigned

   Hona

   on Sep 3, 2026
2. github-actions commented on Sep 3, 2026

   

   github-actionsBot

   on Sep 3, 2026 – with GitHub Actions

   Contributor

   More actions

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

   • Desktop v1.18.3 — "Auto-accept permissions" settings toggle permanently disabled (cursor: not-allowed) #37617: Desktop v1.18.3 — "Auto-accept permissions" settings toggle permanently disabled — documents the root cause where the Settings dialog toggle does not properly connect to the runtime permission state
   • New Layout Forcibly Disables Auto-Accept Permissions #45159: New Layout Forcibly Disables Auto-Accept Permissions — related issue where layout switching resets the auto-accept state
   • [Web UI] "Auto-accept permissions" button is disabled when "New layout and design" is enabled. #31137: [Web UI] "Auto-accept permissions" button is disabled when "New layout and design" is enabled — similar disconnect between the toggle UI and actual permission behavior

   If your issue is distinct (toggle appears ON but permissions still prompt, rather than the toggle being disabled), please clarify with additional details so we can track it separately.
3. RaviTharuma commented on Sep 3, 2026

   

   RaviTharuma

   on Sep 3, 2026

   Author

   More actions

   Distinct from all three, and none of them has landed — #37617, #45159 and #31137 are all still open.

   Those three describe the toggle being disabled / forced off: the control itself is unavailable or gets reset by layout switching. This issue is the inverse failure — the toggle reads ON and still does not suppress prompts, so the UI state and the runtime permission state disagree in the direction that looks like it should work.

   That matters because the disabled-toggle reports are fixable in the settings UI alone, whereas this one is a propagation bug: the persisted setting is never applied to a newly created session. PR #47104 fixes exactly that path (settings auto-accept honored when a session is created), so it does not overlap with a UI-enablement fix.

   Happy to close as a duplicate if a maintainer prefers to track the ON-but-ignored case under #37617, but the reproduction and the fix are different from the disabled-toggle ones.
4. thdxr commented on Oct 11, 2026

   

   thdxr

   on Oct 11, 2026

   Member

   More actions

   Thanks for the report! OpenCode 2.0 is now out and development is focused on V2, so we're closing issues filed against OpenCode 1. Please upgrade (opencode upgrade --major, details: https://anoma.ly/notes/opencode-2-0), and if this is still relevant on 2.0, reopen this issue or open a new one with your 2.0 version.

   — from 𝕺𝖕𝖊𝖓𝕮𝖔𝖉𝖊
5. thdxr

   closed this as not plannedon Oct 11, 2026