user-feedback: document Codex OAuth resource binding for project-scoped Supabase MCP

[bradensr]

What happened

Task: Configure and authenticate the hosted Supabase MCP server in the Codex VS Code extension, scoped to one project.

Skill said: In SKILL.md under Supabase MCP Server > Troubleshooting connection issues, configure the MCP URL as https://mcp.supabase.com/mcp, authenticate with OAuth 2.1, and reload. The skill does not explain that OAuth credentials are resource-bound or how project_ref query parameters interact with Codex OAuth discovery.

Observed sequence on Windows with Codex CLI 0.144.5 / VS Code extension 26.707.91948:

1. Using https://mcp.supabase.com/mcp?project_ref=abc123 and selecting Authenticate returned:
   {"message":"resource: Resource must be a valid MCP endpoint"}
2. Adding an explicit scalar oauth_resource matching the URL returned:
   {"message":"resource: Expected string, received array"}
   (apparently duplicate auto-discovered and explicit resource parameters).
3. Removing oauth_resource and authenticating with the base URL https://mcp.supabase.com/mcp succeeded.
4. Changing the configured URL back to the project-scoped URL caused authentication to fail in a new agent/task. The base-resource OAuth session did not remain valid for the project-scoped resource.

The hosted endpoint itself was reachable and returned the expected 401 challenge and protected-resource metadata.

Expected: The skill should explain that the MCP URL used for OAuth must remain stable because credentials can be bound to the exact protected resource. It should document a verified Codex-compatible path for project-scoped OAuth, or explicitly recommend keeping the base URL and requiring agents to verify/pass the target project reference before writes when scoped OAuth is incompatible.

Source

File: SKILL.md

Section: Supabase MCP Server > Troubleshooting connection issues

Fix suggestion

Add a Codex/remote-MCP troubleshooting note covering:

• OAuth tokens may be bound to the exact MCP resource URL.
• Authenticating against the base URL and then adding ?project_ref=... can invalidate authentication.
• Do not add oauth_resource when the client already performs protected-resource discovery; duplicate resource parameters may be parsed as an array.
• Provide a tested Codex configuration for project-scoped OAuth.
• If project-scoped OAuth is not supported reliably, document the safer fallback: keep the authenticated base URL unchanged, explicitly verify the target project reference before every write, and avoid exposing tokens in chat.