Repository navigation
A known bot can ask for more permissions (GRYT-2006) - #361
Merged
Merged
Conversation
A bot's list was fixed at its first knock, so a bot that needed more had to come back with a new key: a second bot under the same name, with none of the first one's history. Now an approved bot that declares permissions it never asked for still gets in with what it holds, and the new ones are stored as more_permissions for an admin. Nothing is granted until one answers. Approve grants what was ticked from the new ones on top of what it had; whatever isn't ticked goes into declined_permissions and isn't asked again. Declining leaves the bot approved with what it had. The reason the list was fixed still holds: a taken-over image can ask, but it can't give itself anything. The bot list carries "more" so the client can show the question. Co-Authored-By: Claude Opus 5.5 <noreply@anthropic.com>
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 free
to 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.
Review-required: touches
src/db/(a migration and the bot record).A bot's list was fixed at its first knock, so a bot that needed more had to come back with a new key. That made a second bot under the same name, with none of the first one's history. It happened with the Gryt MCP on beta today.
What changes
more_permissions, an audit entrybot_asked_moreis written, and the Bots list refreshes.server:bots:decideon such a bot answers the new ask. Approve grants what's ticked from the new ones on top of what it had. Unticked ones go intodeclined_permissionsand aren't asked again. Decline leaves the bot approved with exactly what it had.server:bots:listcarriesmorefor the client.bots:more_permissionsanddeclined_permissions, bothTEXT NOT NULL DEFAULT '[]'.Look at
decideBot's new branch. It only runs for an approved bot with something pending, and the grant is bounded by requested ∪ more, so it can't hand out anything never asked for.Tested: four new cases in
bots.test.ts(held not granted, partial approve plus remembered no, decline keeps it in, a pending bot can't use it). Full suite: 2155 pass.Client: Gryt-chat/client#1146. Docs and the bot README follow, since they say the list is fixed.
🤖 Generated with Claude Code