Repository navigation
Auto mode causes repeated false permission notifications in terminals #47545
Description
Description
When using OpenCode Auto mode, permission notifications keep firing even though the permissions are automatically approved and the agent never needs user input.
The underlying issue is that Auto approval currently happens client-side, after the server has already emitted permission.asked. Integrations such as Warp and Orca therefore interpret these requests as requiring user attention.
Expected
Auto-approved permissions should not emit a user-attention event.
Downstream impact
This currently affects at least:
- Orca: [Bug]: OpenCode Auto mode sends repeated false permission notifications stablyai/orca#18950
- Warp: fix: debounce permission notifications to avoid false positives in auto mode warpdotdev/opencode-warp#26
The Warp PR works around the race downstream by delaying notifications briefly. Fixing the distinction upstream would avoid integrations needing their own suppression logic.
Proposed direction
#47754 moves the Auto decision server-side so covered requests can be resolved before permission.asked is emitted.
The remaining design question is whether TUI Auto should continue affecting all sessions on the connected server, as it effectively does today, or only the current session.
Plugins
No response
OpenCode version
1.18.29
Steps to reproduce
- Run OpenCode in Warp or Orca.
- Enable Auto mode.
- Start a task with permission-gated tool calls.
- Observe repeated permission / blocked notifications.
- The agent continues without requiring input.
Screenshot and/or share link
No response
Operating System
macOS 27.0 Beta (26A5421a)
Terminal
Warp.dev & Orca
Related
#47675 restores the permission.ask plugin hook, allowing a plugin verdict to resolve a request before permission.asked is emitted. It is related because both changes aim to resolve permission requests before they become user-attention events.
Activity
sambokai commentedon Sep 6, 2026
Earlier architecture exploration
I looked into a few ways to fix this upstream.The root issue is that Auto mode currently happens on the client side, so the server emits
permission.askedbefore it knows the request will be auto-approved. Integrations like Warp and Orca therefore briefly think user input is needed.The approaches I considered:
A. Client-side workaround
Keep Auto as-is and debounce/suppress those notifications downstream.
B. Session-scoped server Auto
Move Auto to the server and apply it to a specific session and its descendants.
C. Client-owned server Auto
Move the decision to the server, but make the Auto authority temporary and owned by the client that enabled it.
D. Instance-owned/shared server Auto
Store Auto as shared state on the OpenCode instance, independent of which client enabled it.
I implemented C, using a renewable lease so the authority disappears if the client disconnects or crashes.
The remaining scope decision is separate from ownership: for the TUI, my implementation gives that client-owned lease instance scope, which is closest to the TUI's current effective behavior.
run --autoinstead gets a session-scoped lease covering only that run and its descendants.I have this working locally with tests. Before opening a PR, I'd mainly appreciate feedback on whether that ownership/scope model makes sense, or whether TUI Auto should also be session-scoped.
I’ve pushed the implementation to my fork in case it’s useful to look at: #47754 (Opened as a draft PR with option C implemented, so the code is easier to look at than the compare link.)
sambokai commentedon Sep 6, 2026
@thdxr @rekram1-node since you introduced Auto mode in #33279, would you mind sanity-checking the ownership/scope direction above? I have an implementation ready, but I'm holding off on opening the PR because this moves part of Auto handling server-side and I'd like to make sure that matches the intended model first.
AmethystLiang commentedon Sep 7, 2026
Thanks for reporting! We'll look into it.
Atmostone commentedon Sep 7, 2026
Thanks for the cross-reference — one correction so it doesn't over-promise.
anomalyco/opencode#47675
doesn't move Auto server-side. It revives the permission.ask plugin hook, which happens to run inside Permission.ask before pending.set and before Event.Asked is published — so a plugin verdict resolves the request without ever emitting a user-attention event. Built-in Auto is untouched, so on its own it doesn't fix your case.
Where they meet: both touch packages/opencode/src/permission/index.ts and packages/core/src/v1/permission.ts, so they will conflict. Mine is small (+412/-7) and ready; yours is the larger change with an open design question. Happy to rebase onto yours whenever it lands — no need to sequence around me.
One thing the lease model may need to settle: with the hook alive, a plugin can answer ask on a request Auto would have covered. Does the lease win, or the plugin? Failing toward the prompt looks right to me, but it is worth being explicit — otherwise the "resolved before the event" property you are adding can be undone by a plugin, and the notifications come back intermittently.
sambokai commentedon Sep 7, 2026
@Atmostone
Thanks, that makes sense. No need to sequence the PRs around each other. I’m happy to handle the conflict whichever lands first.
Good catch on the plugin/Auto interaction too. One option would be to treat Auto as part of the effective permission decision before
permission.askruns: an active lease turns the normalaskintoallow, then the plugin can still tighten that back toaskordeny. If it returnsask, emittingpermission.askedwould then be correct because user attention is genuinely required.Another possibility might be a separate hook specifically for Auto approval, so plugins can review or veto an automatic approval without overloading the semantics of
permission.ask. However, that additional API surface is probbaly not justified for this PR.sambokai commentedon Sep 8, 2026
Small follow-up after looking at the current v2 branch: this issue still appears to apply there.
Auto approval is still performed client-side in the TUI after the permission request exists, so the same ordering problem around permission.asked remains. #44009 also keeps that event-driven model and addresses the scope of the responder rather than moving the decision before the event.
That makes me think the issue itself is still relevant to v2, while the lease/API implementation in #47754 is much more specific to the current dev architecture.
lesacar commentedon Oct 1, 2026
bump, still happening on latest version and it's a pretty simple to fix with a working PR, any ETA on this getting merged?
edit: v2.0.21
sambokai commentedon Oct 2, 2026
Downstream update: Orca has now landed stablyai/orca#24612, which fixes stablyai/orca#18950 by waiting up to 500 ms before surfacing a permission request as needing input.
That matches the approach in warpdotdev/opencode-warp#26, which also uses a 500 ms grace period to suppress notifications when Auto replies immediately.
So both Orca and Warp now work around the same
permission.asked→ client-side Auto reply ordering downstream.iitzkube commentedon Oct 9, 2026
Also opencode v2.0.24 is spamming iTerm2 notifications on auto mode for every tool call, in the session itself nothing is actually waiting for my permission/input
thdxr commentedon Oct 11, 2026
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 𝕺𝖕𝖊𝖓𝕮𝖔𝖉𝖊
sambokai commentedon Oct 12, 2026
Hi @thdxr, This is still happening on V2, as confirmed above on v2.0.21 and v2.0.24.
The underlying issue also remains:
permission.askedis emitted before client-side Auto approval responds.I realize my original PR (#47754) targets the old architecture and would need to be adapted for V2, but the issue itself is still relevant.
Could we reopen this? I'm happy to work on a V2 fix if moving Auto approval server-side is an acceptable direction.
rekram1-node commentedon Oct 13, 2026
Hmm this is kinda weird to solve
yethranayeh commentedon Oct 20, 2026
Can confirm this is happening on my 2.1.1 client too
Environment: OpenCode 2.1.1, macOS 15.7.4 (24G517, Darwin 24.6.0, arm64), Rex 0.1.0 (1282) as the terminal, zsh.
Had an agent actually measure its own session and it reported:
Also worth noting that the same session that appears on my other tabs (which also have OpenCode sessions open on the same working directory) apparently produce three reports per request
Here is a video recording:
Screen.Recording.2026-10-20.at.19.43.54-e-cut-merged-1792520578631-lowered.mp4