[Dhravya]

Widget write choices only honored scope.permission = read when the grant was tag-scoped. A Read only + All memories MCP connection is type: full with permission: read, so guided-save and upload still offered writable spaces.

effectiveContainerTagAccess now treats permission: read as read-only regardless of scope type. This matches /v3/session reporting the actual OAuth grant.

[polylane]

Note

Production impact unlikely.

Checked the RBAC change against supermemory-mcp (~30k req/h, invocation Errors flat at 0): effectiveContainerTagAccess feeds only the save/upload/picker widget lists, and every branch introduced can only narrow permission to read — no write path is gated by it.

View the full analysis →

Also considered · 2 refuted

• Refuted · Full-scope read grant now blocks a write the user expected to succeed · The only consumers turn the value into a UI list that already guards the empty case, and the changed branch cannot produce "write" — so the worst case is a read-only widget showing zero writable spaces, which is the intended behaviour for a read-only grant.
• Refuted · Hoisting the read check widens access for tag-scoped grants · A truth-table comparison of the old and new conditions shows the change is monotonically stricter: the hoisted check subsumes the removed disjunct for scoped grants and only adds the full-scope read case.

Analysed against 1 Cloudflare Worker and 1 repository

• Cloudflare Worker: supermemory-mcp
• Repository: supermemoryai/supermemory

_{Polylane analysed c28f7b8 for production impact. You can ask follow-ups by mentioning @polylane in a comment.}

Rate this review: 👍 helpful · 👎 not helpful · 😕 confusing