Skip to content

fix: restore pending permissions via REST API after session switch#365

Merged
sudo-tee merged 3 commits intosudo-tee:mainfrom
jbro:fix/preserve-permissions
Apr 28, 2026
Merged

fix: restore pending permissions via REST API after session switch#365
sudo-tee merged 3 commits intosudo-tee:mainfrom
jbro:fix/preserve-permissions

Conversation

@jbro
Copy link
Copy Markdown
Contributor

@jbro jbro commented Apr 27, 2026

Summary

  • Restore pending permission dialogs after a session switch, mirroring the existing restore_pending_question pattern in question_window.lua
  • Previously, switching sessions would auto-deny all pending permissions and discard them — they are now fetched from the server and re-queued

Changes

api_client.lua — Added list_permissions() method (GET /permission) to fetch pending permissions from the server.

permission_window.lua — Added restore_pending_permissions(session_id) which:

  1. Fetches all pending permissions via the new API endpoint
  2. Filters to those belonging to the active session (including child task sessions)
  3. Re-queues matching permissions into the UI, avoiding duplicates

renderer.lua

  • Calls restore_pending_permissions() alongside restore_pending_question() in render_full_session()
  • Removed the old reset() logic that auto-denied all pending permissions on session switch

@jbro jbro force-pushed the fix/preserve-permissions branch 2 times, most recently from 7f27e47 to 2aeed6a Compare April 28, 2026 07:01
@sudo-tee
Copy link
Copy Markdown
Owner

Thanks for the PR.

Should we check the permission status ?

I did something similar for questions a while back
If you look at the restore_pending_question function I had to add a check for resolved questions since it would restore answered questions.

jbro added 2 commits April 28, 2026 11:54
renderer.reset() clears the permission queue on every session change.
The previous approach (preserve_permissions flag) tried to keep the queue
alive across resets, but permissions that arrived for a different worktree
while the user was away were never in the queue to begin with.

Mirror the question_window.restore_pending_question pattern instead:
after the session loads, query GET /permission for pending permissions,
filter for ones belonging to the active session, and show them.

This removes all preserve_permissions plumbing and the auto-deny
behaviour from reset() (the cancel function handles explicit abort).
Add list_permissions to the shared mock API client so tests exercising
render_full_session() don't crash on the new restore_pending_permissions
code path. Add a dedicated test verifying that pending permissions are
fetched and re-queued via on_permission_updated after a session switch.
@jbro jbro force-pushed the fix/preserve-permissions branch from 2aeed6a to 10ccc62 Compare April 28, 2026 09:54
@jbro
Copy link
Copy Markdown
Contributor Author

jbro commented Apr 28, 2026

Thanks for the PR.

Should we check the permission status ?

I did something similar for questions a while back If you look at the restore_pending_question function I had to add a check for resolved questions since it would restore answered questions.

Yeah that makes sense, let me take a look and see if I can figure it out 🙂

@sudo-tee
Copy link
Copy Markdown
Owner

Great thanks for the PR.

Looks good to me

@sudo-tee sudo-tee merged commit 92ad9bf into sudo-tee:main Apr 28, 2026
5 checks passed
Sign up for free to 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.

2 participants