Claude Code 2.1.288: MCP OAuth and Code Review as a Sidecar, Not Prod Access to Bubble
Claude Code 2.1.288 adds in-session OAuth re-auth for MCP and a findings limit for /code-review. Here is why I use it as a sidecar for code alongside Bubble, not as prod access.
When I'm launching an MVP on Bubble or vibe coding, every developer tool release looks like a shortcut. On October 2, 2026, Anthropic released Claude Code v2.1.288. Two changes caught my eye: in-session OAuth re-authentication for Model Context Protocol (MCP) servers, and a new flag for the /code-review slash command. Same topic: Bubble MCP: A First-Connection Checklist.
If you're a no-code builder or an early-stage founder, you need to know where these features stop. Otherwise you can put your app data at risk. Same topic: Claude Code 2.1.287: What Non-Technical.
What Changed in Claude Code 2.1.288
This release adds practical reliability fixes for working with external tools and inspecting diffs:
- In-session MCP OAuth step-up. If a remote HTTP MCP server asks for additional OAuth scopes during a tool call, Claude Code now shows a re-authentication prompt inside the session. URL-based sign-in now waits for you to confirm explicitly («I’m done, continue») before it runs the tool call. The release also fixes reliability issues with revoked tokens and headless sessions.
- Configurable findings in
/code-review. The local slash command now accepts--max-findings <n>|all|default. I can cap or expand the number of reported issues when I inspect a diff in the terminal, and the setting persists across sessions.
Both are generic improvements to MCP and the developer workflow. Neither one is specific to Bubble, and neither is meant for changing a visual app tree. A closer look: n8n Assistant 2.35+: preview Agents,.
A Sidecar for Helper Code, Not Visual Editor Trees
Local /code-review reads git diffs in a terminal. It catches bugs, syntax inconsistencies, and missing checks in standard programming languages. It doesn't see Bubble visual editor elements, responsive conditional logic, or visual workflows.
Say your Bubble MVP relies on an external sidecar: a custom serverless webhook, an integration worker, or an API wrapper. Reviewing that code with Claude Code makes sense. Expecting it to review the structure of your Bubble app does not.
Why I Don't OAuth-Connect Third-Party MCPs to Prod
People are waiting for Bubble's native MCP integration. According to a recap of a September 25, 2026 founder AMA, Bubble leadership said an editor MCP beta would arrive within two to three weeks. It's supposed to create and edit app UI and support data exploration. On October 2, Bubble staff repeated on the forum that it's «very soon. Very very soon!» They didn't commit to a calendar date or an access tier.

With the official release still pending, some founders are tempted to connect third-party tools (Buildprint, or experimental community wrappers) to production Bubble apps through Claude Code's expanded OAuth handling. Same topic: BuildPrint vs Codex CLI MCP.
I wouldn't do that, for three reasons:
- Client OAuth hardening is not Bubble authorization. Claude Code handling scope step-up cleanly doesn't make an unofficial server safe to touch live Bubble data.
- Live MVP users take the hit. Unverified automated changes to live Bubble data or workflows can cause instant downtime or corrupted data right when you're validating with real users.
- The trust boundaries are separate. Third-party tools have their own security profiles, which differ from Bubble's upcoming official integration. Bubble hasn't published that integration's exact scopes and permission controls yet. Same topic: Bubble MCP server: Three Meanings.
So I keep Claude Code in the sidecar lane. I use it to draft auxiliary services, test external APIs, and review the code around my Bubble app. For changes to the Bubble app itself, I'm waiting for the official beta and published specs.