Detailed Analysis
A recurring friction point in the Claude.ai ecosystem concerns the gap between the platform's built-in Supabase connector and the more granular permission controls available through Claude Code's MCP (Model Context Protocol) implementation. The Reddit post in question captures a technically accurate frustration: when a user connects Supabase through Claude.ai's web interface Connectors settings, the resulting integration grants broad access — including write permissions — and offers no native read-only toggle equivalent to what Supabase's own MCP documentation describes. The user correctly identifies that disabling individual tool permissions within the Claude.ai interface is possible for most operations, but "execute SQL" cannot be meaningfully restricted this way, leaving the database exposed to potential mutations during a conversation.
The root cause of this confusion lies in an architectural distinction between two separate Claude products. Supabase's official MCP server, documented at mcp.supabase.com, is explicitly designed for Claude Code — Anthropic's terminal-based agentic coding environment — rather than for Claude.ai's browser-based chat interface. In Claude Code, a user can invoke `claude mcp add --transport http supabase` with a specific project reference, triggering an OAuth 2.1 browser flow that, depending on the authorization scopes selected, can be constrained to read-only operations backed by a Postgres read-only role. This approach limits the agent to SELECT-class queries, schema inspection, storage browsing, and log reading, without any capacity for mutations. The Claude.ai web connector, by contrast, uses a separate integration pathway that does not currently expose the same granular read/write scope selection during OAuth authorization, leaving users without an equivalent safeguard in the chat context.
For users who require read-only Supabase access specifically within the Claude.ai web interface, the available workarounds fall into two categories. The first is database-level enforcement: creating a dedicated Postgres role within Supabase that has only SELECT privileges on the relevant schemas and tables, then using that role's credentials to configure any connection. This approach enforces read-only behavior at the database layer regardless of what Claude attempts to execute. The second category involves third-party MCP proxy services such as Merge.dev or Composio, which authenticate against Supabase on behalf of the user, proxy all queries, and can be configured to limit the operations Claude is permitted to perform. Neither workaround is as seamless as a native read-only toggle, and both introduce additional setup complexity or external service dependencies.
This situation reflects a broader structural challenge in deploying AI agents against production data systems. The MCP standard itself is designed to enable precise capability scoping — a server can expose exactly the tools it chooses and no more — but the value of that design depends entirely on whether the client-facing authorization flow surfaces those scope choices to the end user. When an integration abstracts away OAuth scope selection in the name of convenience, as the Claude.ai web connector appears to do, it inadvertently removes the principal mechanism by which users can enforce least-privilege access. The GitHub issue tracker for the Supabase MCP community repository already contains feature requests for a more explicit read-only mode, indicating this is a recognized gap rather than an edge case, and suggesting that future iterations of both the Supabase MCP server and the Claude.ai connector layer will likely need to address scope granularity more directly.
The broader trend this episode illustrates is the increasing urgency of permission governance as AI assistants gain direct connections to live production infrastructure. As of April 2026, MCP integrations are proliferating rapidly across databases, file systems, calendars, and enterprise SaaS tools, and the security model underpinning each varies significantly. Anthropic's own guidance emphasizes minimal footprint and preference for reversible actions in agentic contexts, but those principles require platform-level enforcement mechanisms — not just instructional prompts — to be reliable in practice. The Supabase read-only access gap is a small but representative example of the gap between the intended safety philosophy of agentic AI systems and the current state of their integration tooling, a gap that the industry is only beginning to close through standards work, OAuth scope enforcement, and database-layer access controls.
Read original article →