Uh oh!
There was an error while loading. Please reload this page.
fix: debounce permission notifications to avoid false positives in auto mode - #26
Open
sfdye wants to merge 1 commit into
Open
fix: debounce permission notifications to avoid false positives in auto mode#26sfdye wants to merge 1 commit into
sfdye wants to merge 1 commit into
Conversation
sfdyeforce-pushed
the
lwan/fix-false-permission-notification
branch
2 times, most recently
from
August 24, 2026 03:32
696a608 to
3a51ad8Compare…to mode Instead of swapping permission.updated for permission.asked (which fires under the same condition), debounce permission notifications by 500ms and cancel them if permission.replied arrives within that window. In auto mode, Warp auto-replies near-instantly → notification cancelled → no false 'agent blocked' notification. In non-auto mode, no instant reply arrives → notification fires after the grace period → user sees it as before. Both permission.updated (v1 SDK) and permission.asked (v2 SDK) are handled, preserving compatibility across opencode versions.
sfdyeforce-pushed
the
lwan/fix-false-permission-notification
branch
from
August 24, 2026 04:00
3a51ad8 to
b147546Comparesfdye
marked this pull request as ready for review
August 25, 2026 03:09
This file contains hidden or bidirectional Unicode text that may be interpreted or compiled differently than what appears below. To review, open the file in an editor that reveals hidden Unicode characters.
Learn more about bidirectional Unicode characters
Sign up for freeto join this conversation on GitHub.
Already have an account?
Sign in to comment
Add this suggestion to a batch that can be applied as a single commit.This suggestion is invalid because no changes were made to the code.Suggestions cannot be applied while the pull request is closed.Suggestions cannot be applied while viewing a subset of changes.Only one suggestion per line can be applied in a batch.Add this suggestion to a batch that can be applied as a single commit.Applying suggestions on deleted lines is not supported.You must change the existing code in this line in order to create a valid suggestion.Outdated suggestions cannot be applied.This suggestion has been applied or marked resolved.Suggestions cannot be applied from pending reviews.Suggestions cannot be applied on multi-line comments.Suggestions cannot be applied while the pull request is queued to merge.Suggestion cannot be applied right now. Please check back later.
Problem
In auto mode, Warp auto-approves permission requests, but the plugin still sent a "Wants to run X" notification for every permission ask — causing Warp to show false "agent blocked" notifications while the agent was working uninterrupted.
Root cause
After investigating the opencode source (
packages/opencode/src/permission/index.tsacross v1, PermissionNext, and current v2), bothpermission.updated(v1 SDK) andpermission.asked(v2 SDK) fire under identical conditions — only when the ruleset evaluates to"ask". Neither event fires for auto-approved ("allow") or denied ("deny") permissions.The false positives occur because Warp's auto mode auto-replies to permission requests at the client level: opencode publishes a genuine ask event → the plugin notifies "blocked" → Warp auto-approves → the agent continues. The user sees a notification even though no input was needed.
The event payload (
{id, type, pattern, sessionID, messageID, callID, title, metadata, time}) has no outcome field, so the plugin cannot distinguish "Warp will auto-approve this" from "user must act" at fire time.Fix
Debounce permission notifications by 500ms. If
permission.repliedarrives within that grace period, the notification is cancelled.Both
permission.updated(v1 SDK case) andpermission.asked(v2 SDK default case) are handled with the same debounce logic, preserving compatibility across opencode versions. Thepermission.repliedhandler checks bothrequestID(v2) andpermissionID(v1) field names, and bothreply(v2) andresponse(v1) for the reject check.Verification
npm run build— cleannpx tsx --test tests/index.test.ts tests/payload.test.ts— 23/23 assertions pass