Repository navigation
Conversation
![opencode-agent[bot]](https://avatars.githubusercontent.com/in/1549082?s=60&v=4){kind=small}
There was a problem hiding this comment.
The change looks correct. Its check matches what the session view actually auto-approves: the open session and its subagents in auto-accept mode, and nothing when the open session is itself a subagent. Since only one session view is mounted at a time, requests from other tabs or the home screen stay pending and still alert. The new tests pass, and type checks pass in packages/tui and packages/plugin. I could not reproduce the sound or notification end to end in a simulated TUI, because the simulated model never triggered a permission request.
Public API: adds ui.permission.mode(): PermissionMode to the TUI plugin context and exports the type PermissionMode = "prompt" | "autoaccept" from @opencode/plugin/tui/context. This is additive and backwards compatible for plugins that use the context. Code that builds its own TUI plugin context object (like the test harness here) now has to provide ui.permission. Maintainers should decide whether this belongs in the public plugin API.
One concern, noted inline: which requests get auto-approved is now decided in two places, and they can drift apart.
Related: #47545
| }) | ||
| } | ||
|
|
||
| function willAutoApprove(context: Plugin.Context, sessionID: string) { |
There was a problem hiding this comment.
This copies the auto-approve scope from routes/session/index.tsx (the descendantSessionIDs/permissions memos and the auto-accept createEffect). If one changes without the other, for example if auto-accept starts covering other tabs or stops skipping subagent routes, requests will either be silenced while left pending (the bad case) or alert again. Could both places use one shared helper for the scope, or could a comment on each side point to the other, so they stay in sync?
Issue for this PR
Closes #48579
Type of change
What does this PR do?
The TUI played the permission alert (sound plus terminal notification) for requests that were auto-approved and never shown, so auto-accept produced constant noise.
The
permission.askedhandler infeature-plugins/system/notifications.tsnow skips the alert only for requests this client will actually auto-approve: the open session and its subagents, while the live permission mode is auto-accept. Requests from another tab, the home screen, or a session opened as a subagent still alert, because those are not auto-approved and stay pending.To read the live mode from that handler, the TUI plugin context gains
ui.permission.mode()and an exportedPermissionModetype. This is additive and existing plugins are unaffected, but it does widen the public plugin API, so it needs a maintainer decision.This replaces #54901: I deleted my fork failing to realise that would close my pull requests. -_- That PR's review found the initial placement and scoping wrong; both were fixed before it closed.
Related: #53525 (closed as a duplicate of #48579)
How did you verify your code works?
bun test test/cli/cmd/tui/notifications.test.tsinpackages/tuicovers auto-accepted requests staying silent, requests outside the open session still alerting, and subagent-applied requests staying silent.bun run typecheck:tscis clean inpackages/tuiandpackages/plugin.Screenshots / recordings
Checklist
Added by the opencode bot (AI-generated).
Related: #47545
Public API: adds
ui.permission.mode()and thePermissionModetype to the TUI plugin context (additive, backwards compatible)