the default permissions may not be applied correctly like i have read checked but it still asks for permission #198

New Issue

2026-03-09T13:01:21-07:00

amari commented

2026-03-09 13:01:21 -07:00

Default Permissions Not Applied Correctly

Description

Hey there! 👋 Thanks so much for flagging this — it's exactly the kind of thing that can be frustrating when permissions should "just work."

We're noticing that the default permission settings aren't being applied as expected. Specifically, when a user has "read" permissions checked in the defaults, the system is still prompting them for permission instead of granting access automatically. This suggests there's a disconnect between what's configured and what's actually being enforced.

This one matters because users expect their default permissions to be respected without friction — it's the whole point of setting defaults in the first place! Let's get this sorted so the permission system works as intended.

What We Know

Default "read" permission is marked/checked in settings
System still prompts for permission when it shouldn't
Expected behavior: access should be granted silently based on defaults

Acceptance Criteria

✅ Verify that default permissions (read, write, etc.) are correctly retrieved from the user's profile/settings
✅ Confirm the permission check logic actually compares against these defaults before prompting
✅ Test that a user with default "read" permission can access resources without additional permission prompts
✅ Ensure the fix works across all permission types (read, write, admin, etc.)
✅ Add a test case that would catch this regression in the future

Next Steps

This will need someone to dig into the permission-checking logic and trace where the disconnect is happening. Could be in retrieval, comparison, or enforcement — we'll figure it out together!

Thanks for bringing this to our attention. 💙

# Default Permissions Not Applied Correctly ## Description Hey there! 👋 Thanks so much for flagging this — it's exactly the kind of thing that can be frustrating when permissions should "just work." We're noticing that the default permission settings aren't being applied as expected. Specifically, when a user has "read" permissions checked in the defaults, the system is still prompting them for permission instead of granting access automatically. This suggests there's a disconnect between what's configured and what's actually being enforced. This one matters because users expect their default permissions to be respected without friction — it's the whole point of setting defaults in the first place! Let's get this sorted so the permission system works as intended. ## What We Know - Default "read" permission is marked/checked in settings - System still prompts for permission when it shouldn't - Expected behavior: access should be granted silently based on defaults ## Acceptance Criteria - ✅ Verify that default permissions (read, write, etc.) are correctly retrieved from the user's profile/settings - ✅ Confirm the permission check logic actually compares against these defaults before prompting - ✅ Test that a user with default "read" permission can access resources without additional permission prompts - ✅ Ensure the fix works across all permission types (read, write, admin, etc.) - ✅ Add a test case that would catch this regression in the future ## Next Steps This will need someone to dig into the permission-checking logic and trace where the disconnect is happening. Could be in retrieval, comparison, or enforcement — we'll figure it out together! Thanks for bringing this to our attention. 💙

hikari referenced this issue from a commit

2026-03-09 13:18:53 -07:00

fix: include auto_granted_tools when reconnecting after permission approval

hikari referenced a pull request that will close this issue

2026-03-09 14:46:02 -07:00

fix: resolve message submission and stuck processing bugs #199

naomi closed this issue

2026-03-09 16:53:09 -07:00

naomi referenced this issue from a commit

2026-03-09 16:53:11 -07:00

fix: resolve message submission and stuck processing bugs (#199)

Sign in to join this conversation.

Branches Tags

main

dependencies/update--tauri-apps-plugin-fs

dependencies/update--tauri-apps-plugin-dialog

dependencies/update--codemirror-language

dependencies/update--codemirror-lang-yaml

dependencies/update-tailwindcss

dependencies/update--tailwindcss-vite

dependencies/update--vitest-coverage-v8

dependencies/update--codemirror-commands

dependencies/update--codemirror-state

dependencies/update-prettier-plugin-svelte

dependencies/update--codemirror-lang-javascript

dependencies/update-lucide-svelte

dependencies/update-marked

dependencies/update-typescript-eslint

dependencies/update-svelte

dependencies/update-eslint-plugin-svelte

dependencies/update--codemirror-view

dependencies/update-eslint

dependencies/update--eslint-js

dependencies/update--tauri-apps-cli

dependencies/update--sveltejs-kit

dependencies/update--tauri-apps-plugin-shell

dependencies/update--tauri-apps-api

dependencies/update-jsdom

dependencies/update-globals

dependencies/update-svelte-check

feat/providers

fix/paths

dependencies/update-vitest

dependencies/update-vite

dependencies/update-typescript

dependencies/update-prettier

dependencies/update--sveltejs-vite-plugin-svelte

dependencies/update--sveltejs-adapter-static

dependencies/update-codemirror

dependencies/update--tauri-apps-plugin-store

dependencies/update--tauri-apps-plugin-os

dependencies/update--tauri-apps-plugin-opener

dependencies/update--tauri-apps-plugin-notification

1 Participants

Notifications

Due Date

No due date set.

Dependencies

No dependencies set.

Reference: nhcarrigan/hikari-desktop#198