Skip to content

fix: debounce permission notifications to avoid false positives in auto mode - #26

Open
sfdye wants to merge 1 commit into
warpdotdev:mainfrom
sfdye:lwan/fix-false-permission-notification
Open

fix: debounce permission notifications to avoid false positives in auto mode#26
sfdye wants to merge 1 commit into
warpdotdev:mainfrom
sfdye:lwan/fix-false-permission-notification

Conversation

@sfdye

@sfdyesfdye commented Aug 24, 2026

Copy link
Copy Markdown

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.ts across v1, PermissionNext, and current v2), both permission.updated (v1 SDK) and permission.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.replied arrives within that grace period, the notification is cancelled.

  • Auto mode: Warp auto-replies within milliseconds → timer cancelled → no false "blocked" notification
  • Non-auto mode: no instant reply → notification fires after 500ms → user sees it as before (a user who replies within 500ms made the notification moot anyway)
  • Works whether Warp auto-approves all asks or only a subset — only auto-approved ones are suppressed

Both permission.updated (v1 SDK case) and permission.asked (v2 SDK default case) are handled with the same debounce logic, preserving compatibility across opencode versions. The permission.replied handler checks both requestID (v2) and permissionID (v1) field names, and both reply (v2) and response (v1) for the reject check.

Verification

  • npm run build — clean
  • npx tsx --test tests/index.test.ts tests/payload.test.ts — 23/23 assertions pass
  • Manual verification in Warp pending

@sfdye
sfdyeforce-pushed the lwan/fix-false-permission-notification branch 2 times, most recently from 696a608 to 3a51ad8CompareAugust 24, 2026 03:32
…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.
@sfdye
sfdyeforce-pushed the lwan/fix-false-permission-notification branch from 3a51ad8 to b147546CompareAugust 24, 2026 04:00
@sfdyesfdye changed the title fix: use permission.ask hook to avoid false positive notificationsfix: debounce permission notifications to avoid false positives in auto modeAug 24, 2026
@sfdye
sfdye marked this pull request as ready for review August 25, 2026 03:09
Sign up for freeto join this conversation on GitHub. Already have an account? Sign in to comment

Labels

None yet

Projects

None yet

Development

Successfully merging this pull request may close these issues.

1 participant

@sfdye